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.) >>> >>> [...] >>