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

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

Hi, David,

I saw that you've submitted -04, and the diffs work for me. Do you have any
other changes, before Last Call?

Thanks,

Spencer

On Tue, Feb 5, 2019 at 7:18 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

> 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.
>>>>
>>>>>