Hi Ben, Please see inline. Cheers, Med >-----Message d'origine----- >De : Ben Campbell [mailto:ben@xxxxxxxxxxx] >Envoyé : jeudi 3 juillet 2014 21:18 >À : BOUCADAIR Mohamed IMT/OLN >Cc : draft-ietf-6man-multicast-addr-arch-update.all@xxxxxxxxxxxxxx; gen- >art@xxxxxxxx Team (gen-art@xxxxxxxx); ietf@xxxxxxxx list >Objet : Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr- >arch-update-05 > >Hi, thanks for the response. I've got some more comments inline, and I >removed sections that do not seem to need further comment. > >On Jul 3, 2014, at 6:20 AM, <mohamed.boucadair@xxxxxxxxxx> ><mohamed.boucadair@xxxxxxxxxx> wrote: > >[...] > >>> 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. >> > >I understood those issues to motivate the clarifications on ff1. But if >they explain why some of the reserved space is updated to be ff2, then I >missed it. > > [Med] see below. >> 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. > >It would be good to mention that in the draft as part of the motivation. It >doesn't need a lot of detail, but a couple of sentences would make it >easier for a reader to understand the reasons for defining ff2. [Med] Ok, will add some text. This text will also address the previous comment. > >[...] > >>> >>> -- 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. >> > >I think it might be helpful, but on further reflection, I think it probably >does no real harm to leave it as is. It might be better to simply add a >line somewhere nearby to point out that [ADDRARCH] refers to the reference >in that RFC, not this document, and that it has been since obsoleted. [Med] OK, added a note as suggested. > >>> >>> -- 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. > >I understand that is the intent, but I think the text can be read >otherwise. The old text unambiguously made the second sentence dependent on >the first; the new text does not. > [Med] I added "Then" to the new text. >> >>> 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.) >>> > >[...] > >>> -- 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. >> > >Do you mean that you prefer to leave the _decision_ to the RFC Editor, or >that you recognize the pre-5378 boilerplate is needed, but would like the >RFC editor to insert it? [Med] We don't think a disclaimer is needed because we quote old text + the new one is largely the same. If the RFC editor re-raises the point, we will clarify our position and then discuss. This is what I meant by " leave this point for the RFC Editor." > >If the former, The RFC editor will not have the background about the pre- >5378 text needed to make that call. That's the responsibility of the >authors. If there's text from pre-5378 IETF documents included, and the >current authors have not verified that all authors of the original text >agree to the BCP 78 and 79 terms, then the pre-5378 boilerplate needs to go >in. This is important; getting it wrong involves misrepresentation of the >license terms. > >If the latter, then the draft needs some directive to the RFC editor to add >the boilerplate. (But keep in mind that the pre-5378 boilerplate >requirement applies to all contributions. That is, I-Ds as well as RFCs -- >so it's important to get this right in the _draft_, not just the final >RFC.) > >[...]