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.