Last Call Review of draft-ietf-trill-rbridge-extension-04
review-ietf-trill-rbridge-extension-04-genart-lc-campbell-2012-08-10-00

Request Review of draft-ietf-trill-rbridge-extension
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-06-05
Requested 2012-05-31
Authors Donald Eastlake, Anoop Ghanwani, Vishwas Manral, Li Yizhou, Caitlin Bestler
Draft last updated 2012-08-10
Completed reviews Genart Last Call review of -04 by Ben Campbell (diff)
Genart Last Call review of -04 by Ben Campbell (diff)
Assignment Reviewer Ben Campbell
State Completed
Review review-ietf-trill-rbridge-extension-04-genart-lc-campbell-2012-08-10
Reviewed rev. 04 (document currently at 05)
Review result Ready
Review completed: 2012-08-10

Review
review-ietf-trill-rbridge-extension-04-genart-lc-campbell-2012-08-10

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.