[Irtf-rr] Fwd: draft-irtf-routing-reqs-02.txt
avri at psg.com
avri at psg.com
Tue May 11 09:47:12 EDT 2004
The following is the RFC editor's review of the requirements draft
submitted. I will be working on an update over the next few weeks. I
would be interested in any discussion people may have of the issues
mentioned below.
a.
Begin forwarded message:
> From: RFC Editor <rfc-editor at rfc-editor.org>
> Date: 10 maj 2004 23.09.10 MET
> To: avri at acm.org, elwynd at nortelnetworks.com, fkastenholz at juniper.net
> Cc: RFC Editor <rfc-editor at rfc-editor.org>
> Subject: draft-irtf-routing-reqs-02.txt
>
> Authors,
>
> The RFC Editor has completed editorial review of this document,
> including
> both parts A and B.
>
>
> (1) Formal problems
>
> The IESG is going to balk at the Security Considerations section.
> You need at least to specifically enumerate the section(s) where
> you talk about security issues. A little blather here would not
> be amiss... ;-)
>
> (2) Editorial problems.
>
> Rather than list all the problems, we found it less work to
> edit the suggested changes into the text. We are sending the
> modified text and diff as: draft-irtf-routing-reqs-02a.txt and
> draft-irtf-routing-reqs-02.wdiff.html. We have probably not
> identified all the problems, but the rest can be handled during
> our EDIT phase.
I have not attached the corrected draft or the diff. I will submit an
updated draft that includes their editorial fixes.
>
> Please, carefully review the changes that we made. We think that we
> interpreted your meaning correctly in every case, but sometimes
> there were ambiguities in the original that may have led us astray.
>
> (3) We have questions and suggestions about the document.
>
> o RFC authors have sometimes been abusing the
> MUST/SHOULD/MAY ... words, and your document has this
> failing in places. We would prefer that you to address
> these issues, generally by de-capitalizing gratuitous
> capitalization. In particular, here are some really
> iffy examples.
>
> - You say the architecture MUST be clear, well thought out, ...
> (2.1.1)
>
> REALLY? How can you determine if you did it?
>
> - You say the architecture MUST be modular (2.1.2).
>
> REALLY? What does that mean, and how do you know?
>
> - You don't say MUST in section 2.1.3, 3rd bullet 1
> (must be slower than Moore's law.)
>
> Did you mean to?
>
> - You say the architecture MUST NOT limit the # of alternate
> paths (2.1.6).
>
> REALLY? No limit? That would be hard to
> believe, even if it were only SHOULD.
>
> - You don't say MUST for "No Bad Data" (2.1.9) (twice).
>
> - You say the architecture MUST be simple enough for
> Radia Perlman to explain in a hour.
>
> Give us a break! That is a content-free MUST.
>
> We probably missed some, but these are the ones we noticed.
>
> o Citations and References
>
> - Mike O'dell quote in 2.1.2 needs a citation and
> reference (the words
> must be quoted from SOMEWHERE!)
>
> - "One respected network sage" (2.2.3) is Dave Clark, and
> we believe he said it in an IETF plenary, probably
> around 1991.
>
> - References [10] and [14] have formatting errors.
>
> o Inconsistencies and duplications
>
> - 2.1.7 appears to duplicate the next to last paragraph of
> 2.1.4.
>
> - The last paragraph of 2.1.7 duplicates 2.2.7. Suggest
> instead (or in addition): "See also Section 2.2.7".
>
> - Section 2.1.13 needs at least a reference to 2.2.9, to
> explain why host mobility was omitted from 2.1.13.
>
> - (How) does 2.1.23 differ from 2.1.6?
>
> - (How) does 2.1.28 differ from 2.1.24? If multiple
> administrations are not just a case (the only case?)
> of "cooperative anarchy", what does the latter mean??
>
> - 2.2.1 appears to contradict 2.1.3.
>
> - 2.2.8 appears to directly contradict 2.1.22.
>
> - The title of 2.2.10 is reversed in polarity; suggest
> "Backwards Compatibility".
>
> o Questions
> - It would be useful to define what you mean by "address
> portability" (2.1.14).
>
> - We did not really grok what 2.1.19 meant. Should
> "integrate with" be "require"?
>
> - In 2.2.3, you say "N!". You can't be serious. How
> about N opinions from N people?
>
> - Section 3.2.2, bullet "Potential addition of a second..."
> Why "potential"; isn't IPv6 already a reality?
>
> - Section 3.2.3.3: What IDR proposal; aren't
> you referring to BGP?
>
> - Section 3.2.3.7 seems to be talking about forwarding
> paradigms, not routing paradigms. Thus, there
> seems to be some overlap/confusion between this
> section and section 3.2.3.4.
>
> - Section 3.4.3: what (??!) is a "wayleave"? (A wayleaf?)
>
> - Section 3.5 item 6, last sentence: shouldn't this
> be "some domains may..."? Surely, not all domains
> will be tens of thousands of routers!
>
> - Section 3.6.1: "replaced by a domain collection object..."
> Maybe this should be "collective domain object"
> or "aggregate domain object" ?
>
> - Section 3.6.6: The term "heuristic proof" seems like an
> oxymoron.
>
> - Sections 3.10.4, 3.10.5: again, "map" and "map distribution"
> are introduced without definition or
> explanation (or citation). Only the disciples
> of Noel Chiappa/Nimrod know what this means!
> [I am puzzled that Noel was not in group B;
> these sections are straight Gospel According to
> Noel!]
>
> o Confusing Text
>
> - Last paragraph of section 3.2, "Current practice ..."
> Not clear what you are trying to say here.
>
> - Section 3.2.1: Huh??
>
> - Section 3.6.2.2, under "security information" bullet:
> the term "map" suddenly appears here without
> explanation or definition.
>
> - Section 3.6.6, the paragraph "Routing policies are
> compatible if...": it is unclear how "convergent"
> differs from "stable", as in R(17).
>
> Please revise this document according to the above recommendations and
> let us know when it has been made available via internet-drafts.
>
> Also, please note that your document will be removed from our queue
> and treated as a new submission when we receive the new version.
>
> Thank you.
>
> RFC Editor
More information about the irtf-rr
mailing list