[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] dna-cpl vs. dna-hosts
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