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

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" <lear@lear.ch> 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" <lear@lear.ch><mailto:lear@lear.ch> 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 <exec-director@ietf.org><mailto:exec-director@ietf.org> 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) <Glenn.Deen@nbcuni.com><mailto:Glenn.Deen@nbcuni.com> 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 3rd 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" <trustees-bounces@ietf.org<mailto:trustees-bounces@ietf.org>> 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 <exec-director@ietf.org<mailto:exec-director@ietf.org>> wrote:
>
> 
>
>> On 13 Nov 2023, at 13:18, Eliot Lear <lear@lear.ch<mailto:lear@lear.ch>> 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
>>>> RSAB@rfc-editor.org<mailto:RSAB@rfc-editor.org>
>>>> 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
>>> exec-director@ietf.org<mailto:exec-director@ietf.org>
>>>
>
> --
> Jay Daley
> IETF Executive Director
> exec-director@ietf.org<mailto:exec-director@ietf.org>
>

_______________________________________________
Trustees mailing list
Trustees@ietf.org<mailto:Trustees@ietf.org>
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
exec-director@ietf.org<mailto:exec-director@ietf.org>