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

[Stephan Wenger <[e-mail]>]

Hi,

I’m with Joel here.  I also don’t think the great unified theory will work.  I even question whether it would be desirable, and hence go a step further here.

As Joel pointed out, we have different IP terms between IRTF and IETF.  This is not by accident, but by design.  My admittedly somewhat vague recollection regarding the reasons for the differences between IRTF and IETF stream boilerplates is that IRTF and IETF have different missions, and hence their attendees may have different business interests, which is reflected by their preferred IP terms and hence boilerplates.  This. I think, is exactly how things should be.

Without offense to Eliot, I don’t understand why the independent stream is still around except as a historic artifact.  I certainly don’t understand its “mission”, from which I could perhaps infer appropriate IPR terms and the feasibility of alignment of such terms with (comparatively speaking) well defined and understood requirements for IP terms from the IETF and IRTF.

Adjusting well-deliberated terms of the IETF and IRTF for the sake of operational efficiency of the independent stream is IMO the wrong approach.  If people want to see their stuff used in the IETF (or, perhaps, the IRTF), they should stop using the independent stream, and ideally it should be advertised that the two streams are incompatible.  We can, within our set of rules, make accommodations for the occasional legacy case.

Stephan



From: Trustees <[e-mail]> on behalf of Joel Halpern <[e-mail]>
Date: Monday, November 13, 2023 at 06:57
To: Eliot Lear <[e-mail]>, Deen, Glenn (NBCUniversal) <[e-mail]>, Jay Daley <[e-mail]>
Cc: [e-mail] <[e-mail]>, Trustees <[e-mail]>
Subject: Re: [Trustees] [rsab] [EXTERNAL] changes to boiler plate for independent submissions are coming

Let's be clear.  There is already stream-specific boilerplate in I-Ds.  (IRTF drafts have slightly different IPR considerations and rights grants.)

It seems to me, that is the right model.  trying to have a grand unified theory isn't going to work.

Yours,

Joel
On 11/13/2023 9:50 AM, Eliot Lear 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 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" <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
>
> 
>
>> On 13 Nov 2023, at 13:18, Eliot Lear <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
>>>
>
> --
> Jay Daley
> IETF Executive Director
> [e-mail]<mailto:[e-mail]>
>

_______________________________________________
Trustees mailing list
[e-mail]<mailto:[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]<mailto:[e-mail]>






_______________________________________________

Trustees mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/trustees