ietf
[Top] [All Lists]

Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt

2010-10-06 14:59:58
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-isis-genapp-03.txt
Reviewer: Ben Campbell
Review Date: 05 Oct 2010
IESG Telechat date: 07 Oct 2010

Summary:

The draft is almost ready for publication as a proposed standard, but I have 
some concerns that I think should be addressed first.


Major issues:

-- This draft creates an "expansion" code point in an IANA registry, where the 
expansion registration requirements are weaker than those of the parent 
registry. This always makes me nervous, as it opens the window for end-runs 
around the registration requirements of the parent. 

In this particular instance, the parent registry policy is "expert review" 
while the proposed expansion registry policy is "specification required". This 
draft puts normative requirements on the content of the required 
specifications, and makes additional non-normative statements about the 
intended use of the GENINFO code point. This implies to me that the review 
process needs to do more than determine that sufficient specification exists. 
Rather, it needs to determine that the criteria in this draft are met by that 
specification. Therefore, I think that it would be appropriate for the GENINFO 
registry to use the "expert review" policy. 

Minor issues:

-- section 4.2, 2nd paragraph: "Where this is not possible, the two affected 
LSPs SHOULD be flooded as an atomic action"

Any reason that this is not a MUST, since it seems like the safety-net behavior 
for when the aforementioned SHOULD is not  possible to follow?

-- Section 4.3: "When information in the two GENINFO TLVs conflicts i.e there 
are different settings for a given attribute, the procedure used to choose 
which copy shall be used is undefined."

Should their be normative requirement not to create this undefined condition in 
the first place?



-- Security Considerations:

This seems too lightweight. Is it impossible for GENINFO applications to 
include sensitive information? Are there no security guidelines that should 
apply to GENINFO application specifications?

Even if the answer is that the underlying IS-IS protocol provides sufficient 
security for any reasonable use of the GENINFO code point, it would be worth 
saying that explicitly.

Nits/editorial comments:

-- section 2

Please expand IS-IS and PDU on first mention.

-- section 6, last paragraph:

Expected/desired by whom?

-- Outdated reference for draft-ietf-isis-mi

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf