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 resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-6man-multicast-addr-arch-update-05 Reviewer: Ben Campbell Review Date: 2014-07-02 IETF LC End Date: 2014-07-02 Summary: This draft is almost ready for publication as a proposed standard. I have a few comments that I think should be considered prior to publication. Major issues: None Minor issues: -- Section 2 I'd like to see more motivation for the creation of ff2. The text says it "... allows addresses to be treated in a more uniform and generic way, and allows for these bits to be defined in the future for different purposes..." That seems pretty vague to me. Can you offer specifics on what problem is being solved here, and how you expect this new flags to be used? Most importantly, are there likely to be interoperability issues for things implemented prior to the definition of these? What is the purpose of redefining them as flags prior to defining the meaning of the flags? Nits/editorial comments: -- general: I found it visually difficult to tell when proposed update text ends, and additional text of _this_ document continues. Some way of visually separating those would be helpful. For example, in the first "new" section of 4.1, there's no visual distinction between between "Flag bits denote both ff1 and ff2" and "This document changes..." -- section 3: Please expand SSM on first use. -- section 4.1, "old" It would be nice to include a reference for [ADDRARCH]. I realize it's an artifact of the quoted text, but I think it's still worth a [perhaps informational] reference. -- section 4.2, 2nd "new" proposed text: " P MUST be set to 1, and consequently T MUST be set to 1 ..." Is this intended to be for all multicast addresses, or just those with R=1? The proposed text can be read to mean the former, but the old text seems to mean the latter (due to the word "Then" which is dropped from the new text.) " This implies that for instance prefixes ff70::/12 and fff0::/12 are embedded RP prefixes." I assume you mean "...,for instance, prefixes..." (with commas). Otherwise I found myself wondering what was meant by an "instance prefix". -- idNits complains about the lack of a pre-5378 disclaimer boilerplate. I found a discussion in the 6man archives ( http://www.ietf.org/mail-archive/web/ipv6/current/msg20838.html ) indicating the authors preferred not to contact all possible authors of pre-5378 text. Doesn't that mean the draft should carry the boilerplate? -- section 6: " Security considerations discussed in [RFC3956], [RFC3306] and [RFC4291] MUST be taken into account." That's kind of an odd application of 2119 language. What does the MUST apply to? I assume it doesn't apply to implementations. I suggest restating the sentence in active voice and/or removing the 2119 language. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
