Subject: Hand-off agreements, when work is brought into the IETF

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Sep 2017 07:43:38 -0700

G'day,

When outside work is brought into the IETF, it is typical to make a 
formal agreement. between the IETF and the originating organization.

It makes the hand-off explicit, sets any constraints on the handoff, and 
sets any constraints on the efforts of the initial working group.  (The 
constraints can range from 'only bug fixes' to 'use the existing work 
merely as conceptual input'.)

The first such IETF agreement was for the underpinnings of NFS:

    An Agreement between the Internet Society and Sun Microsystems, Inc.
    in the Matter of ONC RPC and XDR Protocols

    https://www.rfc-editor.org/rfc/rfc1790.txt

Another one, 3 years later, was for NFS itself.

I cannot find the set of such agreements on the IETF web site, nor as 
other RFCs.

Does anyone have a pointer to the set of these agreements?

Thanks.

d/

ps. my initial focus was to find the agreement for vcard/vcalendar, but 
the search produced the larger question.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Sep 2017 10:53:44 -0400

Dave:

Also, when change control is fully given the the IETF, we have seen the original work published as an Informational RFC that includes a statement that any future versions will be published by the IETF.

RFC 8018 is an example.  It says:

   This document represents a republication of PKCS #5 v2.1 from RSA
   Laboratories' Public-Key Cryptography Standards (PKCS) series.  By
   publishing this RFC, change control is transferred to the IETF.

Since full change control was transferred, that is there are no constraints, the statement in the RFC was considered sufficient.

Russ

> On Sep 7, 2017, at 10:43 AM, Dave Crocker <[email-masked]> wrote:
> 
> G'day,
> 
> When outside work is brought into the IETF, it is typical to make a formal agreement. between the IETF and the originating organization.
> 
> It makes the hand-off explicit, sets any constraints on the handoff, and sets any constraints on the efforts of the initial working group.  (The constraints can range from 'only bug fixes' to 'use the existing work merely as conceptual input'.)
> 
> I cannot find the set of such agreements on the IETF web site, nor as other RFCs.
> 
> ps. my initial focus was to find the agreement for vcard/vcalendar, but the search produced the larger question.
> 
> -- 
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Sep 2017 07:57:29 -0700

> Also, when change control is fully given the the IETF, we have seen the original work published as an Informational RFC that includes a statement that any future versions will be published by the I…

Publishing the pre-IETF work is common, though of course not required.

However there appears to be no documented guidance for hand-off 
agreements and no repository for the set of existing agreements.  This 
is in contrast, for example, to the IPR statements repository.

d/

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 7 Sep 2017 11:41:32 -0400

there is a form that can be used for copyright assignment - not quite the same thing as IPR assignment (like the Sun
agreement was) 

maybe that can be of help

https://iaoc.ietf.org/documents/Changecontrolcopyrightassignment05-31-2015.htm

Scott

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Sep 2017 11:54:47 -0400

> On Sep 7, 2017, at 10:57 AM, Dave Crocker <[email-masked]> wrote:
> 
> However there appears to be no documented guidance for hand-off agreements and no repository for the set of existing agreements.  This is in contrast, for example, to the IPR statements repository.

I am unaware of such a repository, but the point I was trying to make is that in some cases the hand-off text is in an RFC, not a separate document.

Russ

---

From: John C Klensin <[email-masked]>
Date: Sun, 10 Sep 2017 22:23:27 -0400

I wonder how far people think hand-off agreement should be
pushed.  For example, there have been several cases of a
protocol being sorted out in what appeared to have been an ad
hoc organization or other group and then brought to the IETF as
an already finished and already deployed product with
willingness to transfer formal change control to the IETF but
significant, if informal, resistance to changes.  Do you think
we need formal handoff agreements for those cases?  I think
that, in general, we haven't gotten them and that those cases
outnumber the ones where we've had formal agreements and, in
some cases, baseline or prior work informational RFCs.

    john

--On Thursday, September 7, 2017 07:57 -0700 Dave Crocker
<[email-masked]> wrote:

>> Also, when change control is fully given the the IETF, we
>> have seen the original work published as an Informational RFC
>> that includes a statement that any future versions will be
>> published by the IETF.
> 
> 
> However there appears to be no documented guidance for
> hand-off agreements and no repository for the set of existing
> agreements.  This is in contrast, for example, to the IPR
> statements repository.

---

From: Eric Burger <[email-masked]>
Date: Tue, 12 Sep 2017 05:57:09 -0400

Smells like a solution looking for a problem. I could see an informational document explaining what change control means, but do we really have a series of issues that needs solving?

> On Sep 10, 2017, at 10:23 PM, John C Klensin <[email-masked]> wrote:
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Sep 2017 08:39:50 -0400

Eric,

That is exactly the issue I was trying to tease out, i.e.,
whether there is a real problem in this area or, at the other
extreme, whether there is just a quest for more rules,
procedures, and databases.  In particular, the cases I think may
be the most problematic are not addressed at all by the
procedures we have used in the past, so I question making those
procedures more systematic without addressing those problem
cases.

   john

--On Tuesday, September 12, 2017 05:57 -0400 Eric Burger
<[email-masked]> wrote:

> Smells like a solution looking for a problem. I could see an
> informational document explaining what change control means,
> but do we really have a series of issues that needs solving?
> 
>> hoc organization or other group and then brought to the IETF
>>...

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Sep 2017 09:37:03 -0400

> significant, if informal, resistance to changes.  Do you think

I think that we need different handoff agreements for work that comes
to the IETF earlier (change welcome) and resistance to change.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 Sep 2017 09:51:49 -0400

> to the IETF earlier (change welcome) and resistance to change.

Having been through this process several times, a few as an
author/contributor, and one as an AD, it is very helpful to have the
guidelines that are in place already and a little flexibility.  Once
legal from the contributing organization gets involved, they may have
their own requirements.  We've accepted documents that have and have
not transferred change control (as has been stated already) and being
able to work through the options has led to successful contributions.

Russ already named the PKCS documents.  OVAL from DHS was another
somewhat recent one that transferred change control.  This document
does need revision and has been picked up by the SACM working group.
It's been implemented by about 50 vendors, but at this phase it in't
lifecycle, it needs some fixing.

Making sure we don't create too many hurdles is important.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Sep 2017 11:04:59 -0400

Kathleen Moriarty <[email-masked]> wrote:
    > Russ already named the PKCS documents.

So, when we adopted PKCS, we adopted it in order to be able to maintain it.
We didn't have any intention of changing it.

Often we adopt documents *with* the intention of changing it, yet the
people bringing the work in, don't understand that.

{And, in some ways, we don't so much adopt PKCS, as much as we formalized
ownership over an abandoned child we had rescued.  The distinction is
important because there were no proponents that came along with the documents}

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Sep 2017 11:15:37 -0500

Kathleen,

On 9/12/2017 8:51 AM, Kathleen Moriarty wrote:
> guidelines that are in place already

Going back to my original posting:

    What guidelines do you believe exist and where are they documented?

    How is someone supposed to find those guidelines?

    How does someone see the history of agreements that were formulated, 
as further guidance about what the IETF arranges?

> We've accepted documents that have and have

This is confusing, in several ways.  First, historically the IETF always 
insisted on taking change control before agreeing to work on/standardize 
a specification.  The only constraint on this, historically, was on the 
original round of work, but with no constraints on later work.  So this 
sounds like an extremely basic policy got changed somewhere along the way.

It also suggests that the IETF has sometimes become a subcontractor for 
some other group (that retains change control.)

Perhaps you are drawing a distinction between 'bug fixing' versus 
'changing', but again, historically that has only been a constraint on 
the first round of effort, not later IETF work on the specification.

Please clarify.

d/

Apparently

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Sep 2017 12:21:22 -0400

--On Tuesday, September 12, 2017 09:51 -0400 Kathleen Moriarty
<[email-masked]> wrote:

>...
> Russ already named the PKCS documents.  OVAL from DHS was
> another somewhat recent one that transferred change control.
> This document does need revision and has been picked up by the
> SACM working group. It's been implemented by about 50 vendors,
> but at this phase it in't lifecycle, it needs some fixing.

To be a little more specific, how would you categorize something
like DMARC which came to IETF already deployed, with some
cautions about making any significant changes, but with the
expectation that the IETF would clean up the mess (of course,
others, especially those involved before it was brought to the
IETF, might characterize things differently than I do).

> Making sure we don't create too many hurdles is important.

Indeed.  IMO, the biggest danger in discussions like this is
that we will end up creating procedures and rules that make
doing the right thing for a particular case very painful and/or
time-consuming.

  best,
    john

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 Sep 2017 12:30:48 -0400

Hi Dave,

>From my experience, BCP 78 & 78 are the usual references offered as a
starting point for legal representatives to review.  Then if anything
is a little different, the trust is asked for advice and sometimes it
goes to legal for discussion and clarification.

>    How is someone supposed to find those guidelines?

They ask a chair or AD seems to be the usual path.  These are things
people usually want to talk about and don't happen too often, so the
conversation is worth the effort.

>
>    How does someone see the history of agreements that were formulated, as
> further guidance about what the IETF arranges?

There are many with differing outcomes, so this may not be helpful,
IMO.  We need some flexibility, well, because lawyers.

> insisted on taking change control before agreeing to work on/standardize a
> specification.  The only constraint on this, historically, was on the

That's not true.  The PKCS series was published without handing over
change control until very recently.  See
https://tools.ietf.org/html/rfc3447 as an example.

>
> It also suggests that the IETF has sometimes become a subcontractor for some
> other group (that retains change control.)

Or a publisher of well-known and deployed standards.  Yes, that has
happened and worked out just fine as RSA had the motivation to amend
the documents as needed and contribute the updates.  Times have
changed and they decided to hand over change control on the remaining
documents.  There may be other examples, I am just well versed in this
set of examples.

> 'changing', but again, historically that has only been a constraint on the
> first round of effort, not later IETF work on the specification.

See above.

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Sep 2017 15:34:03 -0400

Michael:

It depends on which PKCS document.  I am unaware of any plans for updates to PKCS#1, but the IETF has made updates to PKCS#7 and PKCS#8.  See RFC 5652 and RFC 5958, respectively.

Russ

> On Sep 12, 2017, at 11:04 AM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Sep 2017 14:58:26 -0500

Kathleen, thanks for the followup...

> goes to legal for discussion and clarification.

My original note did use the term "formal agreement" but was not focused 
on IPR legalities, per se.

My note listed explicitly: "any constraints on the handoff, and sets any 
constraints on the efforts of the initial working group.  (The 
constraints can range from 'only bug fixes' to 'use the existing work 
merely as conceptual input'.)"  BCP 78 has to do with IPR and not the 
procedural kinds of issues I raised.

> They ask a chair or AD seems to be the usual path. 

This presumes that everyone in such positions is equally knowledgeable 
on such matters, and handles such queries in the same fashion, while of 
course neither is true.  So, really, this means that the entire process 
is entirely ad hoc, each time, ensuring a minimum of consistency.

  These are things
> conversation is worth the effort.

The fact that it doesn't happen very often -- though really it happens 
with some regularity -- ensures that each person contacted will have to 
invent/guess how to handle it.

> IMO.  We need some flexibility, well, because lawyers.

Alas, the question I asked had nothing to do with lawyers. It had to do 
with arranging for work to be done.

> https://tools.ietf.org/html/rfc3447 as an example.

The IESG writeup for this document includes:

    "This document has been reviewed in the IETF but is not the product 
of an IETF Working Group."

Perhaps there is some confusion happening here, about the difference 
between being published as an RFC vs. being processed by the IETF, and 
especially invoking an IETF task, typically as a working group?

When has the IETF operated a working group that modified a specification 
the IETF did not have change control over?

> Or a publisher of well-known and deployed standards.

Again, the question was not about RFC publication but about IETF work on 
a specification.

d/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Sep 2017 16:29:11 -0400

Russ Housley <[email-masked]> wrote:
    > It depends on which PKCS document.  I am unaware of any plans for
    > updates to PKCS#1, but the IETF has made updates to PKCS#7 and PKCS#8.
    > See RFC 5652 and RFC 5958, respectively.

Thanks for making my point!

RFC2315 was, I think, a direct adoption of PKCS7 1.5, without attempts to
change it.  We later updated it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [