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

[Jay Daley <[e-mail]>]

Thanks Glenn

My question was really trying to understand if we can switch our narrative around the author experience from "author starts by picking a stream, which may change in later versions" to "author starts by picking derivative licensing, which may change in later versions as they understand stream requirements".  

It seems to me that the first one suffers from all of our usual problems - you have to be an insider to understand it; it creates silos in our way of doing things; our boilerplate is unnecessarily confusing to readers, and so on.  However, in offlist discussions, the objections have been that this would cause further confusion for authors.

Jay


> On 13 Nov 2023, at 17:38, Deen, Glenn (NBCUniversal) <[e-mail]> wrote:
> 
> Jay and Paul,
>  Going back to basic principles of the IETF IPR, it’s focused on the IETF’s work process which is mainly IESG, but there is parallel focus on IAB, IRTF, and even IST/ISE.
>  The IETF IPR (rfc 5378) is designed for the business of the IETF.   I-Ds come in labelled with IETF BP, I-D’s become WG docs, WG docs become RFCs.    I-Ds can be used in new IETF derivative I-Ds which may or may not become WG docs and RFC, and RFCs can be used in derivative IETF I-Ds and RFCs.    ALL this is in the context of the work of the IETF.   
>  For these purposes, this largely means the activity led by the IESG, and anyone can submit an IETF I-D or a derivative of and IETF I-D even without an IESG activity such as a WG to receive it.       
>  This also different than the way other groups do IPR.  In those groups all documents start out a works of the SDO and so are both deliverately solicited by the SDO and owned by the SDO.
>  In the IETF content, I-Ds do not need to be either solicited by the IETF and they are not (generally) owned by the IETF (Trust) only the granted rights are.
>  Joe off the street can write an I-D about how to wash a dog and submit it to Datatracker as  draft-joe-dogwashing.       When Joe uploads it to the Datatracker, along with the RFC 5378 IETF BP it’s an IETF submission with rights granted to the Trust.  Even if no WG takes up draft-joe-dogwashing, it’s still an I-D under the IETF process, and later Mary can use it to write DRAFT-MARY-CATWG-CATWASHING which can go onto DRAFT-IETF-CATWG-GROOMING and maybe RFC XXYY Washing and Grooming of Cats.    Mary can do this without Joe’s permission because of the derivative rights grant Joe made to the IETF Trust for use in IETF work.
>  On the other hand, the IST is at its core Independent of the IETF work and so the IP Rules associated with IST works are not IETF IPR but instead IST rules.   The cleanest path is an from the start an IST Draft that later becomes and IST RFC.      However, it is not unheard of (and even a little bit of a design choice) that IETF I-D’s that don’t get picked up by an IESG WG can alternatively be directed through the IST path.  This is fine, and all it requires is that the authors choose to additionally add IST IPR rules to the I-D.  Nothing need change text wise in the IETF I-D BUT the licensing boilerplate would need to be updated to have IST IPR.    Importantly, the original IETF I-D with its IETF IPR continues even after this update.
>  So that means that DRAFT-JOE-DOGWASHING-00 submitted to the IETF can be used by Mary for DRAFT-MARY-GENDISPATCH-CATWASHING-00, and Joe can submit an updated DRAFT-JOE-DOGWASHING-01 now with IST Boilerplate and it can go on to become an ISE produced IST RFC.
>  Of note, is that the IST RFC cannot be directly used by the IETF process because its license is not for IETF work, even though the original source DRAFT-JOE-DOGWASHING-00 can be.   
>  The BP is basically the metadata of licensing rights grant from the authors to the appropriate stream/body.    A single document can have distinct rights grants to multiple stream/bodies at the same time which is accomplished by inserting the necessary BP for each into the document version.
>  An important thing to keep in mind as we talk about this topic is that the BP is a rights grant to the Trust for a particular stream  and is not at ownership transfer.   That’s why the Trust nor the ISE/RFC Editor have the authority to just jump a document from one stream’s IPR to anothers.  It needs the authors who hold the right to grant new rights to grant the Trust the rights for the new stream.  
> 
> The way we’ve the above to date by using a narrow rights grant by particular stream using stream appropriate BP for each of IAB, IRTF, IETF and IST and by the appearance of the appropriate BP in the document version upload to DT.
>  -glenn
>  On 11/13/23, 8:30 AM, "Jay Daley" <[e-mail]> 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]> 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]> 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]> 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]> 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$ 
> >>> 
> >>> --
> >>> 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$
>  -- 
> 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]


-- 
Jay Daley
IETF Executive Director
[e-mail]