Hi Ben, An updated version that takes into account your comments is available online: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-06 A diff can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-06.txt Cheers, Med >-----Message d'origine----- >De : mohamed.boucadair@xxxxxxxxxx [mailto:mohamed.boucadair@xxxxxxxxxx] >Envoyé : vendredi 4 juillet 2014 15:45 >À : Ben Campbell >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 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.) >> >>[...]