Dear Thomas,
Thomas Narten wrote:
>> Thomas' question about whether CPL and Hosts are
really
>> separate still remains, although I think at an
earlier
>> time, the WG consensus was to keep the drafts
separate.
>
> Why? And what is the benefit of keeping them separate?
Personally, I've no objection to combining them,
although there was an intention at the time (as I
recall, -hosts and -routers were combined at the time,
and there was even more text in them).
We need to check that it's a good match if there's
to be merger (this is what we're doing now).
We'd want to see what the WG says, so I encourage people
to show an opinion.
> I just read through the dna-hosts document, and I can't
quite figure
> out what its trying to do (relative to cpl). On the one
hand, it (at a
> high-level) describes some issues with DNA, etc.,
without making
> specific recommendations. On the other hand, in some
areas, it
> includes some fairly specific SHOULD/MAY type
terminology and makes
> recommendations about adding random delays and such.
I.e, much more
> like a spec.
Hosts does include a lot of the background and motivation
which was omitted from CPL, for example information
pertaining
to points 4) and 5) mentioned in your review of the
document.
Where existing recommendations were superceded by the CPL
algorithm,
the hosts document was reorganized to refer to the
algorithm,
without duplicating it (except for a stub in section 4.2.2
of -hosts)
> I strongly believe that we do not want two different
documents on the
> standards track making recommmendations on what a host
should do for
> DNA (to work with unmodified routers). All
recommendations should be
> in one document, and the recommendatoin we want hosts
to implement
> should be clear.
I think the important thing is clarity.
> As it stands now, there is some overlap beween the two
documents, and
> there is some stuff covered in hosts that (if it needs
covering)
> should probably be moved to cpl.
Or the other way around, depending on whether you see
CPL as the core, or a component in the description...
I'll have a look through both documents, and see how much
redundancy and waffle there is (within the documents and
between them). I'll try to post a per paragraph analysis
overnight.
> So if there is some reasoning for why we need two
documents (and how
> the content of those two documents complements, but
does not overlap
> with each other), I'd like to hear it.
Indeed. At least we can cut down redundant information.
If the documents are co-dependent, then it may be OK to
combine them.
Others' opinions are earnestly sought.
Greg
|