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

[Ben Campbell <[e-mail]>]

Version 7 addresses all of my concerns, and is IMO ready for publication.

Thanks!

Ben.

On Jul 8, 2014, at 1:14 AM, <[e-mail]> <[e-mail]> 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:[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.)
>>>> 
>>>> [...]
>>> 
>