Re: [nfsv4] AD Evaluation of draft-ietf-nfsv4-mv1-msns-update-03

[Spencer Dawkins at IETF <[e-mail]>]

Hi, David,

On Tue, Feb 5, 2019 at 3:54 AM David Noveck <[e-mail]> wrote:

> > Does this help?
>
> Yes, but I've decided I might as well just include The waiver in -04.
>
> Regarding contacting Spencer S and Mike Eisler, it occus to me that thay
> have already agreed to the granting of BCP78 rights with regard to RFC5661
> since it was published in January 2010 (i.e.way after November 2008).
>  With regard to possible contributions by others, this document was
> published without the waiver, so it appears that, at least at that time,
> there was felt to be sufficient evidence that such permission had been
> granted for all contribution included in RFC5661.
>

Including the waiver works for me, and the working group is copied on our
email, so anyone who has more knowledge about the history than we do has an
opportunity to provide input.

I'm not a copyright genius, but I THINK the key dates aren't when RFC 5661
was published, but when text that appeared in
https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-29 was
contributed (potentially as early as 2005). We ask authors to verify that
they are granting rights to create derivative works when drafts are
submitted, and (at least the last time I did AUTH48 on one of my RFCs)
authors aren't asked to verify those grants again during AUTH48.

This would be a bigger issue if someone wanted to create derivative works
outside the IETF standards process, but as long as NFSv4 is chartered and
is producing standards-track versions of NFSv4, the previous version of the
BCP covered those rights.

So, unless someone enlightens us (either during Last Call or IESG
Evaluation), I think we're good.

Thanks for thinking this through.

Spencer


> I find it hard to conceive of any contribution appearing in
> draft-ietf-nfsv4-mv1-msns-update, which was not either:
> a) first made publicly available after November 10, 2008, or
> b) included in RFC5661.
>
> However, I cannot say definitely that no such contributions exist.
>
> It occurs to me that we have no indication of why, specifically, IDnits
> decided that such contributions might exist, and that trying to get that
> information is unlikly to be worthwhile.
>
> As a result, I will be including the waiver in -04.  After all, the waiver
> says such contributions "may" exist and they indeed might, even though I
> have no idea what they might be.
>
> On Mon, Feb 4, 2019 at 2:38 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> Hi, David,
>>
>> On Sat, Feb 2, 2019 at 8:15 AM David Noveck <[e-mail]> wrote:
>>
>>> > since I'm doing AD Evaluation on a 100-page document that updates a
>>> 600-page document, we can't be surprised that
>>> > I had a few questions
>>>
>>> Actually, I'm only surprised that it was done so quickly.   Thanks.
>>>
>>> > please let me know how you'd like to proceed.
>>> > I'll mark this as Revised ID Required for now.
>>>
>>> I'll provide initial responses below.   If there turns out to be
>>> anything controversial or difficult to resolve, I'll just note the issue
>>> now and discuss it with my co-author.   Based on my initial scan of your
>>> comments, my expectation is that a revised I-D could be provided in one to
>>> two weeks.
>>>
>>> > This popped up from IDnits, and would be worth fixing before Last
>>> Call.
>>>
>>> It seems that not fixing it is not really an option, much as I'd like to
>>> sweep the whole thing under the rug :-(.
>>>
>>
>> Yeah, I agree. Actual fix is further down, but let's see if you need it,
>> first.
>>
>> > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
>>> >     have content which was first submitted before 10 November 2008.
>>> If you
>>> >     have contacted all the original authors
>>>
>>> I'm not clear about the set of people within "all the original
>>> authors".   If this referring to the authors of RFC5661, then it is just
>>> contacting Spencer S and Mike Eisler, in addition to myself.  On the other
>>> hand, some material from RFC3530 may have migrated to RFC5661, which mkes
>>> the poblem more difficult.
>>>
>>
>> So, Spencer D's view of the world is, it's good to ask "original authors"
>> about this sooner, rather than later, because it only gets harder to ask
>> them as time passes (people change contact information, retire, and even
>> die, all of which gets in the way of asking).
>>
>> If you are OK contacting Spencer S and Mike and confirming that they are
>> willing to grant permission as per BCP 78, and asking if there is material
>> from previous RFCs with other authors in RFC 5661, that would be great.
>>
>>
>>> > and they are all willing to grant
>>> >     the BCP78 rights to the IETF Trust, then this is fine, and you can
>>> ignore
>>> >     this comment.
>>>
>>> I looked at BCP78 and it was not very clear what exactly I would be
>>> agreeing to or asking other authors to agree to, beyond what one would
>>> have agreed to before 11/10/2008.   BCP78 does  have a section entitled
>>> "Changes since RFC 3968" but it isn't very helpful.
>>>
>>
>> For the purposes of this discussion, I'm inclined to agree.
>>
>> I believe this is the explanation you're asking about, which is about
>> halfway down the list of changes:
>>
>>    The right to produce derivative works provided by the Contributor to
>>    the IETF Trust is not limited to being within the IETF Standards
>>    Process.
>>
>>
>> So that, if someone wanted to use material from RFC5661 in a document
>> that's not produced within the IETF standards process, the original authors
>> haven't actually given that permission, not least because no one ever asked
>> them for that permission. The current rights granted by authors would allow
>> (for instance) an IRTF research group to include this text in an
>> Experimental RFC.
>>
>> If it turns out that including the pre-RFC5378 disclaimer is more
>> tractable, that's fine, too - the intended RFC Status for this draft is
>> Proposed Standard, which the original authors would have already agreed to.
>>
>>
>>> > If not, you may need to add the pre-RFC5378 disclaimer.
>>> >     (See the Legal Provisions document at
>>> >    https://trustee.ietf.org/license-info for more information.)
>>>
>>> I looked in that document but I couldn't find the text of the needed
>>> disclaimer.
>>>
>>
>> Somewhat unhelpfully, that's in the various versions of the TLP that
>> exist as links on that page. What I'm seeing from the 5.0 version (most
>> recent version) at https://trustee.ietf.org/license-info/IETF-TLP-5.htm,
>> is
>>
>> If an IETF Contribution contains pre-5378 Material as to which the IETF
>> Trust has not been granted, or may not have been granted, the necessary
>> permissions to allow modification of such pre-5378 Material outside the
>> IETF Standards Process:
>>
>> This document may contain material from IETF Documents or IETF
>> Contributions published or made publicly available before November 10,
>> 2008. The person(s) controlling the copyright in some of this material may
>> not have granted the IETF Trust the right to allow modifications of such
>> material outside the IETF Standards Process. Without obtaining an adequate
>> license from the person(s) controlling the copyright in such materials,
>> this document may not be modified outside the IETF Standards Process, and
>> derivative works of it may not be created outside the IETF Standards
>> Process, except to format it for publication as an RFC or to translate it
>> into languages other than English.
>>
>>
>> Does this help?
>>
>> Spencer D
>>
>> > (This one tends to get Discusses during IESG Evaluation)
>>>
>>> I think I can avoid that.
>>>
>>>>