[Irtf-rr] Changes in draft-irtf-routing-reqs-03

[avri at psg.com]

Hi,

Earlier, I posted the latest notification of the latest version of 
Requirements for Inter-Domain Routing.
.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-03.txt

 From the answers below, I think you will notice 2 things:
- Some of the changes merit further discussion
- Some of the issues still need a response, or perhaps a better 
response.

I will be going over this list during the IRTF RRG meeting on 
Wednesday.  I intend to update the doc after the meeting. After it has 
been posted to this list for a few weeks I will resubmit it To the RFC 
Editor - baring any open issues.

thanks
a.

The following is a draft response to the RFC Editor's comments:

> (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... ;-)

Since this is an non WG  and informational draft, I do not understan
why this will be an issue for the IESG, though of course I expect it 
will
be an issue in any protocol developed to implement any resulting
architecture.  I have, however, accepted the comment and have
added references to the sections where security is discussed.

> (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.
>
> 	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.
>

ANS:
Most of the editorial changes have been accepted and incorporated
into the document.

> (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.
>

ANS:
The suggestion has been accepted.  All capitalization of imperatives
has been eliminated since these words really have no definition in
informational documents.  Additionally since the introduction is
quite specific about all 'requirements' being strong suggestions, the
imperatives have no imperative force in this document.

> 		- You say the architecture MUST be clear, well thought out, ...
> 			(2.1.1)
>
> 			REALLY? How can you determine if you did it?\

ANS:
I think the community at large that reviews any new architecture
will be the ones who need to make this determination.  Expert Reviews, 
rough
consensus,  and running code will be the determinant.

> 		- You say the architecture MUST be modular (2.1.2).\

> 			REALLY? What does that mean, and how do you
> 			know?

ANS:
As the document states this requirement, it is that the architecture
separates the functions, though it does not specifically use the word
'modular'.  I think a review of the architecture will show whether it
has done an effective job of seperating these functions and
capabilities.  We will of necessity, need to rely on expert review to
determine whether this recommendation has been adequately met.

>
> 		- You don't say MUST in section 2.1.3, 3rd bullet 1
> 			(must be slower than Moore's law.)
>
> 			Did you mean to?

ANS:
All capitalized imperatives have been elimnated.  But it stands to
reason that this is a priority.

> 		- 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.

ANS:
The issue is that the architecture, per se, must not be the limitng 
factor.

> 		- You don't say MUST for "No Bad Data" (2.1.9)
> 		  (twice).
>

Well, I have gotten rid of all capitalized imperatives. But, yes, it 
seems very
important to me.

>
> 		- 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.
>

Ans:

Well, I got rid of the capitalized imperative.  The next paragrapgh
goes on to explain that the architecture must be as simple as
possible with a merciless weeding of things that are not absolutely
necessary.

Since this was the product of group A, and the group has since
dissolved, I did not feel I could remove the requirement.  As I do
not personally believe it to be content free, I did add an editor's
note that attempts to explicitly descibe the content of the requirement
as I understand it.


> 		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!)
>

REQUEST: Can someone help me with a citation?

> 		- "One respected network sage" (2.2.3) is Dave Clark, and
> 			we believe he said it in an IETF plenary, probably
> 			around 1991.
>

REQUEST: Can someone help me with a citation?

> 		- References [10] and [14] have formatting errors.

ANS: Fixed

>
> 	o Inconsistencies and duplications
>
> 		- 2.1.7 appears to duplicate the next to last paragraph of
> 			2.1.4.
>

ANS:
Replaced paragrapgh in 2.1.4 with reference to 2.1.7

> 		- The last paragraph of 2.1.7 duplicates 2.2.7.  Suggest
> 		  instead (or in addition): "See also Section 2.2.7".
>

ANS: Replaced paragrapgh in 2.1.7 with a reference to 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.

ANS: Inserted.

> 		- (How) does 2.1.23 differ from 2.1.6?
>

ANS:
     2.1.6 discusses multi-homing while 2.1.23 discusses prefixes.
     While using mutiple prefixes for a topological entity is indeed
     a method for effecting multi-homing, it is not the only reason.
     For example, in renumbering, it is quite possible that prefixes
     might temporarily overlap.


> 		- (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??

ANS:
I beleive the 2.1.28 is more specific then 2.1.24.  One argues for
cooperative anarchy, without specifying how that should be done.
The other is explicit about the allowing multiple levels of
admisitration.

> 		- 2.2.1 appears to contradict 2.1.3.

ANS:
While there is a requirement for scalability, there is no specific
requirement on how this should be done.

> 		- 2.2.8 appears to directly contradict 2.1.22.

ANS:
     2.2.8 indicates that renumbering itself is not the repsonsiblity of
     the routing system.  But it also indicates that the routing
     system must cope with renumbering. 2.1.22 is a way of coping with
     renumbering. The point is that the renumbering itself is still
     not being done by the routing system.

> 		- The title of 2.2.10 is reversed in polarity; suggest
> 			"Backwards Compatibility".

ANS:

     The difference between the group A and group B efforts was that 
group
     A started with a clean state ideology - backward compatabilty was
     not a constraint, whereas group B was required to considered
     backward compatibility.  I think the polarity is correct in this
     case.

> 	o Questions
> 		- It would be useful to define what you mean by "address
> 		  portability" (2.1.14).
>

NOTE: I have not dealt with this one yet.  Suggestions welcome.

> 		- We did not really grok what 2.1.19 meant.  Should
> 		  "integrate with" be "require"?

ANS:
'Integrate with' and 'require' are very different in this case.

To 'integrate with indicates that the information from other routing
     realms, though in the underlying structure, could be used when
     avaialble, but does not indicate that the architecture would
     require them, only that it should accomodate them.

> 		- In 2.2.3, you say "N!". You can't be serious.  How
> 		  about N opinions from N people?

ANS:
In 2.2.2, while it is an obvious hyperbole, i think the meaning is
     that each of N people will have a different and disjoint answer
     in each of N-1 conversations.

> 		- Section 3.2.2, bullet "Potential addition  of a second..."
> 			Why "potential"; isn't IPv6 already a
>     reality?

ANS:
In terms of deployment, not quite yet.  And certainly when this
     section was originally written, it still far from cerrtain.  As
     this document is supposed to reflect the work of groups that have
     closed, I do not see the harm in the 'potential'.  but I have 
removed
     the word potential - though I personally still believe it is a
     potential, though a likely one.

>
> 		- Section 3.2.3.3: What IDR proposal; aren't
> 			you referring to BGP?

Ans:
Yes. and no.  It is the IGP/EGP split in which BGP is the current
     EGP.  It also includes all of the practice that is not explicitly
     part of a protocol but which applies to an architecture of which
     BGP is but one part.

> 		- 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.

NOTE: I have not fixed this one yet.

> 		- Section 3.4.3: what (??!) is a "wayleave"? (A
>     wayleaf?)
>

ANS:
Substituted 'service'.

> 		- 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!

ANS:
Changed

> 	
> 		- Section 3.6.1: "replaced by a domain collection object..."
> 			Maybe this should be "collective domain object"
> 			or "aggregate domain object" ?

ANS:
Substituted 'aggregated domain object'

> 		- Section 3.6.6: The term "heuristic proof" seems like an
> 			oxymoron.

ANS:

Not to argue here for a looser defininiton of proof, I have ammended
     the test to say that there are various means of demonstration and 
proof.

> 		- 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!]

ANS:

While Noel was not in group B, several of the participants had been
part of the Nimrod effort and thus some, but by all means not all.
had absorbed some of the 'gospel'.

In order that the term be clear to non-'disciples', or anyone who does
     not know what a Map distribution protocol is, I have added;
     as defined in ref.07 - which describes to the Nimrod architecture.

> 	
> 	o Confusing Text
>
> 		- Last paragraph of section 3.2, "Current practice ..."
> 			Not clear what you are trying to say here.

ANS:
Text changed to 'the current practice in router design'

>
> 		- Section 3.2.1: Huh??\

ANS:
If I understand the huh's referent:

This section indicates that the definitions of inter domain and intra
     domain do not necessarily map to the current IGP/EGP split, but
     rather to the notion of inside and outside.
It also indicates that the idea is relative, in that the same domain
     can be an inner domain from one perspective but an external domain
     from another perspective.

> 		- Section 3.6.2.2, under "security information" bullet:
> 			the term "map" suddenly appears here without
> 			explanation or definition.
>

ANS:
I think is taken care of by listing a reference for an earlier instance 
of Map

> 		- Section 3.6.6, the paragraph "Routing policies are
> 			compatible if...": it is unclear how "convergent"
> 			differs from "stable", as in R(17).

ANS:
R(17) indicates that the architecture should be stable under a 
requirement for local convergence instead of global convergence.
The paragraph in 3.6.6 is referring to stability on the local basis, 
when local is defined by 'a domain or group of domains'.