Re: [rsab] [Trustees] [EXTERNAL] changes to boiler plate for independent submissions are coming

[Joel Halpern <[e-mail]>]

The issue is veyr simple.  The RFCs express the ISE goal (over multiple 
ISEs) that the independent stream have the right to create derivative 
works from Independent Stream documents.  The IETF boilerplate does not 
grant that.  It probably should not grant that.  Thus, to meet the RFC 
stated intention, I-Ds for the Independent stream need to grant 
different rights.  (It seems to me that expecting authors to change the 
boiler plate at the last step in the process is both a bad idea in terms 
of author comprehension and an ineffective process.  So yes, this change 
should apply to I-Ds, not just RFCs.)

Yours,

Joel

On 11/13/2023 11:29 AM, Jay Daley wrote:
> Hi Glenn
>
> Thanks again for the thorough note.
>
> I still don’t understand why a distinction is being made between IETF 
> IPR and IST IPR.  As I understand it, there is only RFC 5378 IPR, 
> which is what RFC 5744 references, with the sole distinction being 
> that the IETF and IST have different rules around derivative 
> licensing.  Wouldn’t this framing simplify this discussion?
>
> Jay
>
>> On 13 Nov 2023, at 16:01, Deen, Glenn (NBCUniversal) 
>> <[e-mail]> wrote:
>>
>> Agree on iterating.
>> I will be clear on my view(s) and the challenges.:
>>    (1)  I do not believe a GRANT UNIFIED THEORY is possible for the 
>> simple reason that not ever IETF I-D submitted is going to want to 
>> give a rights grant to IST nor is every IST I-D submitter going to 
>> want to give a rights grant to the IETF.      So I’m not suggesting 
>> we can or should create this.
>>     Each document instance must have its distinct rights grant 
>> clearly applied to it thought the BP is contains.
>>     To that end, there a 3 case of IPR+BP:
>>                 (1)(a) A document can be an IETF I-D with IETF IPR + 
>> IETF BP
>>                (1)(b) A document can be an IST I-D with IST IPR + IST BP
>>                (1)(c) In theory, I see no reason from a IPR 
>> perspective be both IETF IPR & IST IPR with both BP appearing.
>>                          The IPRs won’t conflict as they are each 
>> distinct rights grants (both to the Trust) but for different Streams.
>>
>>    (2) I accept that we’ve decided to multi-purpose Datatracker to 
>> hold I-D from multiple tracks (so let’s make this work).
>>        (2)(a) The question is how much do we want DT to actually 
>> understand about the IPR for each document.
>>        (2)(b) We can make it ignorant/agnostic, meaning that the IPR 
>> is entirely what is in the applied BP in the
>>                  document – which is sort of the situation today.
>>       (2)(c) However, if there is an intent to add IPR awareness in 
>> DT then things get very complicated since
>>                  there a possibly a DOZEN or more current and 
>> historic IPR combinations that a document may have.
>>
>>    (3) The way DT today makes this work is by assuming the BP in a 
>> document instance/version in the Datatracker
>>          is the correct BP that applies to the document version.
>>                 (3)(a) The change of Doc V1 with IETF I-D IPR + IETF 
>> BP -> Doc V2 with IST IPR + IST BP is not currently managed well.
>>               (3)(b) The change of Doc V1 with IST I-D IPR + IST BP 
>> -> Doc V2 IETF I-D IPR + IETF BP is not currently managed well
>> Assessing what we have today:
>>   (4)  RFC 5744 – provides a basis of the process IPR for the 
>> ORIGINAL I-D submission into IST.       It directs the “Trust” to 
>> create the boilerplate to make this happen and it suggests that this 
>> all ties into RFC 5378 (somehow) as the source of the IPR to apply 
>> but to the IST I-D and ultimately the IST RFC. This not implemented 
>> yet, so:
>>      (4)(a)  We do not have a completed or approved IST BP.
>>    (5) RFC 5378 – provides the IPR policies for IETF (and since we’re 
>> talking about IST it doesn’t mention IST directly.
>>    (6) IETF I-Ds – have 5378 applied upon submission by authors and 
>> have IPR grants to the IETF that is irrevocable by authors  and 
>> non-refusable/non-terminable by the IETF Trust.
>>   (7)  IST I-Ds – should follow 5744, but the 5744 BP never 
>> materialized into a final form and was not applied to IST I-Ds
>>   (8)  Further, a path not considered by 5744 is the movement of IETF 
>> I-Ds with permanent IETF IPR into IST I-Ds.  This is case (3)(a) above.
>> (9) One a document has any IPR applied to it – that version of the 
>> document permanent has that IPR applied to it.  Neither the authors 
>> nor the trust can change this.
>> (10) Authors as full Rights Owners can, but the Trust CANNOT,  grant 
>> new rights to a new Track or to modify current rights in a current Track.
>>         (10)(a)  There is an exception to (10) where the full 
>> copyright ownership is the Trust.
>>
>>          This would be sub-cases for Trust OWNED Documents where:
>>          (10)(a)(i) The full document ownership has been given the 
>> Trust by the author. (the Trust has paper for these)
>>          (10)(a)(ii) The document was ISOC/CNRI copyrighted document 
>> fully owned by ISOC/CNRI and thus contributed to the Trust in 2005.
>> Is there an agreeable non-email tool we can use to hold this?   GDocs 
>> perhaps?
>> -glenn
>> On 11/13/23, 6:51 AM, "Eliot Lear" <[e-mail]> wrote:
>>
>> Glenn,
>>
>> We may need to iterate on this, because the implications of your 
>> argument is a Grand Unified Theory of IPR boilerplate.  Which by the 
>> way doesn't scare me (it's what we have now, but isn't quite right). 
>> The Trust should provide some guidance here as to how to proceed.
>>
>> Eliot
>>
>> On 13.11.2023 15:17, Deen, Glenn (NBCUniversal) wrote:
>>
>>     It’s both and it’s because the IPR applied to a document is both
>>     historically meaningful as much what it says when used to publish
>>     an RFC.   Remember that IP rights grants are irrevocable – by
>>     both the AUTHOR but also the IETF per 5378 and Trust rules.
>>     When an I-D is submitted to the IETF following RFC 5378, the
>>     Authors are making a grant to the IETF/IETF Trust, but on the
>>     other side of this the IETF Trust is accepting an asset that
>>     except through extraordinary (as in I’m not sure it’s ever been
>>     done) action the Trustees nor the IETF can give away.   Remember
>>     the Trustees are allowed to license, but they are also directed
>>     to preserve/protect the IP rights granted to the Trust.
>>     As I think through the transition to moving something from and
>>     IETF Stream to IS it’s not as simple as swapping BP.   The
>>     original grant still applies and should be maintained in the IP
>>     notices.     In this case the BP either needs to have IS BP added
>>     to it.  Alternatively, or a new I-D instance of the same IETF I-D
>>     needs to be created for the IS by the Authors (not the system)
>>     since it’s authors that are making this IS rights grant and not
>>     the datatracker, WG, WG Chair or AD nor the Trust.
>>     Does that make sense for the IETF I-D (RFC 5738) ->. Independent
>>     Stream I-D (RFC 5744)
>>     Note that section 4 of RFC 5744, only talks about I-D submitted
>>     with the intention of being I-S RFCs.  It does not include the
>>     procedure for the above, which is IETF I-D -> IS I-D.
>>     I’m not a fan of the handwaving in RFC 5744 about the “Trust will
>>     fix this with BP” as it doesn’t take into account the proceedures
>>     that Datatracker may apply.     Which I think is what’s causing
>>     some of the issue here in that we are now talking about
>>     DATATRACKER actions versus Author actions using the BP provided
>>     by the Trust.
>>     -glenn
>>     On 11/13/23, 5:59 AM, "Eliot Lear"<[e-mail]>
>>     <mailto:[e-mail]>wrote:
>>
>>     It’s both. The authors must apply rules that are permitted by the
>>     stream.  The tooling should enforce this to avoid late surprises.
>>     Eliot
>>
>>
>>
>>         On 13 Nov 2023, at 14:54, Jay Daley<[e-mail]>
>>         <mailto:[e-mail]>wrote:
>>
>>         Thanks Glenn, that’s very helpful.
>>         Just one question - is it actually the final track that
>>         matters or is it more the final IPR rules that matter?  In
>>         other words, if authors could just specify the IPR rules
>>         rather than the track, would that simplify the problem during
>>         the I-D phase?
>>         Jay
>>
>>
>>
>>             On 13 Nov 2023, at 13:45, Deen, Glenn
>>             (NBCUniversal)<[e-mail]>
>>             <mailto:[e-mail]>wrote:
>>             I think the key issue here is the final Track the I-D
>>             will end in.
>>             The current boilerplate, which is RFC 5378 compliant does
>>             not cover the Independent Track. Which makes sense since
>>             it was designed with the IETF workflow in mind and not
>>             the ISE.
>>             The two cases the Independent Track needs are:
>>
>>             1.I-Ds intentioned for their first submission to the
>>             Independent Track.
>>
>>             2.I-Ds originally intended for IETF tracks, but later
>>             switched by the authors to Independent Track.
>>
>>             There is a 3^rd case, but It’s so rare that we can choose
>>             to ignore, as there are easier ways such as simply
>>             resubmitting as an new IETF I-D
>>
>>             1.Independent Track I-D that is being adopted in the IETF
>>             tracks.
>>
>>             I’d prefer to find a simple path for all of this.
>>             Changing ALL the boilerplate to make everything
>>             Independent Track may not be the right choice as it may
>>             well cause some IPR compliance issues with companies..
>>             Today when people submit I-Ds they are doing so to the
>>             IETF, for the purposes laid out in 5378 and not for use
>>             in the Independent Track.
>>             A change which suddenly expands IETF I-Ds into being
>>             usable by ANYONE as Independent Track documents with the
>>             permission of the authors (and their companies) may be
>>             seen as a big expansion of the IETF’s IP rules.
>>             I suggest that a matrix or table showing the submission
>>             path, the IPR RFC that applies, the boiler plate that
>>             applies and then any transitions from Track to another
>>             would be very helpful in discussing the proposals as I
>>             find email discussions often want to be concise and the
>>             details here very much matter and lead to confusion when
>>             not explicitly discussed in each scenario.
>>             -glenn
>>             On 11/13/23, 5:31 AM, "Trustees"
>>             <[e-mail]> wrote:
>>             The boilerplate in I-Ds needs to roughly match what is in
>>             the RFCs. This is especially the case when it comes to
>>             IPR.  Those choices need to be offered as early as possible.
>>
>>             Eliot
>>
>>             > On 13 Nov 2023, at 14:26, Jay Daley
>>             <[e-mail]> wrote:
>>             >
>>             > 
>>             >
>>             >> On 13 Nov 2023, at 13:18, Eliot Lear <[e-mail]> wrote:
>>             >>
>>             >> Hi Jay,
>>             >>
>>             >>> On 13.11.2023 12:56, Jay Daley wrote:
>>             >>> That only applies to RFCs.  I’ve always understood it
>>             that I-Ds are under the control of the IESG.  Neither of
>>             the two statements from the IESG on I-Ds reference other
>>             streams in any way.
>>             >>
>>             >> No.  As discussed, this will require changes to I-D
>>             boiler plate and, hence, xml2rfc.  It will probably also
>>             impact kramdown-rfc2629. The IESG cannot solely own I-Ds
>>             for this reason (amongst others).
>>             >
>>             > Sorry Eliot, I don’t understand this point.  The tools
>>             implement whatever the rules are.
>>             >
>>             > Jay
>>             >
>>             >>
>>             >> Eliot
>>             >>
>>             >>
>>             >>>
>>             >>> Jay
>>             >>>
>>             >>>>
>>             >>>> I have been working with Glenn and Joel to develop
>>             new draft boiler plate that would carry out the policy of
>>             RFC 5477. I anticipate putting that work before the Trust
>>             sometime around the end of the year.  My hope would be to
>>             submit the work to the RSAB and RPC for approval shortly
>>             thereafter. Once that approval has taken place, I would
>>             plan to work with the RPC and tooling team to effect
>>             necessary changes.
>>             >>>>
>>             >>>> There surely are some corner cases that will require
>>             some consideration, and so I expect an iteration or two
>>             to address those issues as and when they arise.
>>             >>>>
>>             >>>> Eliot
>>             >>>>
>>             >>>> --
>>             >>>> RSAB mailing list
>>             >>>>[e-mail]
>>             >>>>https://urldefense.com/v3/__https://mailman.rfc-editor.org/mailman/listinfo/rsab__;!!PIZeeW5wscynRQ!sYfAyCGhIR8JsbHqTrd9geYCYhDScmPaPusjrpb2kUUSV_HbUut4xvAAtkCWOtIP2DJxc4Vo2ZpQ$
>>             <https://urldefense.com/v3/__https:/mailman.rfc-editor.org/mailman/listinfo/rsab__;!!PIZeeW5wscynRQ!sYfAyCGhIR8JsbHqTrd9geYCYhDScmPaPusjrpb2kUUSV_HbUut4xvAAtkCWOtIP2DJxc4Vo2ZpQ$>
>>             >>>
>>             >>> --
>>             >>> Jay Daley
>>             >>> IETF Executive Director
>>             >>>[e-mail]
>>             >>>
>>             >
>>             > --
>>             > Jay Daley
>>             > IETF Executive Director
>>             >[e-mail]
>>             >
>>
>>             _______________________________________________
>>             Trustees mailing list
>>             [e-mail]
>>             https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/trustees__;!!PIZeeW5wscynRQ!sYfAyCGhIR8JsbHqTrd9geYCYhDScmPaPusjrpb2kUUSV_HbUut4xvAAtkCWOtIP2DJxcy2owEzX$
>>             <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/trustees__;!!PIZeeW5wscynRQ!sYfAyCGhIR8JsbHqTrd9geYCYhDScmPaPusjrpb2kUUSV_HbUut4xvAAtkCWOtIP2DJxcy2owEzX$>
>>
>>         -- 
>>         Jay Daley
>>         IETF Executive Director
>>         [e-mail]
>>
>>
>>
>> --
>> RSAB mailing list
>> [e-mail]
>> https://mailman.rfc-editor.org/mailman/listinfo/rsab
>
> -- 
> Jay Daley
> IETF Executive Director
> [e-mail]
>
>
> _______________________________________________
> Trustees mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trustees