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.