Dear Ben, Thank you for the review. Please see inline. Cheers, Med >-----Message d'origine----- >De : Ben Campbell [mailto:ben@xxxxxxxxxxx] >Envoyé : mercredi 2 juillet 2014 21:10 >À : draft-ietf-6man-multicast-addr-arch-update.all@xxxxxxxxxxxxxx >Cc : gen-art@xxxxxxxx Team (gen-art@xxxxxxxx); ietf@xxxxxxxx list >Objet : Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05 > >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? [Med] Typical encountered issues are listed in section 3: e.g., some implementations do not treat the flag bits as separate bits, this leads in particular to not consider prefixes starting with fffx as RP-embedded. What is the purpose of >redefining them as flags prior to defining the meaning of the flags? [Med] In fact we started by associating a meaning with an unreserved bit (http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-05)... but when that draft went to the IETF LC, it was decided that it is better to clarify first the usage of flag bits + define reserved bits as flag bits. The 6man draft is not overloaded with all these details, hence the generic sentence you quoted in your comment. > > >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..." [Med] Fixed with dedicated sub-sections for each change. > >-- section 3: > >Please expand SSM on first use. [Med] Fixed. > >-- 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. [Med] [ADDRARCH] is not listed in the reference list because this is a quoted text from RFC3306. BTW, [ADDRARCH] is obsoleted by RFC 4291 which is listed in the reference list. I have no problem to add [ADDRARCH] as an informative reference if you think this is helpful for the reader. > >-- 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? [Med] This context of this text is RFC3956: R=1. The text says explicitly the motivation for such setting ", as this is a special case of unicast-prefix based addresses.". I do think the text is clear. >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". [Med] Fixed. Thanks. > >-- 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? [Med] We prefer to leave this point for the RFC Editor. > >-- 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. > [Med] Fixed. Thanks.