Re: Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
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
Re: Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
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: ...
Re: Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
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
Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
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.
