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. >> -- 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" > >> -- 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. [...]
