Fwd: draft-irtf-routing-reqs-02.txt

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 <[email protected]>
> Date: 10 maj 2004 23.09.10 MET
> To: [email protected], [email protected], [email protected]
> Cc: RFC Editor <[email protected]>
> 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

_______________________________________________
irtf-rr mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/irtf-rr