This version looks good to me. Thanks!
Ben. On Jun 3, 2012, at 1:35 PM, Donald Eastlake wrote: > Hi Ben, > > Attached is a version incorporating changes to resolve your comments > and a wdiff against the current -04 version. However, given the > proximity to the IESG tele chat, I do not plan to upload this version > before that call. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] > > > On Sun, Jun 3, 2012 at 9:43 AM, Donald Eastlake <[email protected]> wrote: >> Hi Ben, >> >> On Fri, Jun 1, 2012 at 3:18 PM, Ben Campbell <[email protected]> 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 <[email protected]> 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 >> [email protected] > <re31fftoc.txt><wdiffRE-04vInternal31.html>_______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
