Hi Ben, Thanks for your review. See responses below.
On Thu, May 31, 2012 at 6:08 PM, Ben Campbell <b...@nostrum.com> wrote: > 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? I am not aware of any conflicts between this draft and RFC 6325. RFC 6325 provides the broadest header option framework, for example specifying the field for the length of the options area and the initial two critical summary bits. This document fills in the structure and allocation mechanism of the remaining bits in the first 4-byte word of the options area, consistent with and repeating some material from RFC 6325, but leaving specification of the remainder of the options area for future documents, which should be consistent with both RFC 6325 and this document. (For example, some future version of draft-ietf-trill-rbridge-options.) However, neither RFC 6325 nor this document can actually actually bind the IETF against adopting future standards describing extensions that do not conform. If future changes do not follow RFC 6325 or this document, for example changing the location or interpretation of the option length field in the TRILL Header or changing the interpretation of the critical summary bits in the first word of the options area, then this would break hardware and software implementations that depend on RFC 6325 and/or this document. But I trust the IETF to adhere to its usually high standards for backwards compatibility. Perhaps this draft should, in the first page header, say "Updates: 6325", not in the sense that it makes a change but in the sense that it fills in more details. > -- 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). I think of it as more like the definition of "non-critical". > -- section 2.1, 1st paragraph, last sentence: > > Redundant with normative language in previous section. ? There is a normative requirement to discard frames with any unimplemented critical hop-by-hop options present, which might be thought to require examination of all options (something manifestly impossible since the format of options beyond the first word of the options area is not yet normatively specified). The sentence to which you refer just clarifies that testing the appropriate crtical summary bit(s) in the first word of the options area, if that word is present, is all that is required. > -- section 2.3, first paragraph: > > Is the first sentence intended as normative? Yes. When one is describing part of a protocol and you say that some particular contiguous block of bits is some particular field (and then possibly describe the sub-structure of that field) isn't that always 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? I tend to think that a discussion of what happens if bits are corrupted or incorrectly set is something reasonable for the Security Considerations section, although it could be elsewhere. The second paragraph/sentence of this section says that security considerations for any bits in the first word of the options area will be in the document specifying those bits. This document specifies the critical summary bits and the RBridge Channel Alert bits so there is text on both of those in its Security Considerations Section. > Nits/editorial comments: > > -- section 1: > > Please expand TRILL on first mention in the body of the document > (i.e. not just in the Abstract.) Sure. And all the other acronym expansions requested below are fine so I won't respond individually to them below although I agree with them. > -- 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? Yes. > -- 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. This draft was split out of a more general draft that covered extensions in general. The three paragraphs after the bullet list on critical / non-critical extensions apply to all extensions as well as the flag bits in the first word of the options area. So this means critical header extensions flags and any other types of critical options specified in the future. > -- section 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? Yes, the cited work-in-progress references are examples. I'm fine with adding "for example". > -- section 2.2, 1st paragraph: > > Please expand PDU on first mention. > > -- section 2.3, first paragraph: > > s/modifictions/modifications OK. Thanks. > -- 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. (Looking at Section 3, I believe the reference there to the IANA Considerations Section should be to Section 5 rather than Section 6.) I guess I don't actually see any problem with the current document structure that I think flows better for someone reading it from the start. I suppose it imposes a tiny burden on someone who is just looking at the IANA Considerations Section. I don't see why it would be better to make it a tiny bit easier for someone just looking at the IANA Considerations Section while imposing a tiny burdne on those reading through the document from the start. Hope the above responses help with the clarification, Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art