Hi Ben, On Fri, Jun 1, 2012 at 3:18 PM, Ben Campbell <b...@nostrum.com> wrote: > Thanks for the quick response. Further comments inline. I deleted sections > that do not appear to need further discussion. > > Thanks! > > Ben. > > On Jun 1, 2012, at 10:45 AM, Donald Eastlake wrote: > >> 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.) > > I agree there is no conflict--this draft adds details, but doesn't seem to > contradict anything in the RFC. > >> >> However, neither RFC 6325 nor this document can actually actually bind >> the IETF against adopting future standards describing extensions that >> do not conform. > > Certainly. Nothing can do that. The IETF can always update a protocol to > change normative language, no matter how strongly it was stated originally :-) > >> 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. >> > > Assuming the additional details in this draft comprise preferred extension > mechanism, then I think it makes sense to say that somewhere (perhaps a > SHOULD strength), and also mark it as updating 6325. Adding details is still > an update.
OK. >>> -- 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". > > Sure--I mainly mention it to be consistent with the text for "critical" > extensions, since it did use normative language about dropping frames. > >> >>> -- 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 says "Any RBridge receiving a frame with a critical hop-by-hop > extension that it does not implement MUST discard the frame...". Section 2.1 > says "If an RBridge does not implement all critical flags in a TRILL Data > frame, it MUST discard the frame..." These really seem like the same MUST > (i.e, if you updated one but not the other, you would have an ambiguous > state). The same is true for the egress bit. > > I understand that you want to draw the connection between a "critical > extension" and "critical flags", but it's better to avoid having multiple > bits of authoritative text for the same normative requirement. Perhaps it > might be better to say something like "If the RBridge does not implement all > critical flags... it MUST treat the frame as having an unimplemented critical > extension as described in section 2" I'm OK with your suggested wording. >> >>> -- 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? > > Never mind, I misread the sentence. Sorry for the confusion. > >> >>> -- 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. > > On re-reading the paragraph, I can see interpreting it to mean that > incorrectly set flags explicitly do not cause a security problem, which I > agree is reasonable to say in the security considerations. So, never mind :-) > > [...] > > >>> >>> -- 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. >> > > Okay, no problem. > >>> -- 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. > > Okay > > [...] > > >> >>> -- 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. >> > > Okay. I was interpreting it as existing entirely for the IANA > registration--but if you believe it adds value to the "body" of the text, I > am okay with it. > > [...] Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com
