Version 7 addresses all of my concerns, and is IMO ready for publication. Thanks! Ben. On Jul 8, 2014, at 1:14 AM, <mohamed.boucadair@xxxxxxxxxx> <mohamed.boucadair@xxxxxxxxxx> wrote: > Hi Ben, > > A pre-5378 boilerplate is now present in -07. Please check this diff: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-07.txt > > Thank you for your careful review. > > Cheers, > Med > >> -----Message d'origine----- >> De : Ben Campbell [mailto:ben@xxxxxxxxxxx] >> Envoyé : lundi 7 juillet 2014 23:29 >> À : 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, >> >> Please see inline (I deleted parts that don't appear to need further >> comment) >> >> On Jul 4, 2014, at 8:44 AM, mohamed.boucadair@xxxxxxxxxx wrote: >> [...] >>>> >>>>>> -- 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." >> >> I think I'm with you for the "old" text, since that is made up of quoted >> text and attributed to the RFCs. But I'm a bit confused by the argument >> that the "new" text is largely the same as the old. That seems to support >> the idea that this draft derives text from those RFCs, which is exactly the >> situation the pre-5378 boilerplate is intended to address. >> >> In any case, I don't think the RFC editor can be expected to resolve the >> question, and the fact that the RFC editor might not bring up the issue >> doesn't mean there is no issue. At this point that responsibility seems to >> lie with the authors and the ADs. >> >>> >>>> >>>> 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.) >>>> >>>> [...] >>> >