RE: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05

[<[e-mail]>]

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:[e-mail]]
>Envoyé : lundi 7 juillet 2014 23:29
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [e-mail]; gen-
>[e-mail] Team ([e-mail]); [e-mail] 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, [e-mail] 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.)
>>>
>>> [...]
>>