ietf
[Top] [All Lists]

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

2014-07-08 01:15:34
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(_at_)nostrum(_dot_)com]
Envoyé : lundi 7 juillet 2014 23:29
À : BOUCADAIR Mohamed IMT/OLN
Cc : 
draft-ietf-6man-multicast-addr-arch-update(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
gen-
art(_at_)ietf(_dot_)org Team (gen-art(_at_)ietf(_dot_)org); 
ietf(_at_)ietf(_dot_)org 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(_dot_)boucadair(_at_)orange(_dot_)com 
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.)

[...]