Re: Last Call: draft-fenner-zinin-rtg-standard-reqts-01.txt

["Thomas D. Nadeau" <[e-mail]>]

	Alex/Bill,

	A comments on the draft below.

1) In section 4.1 you have the following:

   	 2.  A Management Information Base (MIB) must be written for the
       	 protocol.  The MIB does not need to submitted for Proposed
       	 Standard at the same time as the routing protocol, but must  
be at
       	 least an Internet Draft.

	I suggest that this requirement be a little stronger in
	that the document must "be at least a Working Group
	Draft".   Just being a draft doesn't mean that it is
	going to be an agreed/inter-op standard some day. Well,
	neither does a WG draft, but it has a better chance of
	being one. Also, if you just require it to be an ID,
	how do you handle say individual submissions that might
	conflict/compete with a WG document and so forth?  I
	think just requiring a WG draft is cleaner.


2) Further along in the same section the following statement
	appears, which to me seems far too open-ended for
	my tastes in that it gives far too much latitude for
	an IESG review to kill or delay a protocol based on
	personal tastes for what constitutes "set forth
	explicitly".

	3.  The security architecture of the protocol must be set forth
        	explicitly.  The security architecture must include mechanisms
        	for authenticating protocol messages and may include other  
forms
        	of protection.

	I am also concerned by the second sentence,
	"...may include other forms".  I am not a security expert,
	but to me, it seems more straight forward if we require
	the aforementioned "security architecture", to contain
	at least one method of each:
		
		- message authentication
		- replay protection
		- message encryption
		- message filtering (to help prevent DOS attacks)



3)   I would just say "At least two independent..." here

	4.  Two or more independent interoperable implementations must exist.

	Also, is this for *any* standards track documents or just
	protocol specifications? Namely, does this impact MIBs, PIBs, XML
	schemas, etc... out of a WG?

4)    Further down, point #5 seems a bit specious to me. Do you mean
	that they have been tested within a vendor's test lab or
	in somewhere else? I would say that an independent test such
	as the ones done at GMU or UNH might be what you are looking for
	here.  Also, HOW do you mean for them to be tested? Above you
	talk much about your concerns over scale testing, but the statement
	in #5 just says "tested".  Please be more specific.


	5.  There must be evidence that the major features of the protocol
        have been tested.


5) Section 4.2 gives me similar concerns as above. Specifically the
	security requirement in #3:

	   3.  The security architecture of the protocol must be set forth
        explicitly.  The security architecture must include mechanisms
        for authenticating protocol messages and may include other forms
        of protection.

6) Further in 4.2 I have similar concerns in the testing section:

	   5.  There must be evidence that all features of the protocol have
        been tested, running between at least two implementations.  This
        must include that all of the security features have been
        demonstrated to operate, and that the mechanisms defined in the
        protocol actually provide the intended protection.

	How should this be demonstrated?

7) Further in 4.2 you have:

    4.  Two or more interoperable implementations must exist.  At least
        two must be written independently.

	Please be more specific about what "written independently"
	means. I *think* you mean that the code is not
	derived from the same code base (i.e.: purchased code or
	two divergent code trains within a single vendor), but
	please be specific anyway.


8) Further in 4.2 you have:

    6.  There must be significant operational experience.  This must
        include running in a moderate number routers configured in a
        moderately complex topology, and must be part of the operational
        Internet.  All significant features of the protocol must be
        exercised.  In the case of an Interior Gateway Protocol (IGP),
        both interior and exterior routes must be carried (unless  
another
        mechanism is provided for the exterior routes).  In the case  
of a
        Exterior Gateway Protocol (EGP), it must carry the full
        complement of exterior routes.

	I think you should also include as part of the operational
	experience, some statement about the MIBs being used/tested
	and found to be useful. This is the phase where you might
	go back and refine them, so its important that this be included.
	In fact, you might also want to include them explicitly
	as part of the interop statements above.


9) Under section 5.  Submitting, I would like you to consider
	a time limit for the processing of documents both by
	the WG and the IESG review process.  Specifically,
	if you are going to put more burden on the WG and
	document editors to produce better specifications,
	I don't see why it is not appropriate to also put
	more stringent review guidelines on the review
	process.  All too often, documents seem to be lost
	in document review for (literally) a half of a year or
	more.  I suggest that we do something like say
	that if a document has been offered for review to the
	IESG or the RTG Area Dir review, and no answer has been
	given in 6 months, that the document proceed to the next
	phase.

10) 5.4:

    4.  A pointer (e.g.  URL) to the implementation and interoperability
        report previously submitted to the IETF secretariat.

	Shouldn't this be an IETF RFC or somewhere that can be
	solidly referenced? References to URLs can come and go,
	right?  I would say a fixed copy of the interop report
	is what you are looking for.

11) Later in 5.5:

    5.  A pointer to the corresponding MIB document with an explanation
        of how the MIB maturity requirement has been satisfied, or an
        explanation of why no MIB modifications are required to support
        functionality described in the Technical Specification.

	I am unclear on what the "MIB maturity requirement" is;
	can you be more specific or refer to a specific section
	in the document?


	--Tom









> ----- Original Message -----
> From: "Alex Zinin" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, February 16, 2006 6:02 PM
> Subject: Last Call: draft-fenner-zinin-rtg-standard-reqts-01.txt
>
>
>> This is to start a Routing Area-wide two-week Last Call on this  
>> document
>> for submission to the IESG for publication as BCP. The Last Call  
>> ends on
>> March 2nd, 2006.
>>
>> The document is available here:
>>
>>
> http://www.ietf.org/internet-drafts/draft-fenner-zinin-rtg-standard- 
> reqts-01.txt
>>
>> Abstract:
>>
>>>    This document provides guidance for the advancement of the
> protocols
>>>    produced within the IETF Routing Area.  It places implementation
> and
>>>    interoperability constraints on protocols earlier in the  
>>> standards
>>>    process than RFC 2026, based on RFC 2026's provision that the  
>>> IESG
>>>    may require implementation and/or operational experience prior to
>>>    granting Proposed Standard status to a specification that
> materially
>>>    affects the core Internet protocols or that specifies behavior  
>>> that
>>>    may have significant operational impact on the Internet.
>>>
>>>    We also discuss the applicability of these rules to protocols and
>>>    their extensions.
>>
>>
>> -- 
>> Alex
>> http://www.psg.com/~zinin
>>
>>
>> _______________________________________________
>> routing-discussion mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/routing-discussion
>>
>>

_______________________________________________
routing-discussion mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/routing-discussion