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-trill-rbridge-extension-04
Reviewer: Ben Campbell
Review Date: 2012-05-31
IETF LC End Date: 2012-06-07
IESG Telechat date: 2012-06-07

Note: Since this draft is on the agenda of the IESG Telechat on the same day 
that the IETF last call expires, this review is intended for both purposes.

Summary: 

This draft is almost ready for publication as a proposed standard, but I have 
some clarification questions and comments that should be considered prior to 
publication.

Major issues:

None

Minor issues:

-- section 2, general:

Do the authors assume that all TRILL extensions will follow this spec? Since 
RFC6325 already specifies an extension mechanism, what stops an extension from 
ignoring this spec and doing something different? Does it hurt if they do?

-- section 2, 3rd paragraph from end: "Non-critical extensions can be safely 
ignored."

Is that intended to be normative? (Seems like it should be, since behavior for 
critical extensions is normative).

-- section 2.1, 1st paragraph, last sentence:

Redundant with normative language in previous section.


-- section 2.3, first paragraph: 

Is the first sentence intended as normative?

-- section 6, last paragraph:

No security implications of this are mentioned. Is it really a security 
consideration?

Also, is this more likely to be set incorrectly than all the other things that 
some implementation might screw up, so that it warrants special treatment?


Nits/editorial comments:

-- section 1: 

Please expand TRILL on first mention in the body of the document (i.e. not just 
in the Abstract.)

-- section 2:

Please expand RBridge and IS-IS on first mention.

-- section 2, bullet list, 2nd bullet: " ... which would only necessarily 
affect the RBridge(s) where a TRILL frame is decapsulated"

Does that mean it always affects the decapsulating RBridge but might effect 
transit RBridges as well? 

-- section 2, first paragraph after bullet list: "critical hop-by-hop extension"

I assume this means an extension with the critical flag set? If so, it would be 
more precise to say that.

-- sectio 2.1, 1st paragraph:

I'm a little confused by a citation for "future documents". Do you mean the 
cited document as an example of something that might do this (in which case a 
"for example" would help), or do you mean to say that document will do this?

-- section 2.2, 1st paragraph:

Please expand PDU on first mention.

-- section 2.3, first paragraph: 

s/modifictions/modifications

-- section 5:

Since section 3 is entirely composed of the referenced table, and seems to 
exist mostly if not entirely for the purpose of this reference, why not just 
move the table to the IANA considerations section.


Reply via email to