Subject: Status of this memo

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Apr 2021 14:24:54 +1200

I don't what made this click in my brain now rather than 20 years ago, but think about this extract from our I-D boilerplate**:

"Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts."

That's actually internally inconsistent and if the first sentence is quoted without the second, it is actively misleading when (say) an IRTF draft is concerned.

Shouldn't those two sentences be combined into a more accurate single sentence?:

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF) or of other associated groups or individuals.

**The exact wording of the boilerplate has changed since 20 years ago, but the problem has always existed.
  
Regards
   Brian Carpenter

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Apr 2021 22:27:11 -0400

+1

He's right you know

On Mon, Apr 26, 2021 at 10:25 PM Brian E Carpenter <
[email-masked]> wrote:

> I don't what made this click in my brain now rather than 20 years ago, but
> think about this extract from our I-D boilerplate**:
>
> "Internet-Drafts are working documents of the Internet Engineering Task
> Force (IETF). Note that other groups may also distribute working documents
> as Internet-Drafts."
>
> That's actually internally inconsistent and if the first sentence is
> quoted without the second, it is actively misleading when (say) an IRTF
> draft is concerned.
>
> Internet-Drafts are working documents of the Internet Engineering Task
> Force (IETF) or of other associated groups or individuals.
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Apr 2021 10:54:52 +0300

Hi,

> Internet-Drafts are working documents of the Internet Engineering Task Force (IETF) or of other associated groups or individuals.

thanks for the suggestion, Brian. I agree that this would be a clarification. I'll bring it up with the IESG.

Thanks,
Lars

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 27 Apr 2021 10:28:57 +0200 (CEST)

> Il 27/04/2021 09:54 Lars Eggert <[email-masked]> ha scritto:
> 
>  
> Hi,
> 

Was there ever any discussion of adopting a more specific formal name for IETF I-Ds, e.g. "IETF draft" ("IRTF draft" etc.)? "Internet-draft" could stay as a rarely used generic umbrella term, but if more precise terms come into common use, clarity will gain a lot. 

I am also thinking of the difference between adopted IETF drafts and individual submissions; that was completely lost on me until my first several months of active participation, and I am sure that almost all Internet developers and engineers out there miss it too, with the obvious consequence that any "Internet draft" is taken as an official IETF-sanctioned document. It would be better if there were clearly different terms in use for the two types of documents, even better if with different repositories, URL patterns etc.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Apr 2021 11:41:24 +0300

Hi,

> Was there ever any discussion of adopting a more specific formal name for IETF I-Ds, e.g. "IETF draft" ("IRTF draft" etc.)? "Internet-draft" could stay as a rarely used generic umbrella term, but i…

not that I am aware of. I agree that indicating adoption of a draft via the name (i.e., draft-ietf or draft-irtf) is not something that will be obvious to many people outside the IETF.

> I am also thinking of the difference between adopted IETF drafts and individual submissions; that was completely lost on me until my first several months of active participation, and I am sure that…

There was a suggestion recently to not serve I-Ds from ietf.org domains until they were adopted by the IETF. Do you think serving individual drafts from another domain would help make that distinction clearer?

There was also a suggestion to add something to the boilerplate text of individual I-Ds along the lines of "anyone can submit an I-D; they have no formal standing until they are adopted by a group in the IETF or IRTF". Would that provide additional clarification?

Thanks,
Lars

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 07:28:27 -0400

Hi Lars,

> There was a suggestion recently to not serve I-Ds from ietf.org domains until they were adopted by the IETF. Do you think serving individual drafts from another domain would help make that distinct…

Drafts get copied to other places, forwarded as attachments, etc. I
think originally serving them from a different domain would not be
worth the trouble and would cause confusion not clarity. Besides, I
would still want the datatracker to, by default, search across all
drafts regardless of their adoption status which would seem a bit odd
if, when unadopted, they were coming from example.org or whatever.

Changing the first token in the file name seems much more powerful to
me. Perhaps, to make a clean break, they should be
proposal-lastname-... and wip-wgname-... (or rgname) (wip = work in
progress) or the like so there is no longer anything starting with
"draft-". You might also need an "adopted" type draft name for AD
sponsored drafts and there are other cases...

> There was also a suggestion to add something to the boilerplate text of individual I-Ds along the lines of "anyone can submit an I-D; they have no formal standing until they are adopted by a group…

Sure, seems reasonable to make a change along those lines.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Apr 2021 07:48:02 -0400

+1 to Donald. It's important for both the IETF process and IPR purposes to
be able to track a particular submission or proposal from start to finish,
in the Datatracker.

Sure, let's change the boilerplate and perhaps the naming conventions to
make it more clear what's an individual submission and what's an IETF
WG/IRTF/IAB/etc. work item, but we need it all searchable and archived in
one place.

Cheers,
Andy

On Tue, Apr 27, 2021 at 7:29 AM Donald Eastlake <[email-masked]> wrote:

> > On 2021-4-27, at 11:28, Vittorio Bertola <
> [email-masked]> wrote:
> > > Was there ever any discussion of adopting a more specific formal name
> for IETF I-Ds, e.g. "IETF draft" ("IRTF draft" etc.)? "Internet-draft"
> could stay as a rarely used generic umbrella term, but if more precise
> terms come into common use, clarity will gain a lot.
> >
> > not that I am aware of. I agree that indicating adoption of a draft via
> the name (i.e., draft-ietf or draft-irtf) is not something that will be
> obvious to many people outside the IETF.
> >
> > > I am also thinking of the difference between adopted IETF drafts and
> individual submissions; that was completely lost on me until my first
> several months of active participation, and I am sure that almost all
> Internet developers and engineers out there miss it too, with the obvious
> consequence that any "Internet draft" is taken as an official
> IETF-sanctioned document. It would be better if there were clearly
> different terms in use for the two types of documents, even better if with
> different repositories, URL patterns etc.
> >
> > There was a suggestion recently to not serve I-Ds from ietf.org domains
> until they were adopted by the IETF. Do you think serving individual drafts
> from another domain would help make that distinction clearer?
>
> > There was also a suggestion to add something to the boilerplate text of
> individual I-Ds along the lines of "anyone can submit an I-D; they have no
> formal standing until they are adopted by a group in the IETF or IRTF".
> Would that provide additional clarification?
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 08:40:37 -0400

> There was a suggestion recently to not serve I-Ds from ietf.org domains until they were adopted by the IETF. Do you think serving individual drafts from another domain would help make that distinct…

The very notion of "adoption" of a draft by the IETF (or at least by a 
working group) is a Bad Idea, as it tends to indicate an assumed 
direction for the WG that isn't yet reflected by a deep understanding of 
the draft or its implications, and makes it harder for a WG to change 
direction.     WGs should be able to entertain alternate proposals at 
any time prior to a post-WGLC consensus, without any built-in 
presumption that some particular draft will be the basis for the 
eventual solution.

So no, please don't do this.

Keith

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Apr 2021 14:47:08 +0200

On 2021-04-27, at 14:40, Keith Moore <[email-masked]> wrote:
> 
> The very notion of "adoption" of a draft by the IETF (or at least by a working group) is a Bad Idea, as it tends to indicate an assumed direction for the WG

WGs differ, so an absolute statement about all WGs like this is always wrong.

For some WGs, establishing that focus is exactly what is needed.

Obviously, even then, the focus on a set of WG drafts is subject to change, as is any specific draft and the direction incorporated in there.

Grüße, Carsten

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 08:53:19 -0400

> WGs differ, so an absolute statement about all WGs like this is always wrong.
I did say "/tends/ to indicate an assumed direction", so it wasn't an 
absolute statement.
> Obviously, even then, the focus on a set of WG drafts is subject to change, as is any specific draft and the direction incorporated in there.

I agree that some WGs are better off starting early with some assumed 
draft to focus on, even if they change it later.   Where I disagree is 
that it's "obvious" to the WG participants that the WG is free to change 
its mind and that alternative proposals are still welcome.   IMO, 
hosting non "adopted" drafts at a separate domain would reinforce the 
perception that the "adopted" drafts are already endorsed by the WG or 
IETF, and IMO this would be a Bad Thing.

Keith

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Apr 2021 16:01:44 +0300

Hi,

On 2021-4-27, at 15:40, Keith Moore <[email-masked]> wrote:
> The very notion of "adoption" of a draft by the IETF (or at least by a working group) is a Bad Idea, as it tends to indicate an assumed direction for the WG that isn't yet reflected by a deep understanding of the draft or its implications, and makes it harder for a WG to change direction.

I'm not sure I follow. WGs have adopted I-Ds for decades; it's the usual way in which the IETF works, and is what causes I-D names to change from draft-yourname to draft-ietf.

This process is central to our way of working; we even commissioned specific datatracker functionality for it ten years ago (RFC6174) and discussed the common practice in RFC7221.

Thanks,
Lars

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Apr 2021 15:03:54 +0200

On 2021-04-27, at 14:53, Keith Moore <[email-masked]> wrote:
> 
> IMO, hosting non "adopted" drafts at a separate domain would reinforce the perception that the "adopted" drafts are already endorsed by the WG or IETF, and IMO this would be a Bad Thing.

The boilerplate probably should explain that “adopted” means “the IRTF RG/IETF WG <name> has expressed interest in working on this document” (and that individual drafts do not have any status).

Apart from that, I do believe in the power of signals, so increasing the difference in the signals for draft-* and draft-ietf is probably good, while sending the wrong signal about draft-ietf is bad (but then, the signal we are sending for these does not change).  As has been mentioned, changing the authority (hostname) of the link is not very strong, as the difference may not persist in copies.

(I’m somehow reminded of the abortive attempts by some universities to give students mail addresses that clearly identify the holder of the address as a lowly student(*), which of course needs a change in address when the status of the student changes, and is a strong disincentive to use that “peon” mail address in the first place.  But the present case is about names for documents, not people, so increasing the difference in signal is very well possible.)

Grüße, Carsten

(*) And, as a welcome contrast, I adore Cambridge for their absolute egalitarianism here!

---

From: Lloyd W <[email-masked]>
Date: Tue, 27 Apr 2021 23:10:15 +1000

https://en.wikipedia.org/wiki/List_of_preprint_repositories

there are lots of arXiV name variants.

setting up the datatracker or tools to have an ietf-rXiV preprint server-like interface for drafts may help- slightly. Or maybe just with academic communities. But you can barely see domain names in browsers these days, and those keep working to get rid of the url bar entirely.

again, I think the IETF is really in the publishing business. Publishers have submissions, a slush pile, and a lot of wannabe unpublished writers.

Lloyd Wood
[email-masked]

> On 27 Apr 2021, at 18:42, Lars Eggert <[email-masked]> wrote:
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 09:13:15 -0400

> I'm not sure I follow. WGs have adopted I-Ds for decades; it's the usual way in which the IETF works, and is what causes I-D names to change from draft-yourname to draft-ietf.

I'm aware of this, and it has bothered me for many years.  It's a 
dubious practice that we should not further reinforce.   I've seen too 
many groups decide to "adopt" a draft, with little discussion, based 
only on the appearance of support for the draft by the chairs, when it 
was clear that most participants (even those in favor of adoption) 
hadn't even read it.

> This process is central to our way of working; we even commissioned specific datatracker functionality for it ten years ago (RFC6174) and discussed the common practice in RFC7221.

The fact that there's datatracker support for it does not mean it's 
central to our way of working, or that it should be.

Keith

('The most damaging phrase in the language is "We've always done it that 
way"' - RAdm. Grace Murray Hopper)

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Apr 2021 16:19:03 +0300

Hi,

On 2021-4-27, at 16:13, Keith Moore <[email-masked]> wrote:
> I've seen too many groups decide to "adopt" a draft, with little discussion, based only on the appearance of support for the draft by the chairs, when it was clear that most participants (even those in favor of adoption) hadn't even read it.

would you please provide some examples?

Thanks,
Lars

---

From: Scott Brim <[email-masked]>
Date: Tue, 27 Apr 2021 09:20:08 -0400

> Force (IETF). Note that other groups may also distribute working documents

Working documents of the Internet Engineering Task Force (IETF) are called
Internet-Drafts.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 27 Apr 2021 15:26:51 +0200 (CEST)

> Il 27/04/2021 10:41 Lars Eggert <[email-masked]> ha scritto:
> 

URIs can help, because they are posted around to refer to documents, so they can contain prominent semantic "messages", either in the hostname or in the top path element. However, I think it would be even better to do this in the filename, as the filename persists even when the file is downloaded or attached. For example, you could reverse the order of the initial elements and things would already be much clearer:

ietf-draft-<wg>-<subject>
irtf-draft-<wg>-<subject>
independent-draft-<author>-<subject>

> There was also a suggestion to add something to the boilerplate text of individual I-Ds along the lines of "anyone can submit an I-D; they have no formal standing until they are adopted by a group…

The boilerplate is useful mostly as something that people can refer to when having a specific discussion; people that know the issue can point other participants to text in the boilerplate. However, people that just randomly find the document and are interested in the content will mostly skip the boilerplate and just read the technical spec.

So, I would add text in the boilerplate but I would also add a short, neat, isolated sentence in a much more visible position, such as a tagline above the title and below the headers, or a subtitle just under the title. Something like "Working draft of IETF group <wgname>" or "Unofficial submission", perhaps combined with something on the intended status (standard vs informational etc.).

By the way, "independent" is not immediately clear. "Personal" or "unofficial" would IMHO be better.

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 09:27:01 -0400

> would you please provide some examples?

I don't want to single out specific WGs, especially when these decisions 
were taken some time ago and it's too late to change them.   Also it's 
not as if I've kept a record of every time I have seen this happen.   
I've just seen it happen so often that I realized it was poor practice 
on our part, and I don't think it should be further entrenched.

Keith

---

From: Scott Bradner <[email-masked]>
Date: Tue, 27 Apr 2021 09:32:10 -0400

IDs are adopted by WGs when they are material to the work of the WG 

and the alternative is to throw out the work and start over?

Scott

> On Apr 27, 2021, at 9:27 AM, Keith Moore <[email-masked]> wrote:
> 
> I don't want to single out specific WGs, especially when these decisions were taken some time ago and it's too late to change them.   Also it's not as if I've kept a record of every time I have seen this happen.   I've just seen it happen so often that I realized it was poor practice on our part, and I don't think it should be further entrenched.
> 
> Keith
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Apr 2021 09:33:02 -0400

> Force (IETF). Note that other groups may also distribute working documents

My suggestion.

Internet-Drafts are documents submitted according to the 'NOTE WELL' terms
of the Internet Engineering Task Force (IETF) as described in RFC-FOO. They
are working documents of the IETF, IRTF and other groups.

I would like open source and other communities to be encouraged to make
more use of Internet Drafts. The more design data is captured under NOTE
WELL terms, the better.

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 09:36:30 -0400

> independent-draft-<author>-<subject>
Binding status to the name of the resource is a Bad Idea partially 
because the name can persist long after the status changes and partially 
because it can confer status prematurely.   Even expecting people to 
repost existing I-Ds with new names to reflect WG "adoption" is dubious.

And we really don't want to "bless" drafts before they have community 
consensus.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 09:40:46 -0400

> IDs are adopted by WGs when they are material to the work of the WG

My impression is that, in practice, IDs are "adopted" by WGs when the 
chair presents that as the next thing for the WG to do, or when the 
chair wants the WG to make a decision about whether the draft is 
in-scope for the WG or not.

Again, in the first case, I think this often happens without any 
significant technical evaluation, so it amounts to a premature 
decision.   I also think it often happens without any regard for whether 
the draft is a good investment of the WG's time, as "adoption" of drafts 
is a good way for WGs to make more work for themselves and justify their 
continued existence.

In the second case, it's quite understandable that a chair wants a 
decision that can scope future discussion in the WG, but "adoption" 
seems like the wrong way to think of it.

Keith

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 27 Apr 2021 13:52:39 +0000

> On Apr 27, 2021, at 6:40 AM, Keith Moore <[email-masked]> wrote:
> 

This has been my experience as well.

> 
> My impression is that, in practice, IDs are "adopted" by WGs when the chair presents that as the next thing for the WG to do, or when the chair wants the WG to make a decision about whether the draft is in-scope for the WG or not.

Various working groups and their chairs work somewhat differently; however, in my experience the working group chairs have done a pretty good job of gauging the rough consensus of the working group that the draft is within charter, of interest to the group, and in good enough shape to adopt as a starting point around which additional detail and consensus will be built. In the event the chairs misjudge this, the working group lets them know by indicating very we few people have read, or understood, or support the draft as a starting point at this time. Next steps are determined from there. Overall, in my experience, the working group adoption process has worked very well.

Cheers,
Charles

> 
> Again, in the first case, I think this often happens without any significant technical evaluation, so it amounts to a premature decision.   I also think it often happens without any regard for whether the draft is a good investment of the WG's time, as "adoption" of drafts is a good way for WGs to make more work for themselves and justify their continued existence.
> 
> In the second case, it's quite understandable that a chair wants a decision that can scope future discussion in the WG, but "adoption" seems like the wrong way to think of it.
> 
> Keith
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Apr 2021 14:17:33 +0000

>   There was a suggestion recently to not serve I-Ds from ietf.org domains until they were adopted by the IETF. Do you think serving individual drafts from another domain would help make that distin…

I do not think it would be worth the effort to do this. And it would probably inconvenience people who already participate and whose fingers are already permanently "trained."

>    There was also a suggestion to add something to the boilerplate text of individual I-Ds along the lines of "anyone can submit an I-D; they have no formal standing until they are adopted by a gro…

Oh yes, PLEASE!

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 10:26:11 -0400

>>     There was also a suggestion to add something to the boilerplate text of individual I-Ds along the lines of "anyone can submit an I-D; they have no formal standing until they are adopted by a g…

concur.   Except get rid of the "adopted" bit, because even assuming 
that "adoption" of a draft by a WG is useful, it doesn't imply any kind 
of broad support from the organization.   Just say that the existence of 
a draft does not mean it has any formal standing with IETF or any other 
organization.   Documents with formal standing in IETF are published as 
RFCs.

Keith

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Apr 2021 11:06:22 -0400

Keith,

I disagree. WGs have charters, which result in RFCs. During that process,
they have consensus-based working drafts that are refined to meet their
charter goals. That's an "adopted" draft. But it doesn't have to be based
on a single individual draft, a working draft can be the result of merging
earlier individual drafts, or can even originate as a WG draft without a
preceding individual draft or drafts. But yes, working drafts do reflect WG
consensus, and they have formal standing as such.

Cheers,
Andy

On Tue, Apr 27, 2021 at 10:27 AM Keith Moore <[email-masked]>
wrote:

> concur.   Except get rid of the "adopted" bit, because even assuming that
> "adoption" of a draft by a WG is useful, it doesn't imply any kind of broad
> support from the organization.   Just say that the existence of a draft
> does not mean it has any formal standing with IETF or any other

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Apr 2021 11:07:30 -0400

On Tue, Apr 27, 2021 at 10:18 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> >   There was a suggestion recently to not serve I-Ds from ietf.org
> domains until they were adopted by the IETF. Do you think serving
> individual drafts from another domain would help make that distinction
> clearer?
>
> I do not think it would be worth the effort to do this. And it would
> probably inconvenience people who already participate and whose fingers are
> already permanently "trained."
>
> >    There was also a suggestion to add something to the boilerplate text
> of individual I-Ds along the lines of "anyone can submit an I-D; they have
> no formal standing until they are adopted by a group in the IETF or IRTF".

+1

If we do this, we should also explicitly say that a document has been
adopted and by what group in which organization. Probably on the same line
that says where to discuss it

"This draft has been adopted by the IETF FOO working group, comments on the
[email-masked] list"
"This draft has been adopted by the IRTF BAR working group, comments on the
[email-masked] list"
"This draft has been adopted by the PHB foundation XYZ working group,
comments on the [email-masked] list"

Why would PHB foundation use an IETF list? Same reason as to publish as an
Internet Draft, to be under Note Well.

If we go this route, we really need to have a final status for documents
that is not an RFC. For better or worse, every RFC comes with the
imprimatur of the IETF whether IETF wants to acknowledge that or not. Does
the IETF really want the PHB foundation issuing RFCs? I think not. Does the
IETF want to have a place where permanent records can be published of file
formats etc that are referenced in specs? I think so.

The current situation in which there are WG RFCs and AD sponsored RFCs and
individual submissions is wide open to abuse and has been abused. Some folk
have made a career out of knowing how to get an RFC published without
having the faff of going through IETF process.

IETF and IRTF drafts should definitely expire after a fixed interval and
maybe 6 months is if anything too long. I can't ever remember having a WG
draft come close to expiring on me. Not once.

I suggest a NOTE series that is simply a terminal state for Internet Drafts
that are never intended to become RFCs but represent fixed static outputs.
NOTEs would only be allowed to be INFORMATIONAL or EXPERIMENTAL. And the
boilerplate would state 'This is not the result of a consensus process'.

One of the things I would use NOTEs for is to document certain file format
arcana which is not otherwise available.

One of my most widely used specifications, the W3C log format was written
in six hours and has never been reviewed in any standards process
whatsoever. It was intended as a placeholder until we sorted something
better out.

Imagine if Markdown had been published as a NOTE in 2004. We might have one
version of Markdown with divergence on extensions rather than dozens of
incompatible versions.

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 11:34:31 -0400

On 4/27/21 11:06 AM, Andrew G. Malis wrote:

> I disagree. WGs have charters, which result in RFCs. During that 
> process, they have consensus-based working drafts that are refined to 
> meet their charter goals. That's an "adopted" draft. But it doesn't 
> have to be based on a single individual draft, a working draft can be 
> the result of merging earlier individual drafts, or can even originate 
> as a WG draft without a preceding individual draft or drafts. But yes, 
> working drafts do reflect WG consensus, and they have formal standing 
> as such.

emphatically disagree, and as said earlier I believe it is a Bad Idea to 
give such draft more status than they deserve.

Keith

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Apr 2021 11:37:30 -0400

Keith, you seem to be4 asking for a change in established practice.  You 
apparently don't like the practice.
If you want it changed, you need to make an argument, get support, etc.
Objecting to a proposal because you want something else to be different 
seems rather odd.

Yours,
Joel

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 11:41:20 -0400

On 4/27/21 11:37 AM, Joel M. Halpern wrote:

> Keith, you seem to be4 asking for a change in established practice.  
> You apparently don't like the practice.
> Objecting to a proposal because you want something else to be 
> different seems rather odd.

To clarify, I'm objecting to the proposal because I think it will 
exacerbate the harm done by an already dubious practice.

Getting groups to think differently about "adoption" is a much more 
subtle, and therefore more difficult, problem.

Keith

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 27 Apr 2021 18:06:20 +0200

Andy,

quick question, if I may:

Le 2021-04-27 à 17:06, Andrew G. Malis a écrit :
> meet their charter goals. That's an "adopted" draft. But it doesn't have 
> to be based on a single individual draft, a working draft can be the 
> result of merging earlier individual drafts, or can even originate as a 
> WG draft without a preceding individual draft or drafts. But yes, 
> working drafts do reflect WG consensus, and they have formal standing as 
> such.
At which point in time to do they reflect WG consensus, according to you?
As examples to illustrate my ask: From day 1 or only at "Publication 
Requested" time, or some other time, if any specific one?

-m

> 
> Cheers,
> Andy
> 
> 
> On Tue, Apr 27, 2021 at 10:27 AM Keith Moore <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     that "adoption" of a draft by a WG is useful, it doesn't imply any
>     kind of broad support from the organization.   Just say that the
>     existence of a draft does not mean it has any formal standing with
>     IETF or any other organization.   Documents with formal standing in
>     IETF are published as RFCs.
> 
>     Keith
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Apr 2021 18:17:39 +0200

On 2021-04-27, at 18:06, Martin Vigoureux <[email-masked]> wrote:
> 
>> But yes, working drafts do reflect WG consensus, and they have formal standing as such.

I do believe different WGs handle this in different ways.

Some WGs have a formal consensus-based process that must be run before the WG documents can be updated.  In these, the statement is pretty much true, except that the WG may not have measured consensus yet on what further steps are needed before the document is ready for publication.

Some WGs give the editors (authors) of the WG document some leeway to move the document forward based on their perception of WG direction.  This is where Section 6.3 of RFC 2418 comes in (note that it says “reflect the decisions of the WG” and does not talk about “consensus").  This is usually more productive in smaller WGs that do not have a large queue of ready-made changes (pull requests) but require the document author to actually do some of the work creating those.

I think Keith is recollecting some experience with WGs where the chairs used the WG document process to run the show without much regard to the WG’s opinions.  In that case, I’d say: get new chairs!  We don’t need to make the process capable of coping with this abuse.

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Apr 2021 12:30:40 -0400

On Tue, Apr 27, 2021 at 12:18 PM Carsten Bormann <[email-masked]> wrote:

>
> I think Keith is recollecting some experience with WGs where the chairs
> used the WG document process to run the show without much regard to the
> WG’s opinions.  In that case, I’d say: get new chairs!  We don’t need to
> make the process capable of coping with this abuse.
>
> Grüße, Carsten
>

That is not always possible. While I am not aware of any AD being a WG
chair at present and there are cases where it makes sense for General area
WGs to be chaired by IETF chair, there have been occasions where an AD of
one area was WG chair in another which made it impossible for that other
area to remove him in a case where he was clearly abusing his position.

I would like to see explicit policy prohibiting this practice. It is futile
to expect IESG members to risk taking on another IESG member on account of
malpractice as a WG chair.

As for the documents, I really can't see how a WG can come to consensus on
a document before they see the document. There are some cases where edits
can be agreed upon and a nice paper trail created. But those changes aren't
the ones that take the time when editing. Change mechanism A to mechanism B
is an easy change. The ones that take time are 'section 3 is unclear'
because you often end up having to make changes in every other section to
fix it.

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 12:35:31 -0400

On 4/27/21 12:17 PM, Carsten Bormann wrote:

> I think Keith is recollecting some experience with WGs where the chairs used the WG document process to run the show without much regard to the WG’s opinions.

Yes, I've seen that happen.  But I've also seen something subtly 
different happen, which is to ask the WG for "consensus" before there's 
really been time for participants to have informed opinions, and then 
(sometimes) treat that "consensus" as if it were set in stone for the 
lifetime of the WG.

What I've seen repeated at many f2f WG meetings:  "how many people have 
read the draft?" (a few hands raised).   and later: "how many people 
support adoption of this document?"   (many more hands raised).   People 
don't even know what they're expressing an opinion on, but they want to 
get on with it!

IMO consensus is meaningless if obtained prematurely, just as consensus 
is meaningless if the WG leaders effectively dictate the outcome.    I 
don't think we should be asking for "consensus" about anything on 
revision -00 documents.    What seems more appropriate is that as a 
document evolves, there's increasing confidence in the WG that the 
document is approaching the criteria for its intended status.   And any 
indications of the status of the document (to the extent that they're 
necessary) should reflect that degree of confidence or lack thereof.   
But I don't think it's helpful to be too formal about this, so rather 
than try to come up with some scheme to express that level of 
confidence, I recommend that we just wait until after WGLC to claim 
consensus of the WG.

> In that case, I’d say: get new chairs!  We don’t need to make the process capable of coping with this abuse.

It's pretty difficult to get chairs replaced.   It looks bad for the 
people who appointed them.   At best, you might get their AD to have a 
word with them.

Keith

---

From: Bob Hinden <[email-masked]>
Date: Tue, 27 Apr 2021 10:11:32 -0700

Hi,

I agree with Brian Carpenter’s suggestion that started this thread.

I do not think we should do anything that makes IDs have more status.    They should continue as working documents.  They shouldn’t get any additional status until at least the chairs declare a w.g. consensus to advance them to the IESG.   Until this happens, they should remain working documents.

In the w.g. I co-chair and ones I participate in, it’s already getting hard to adopt documents, basically the bar is being raised to make adoption more like requiring a w.g. consensus.   Giving IDs more status will make this worse.   Personally, I think the w.g. adoption hurdle should not be too high, because it’s the stage when it becomes a w.g. document and not under the control of the authors.   My main point, is that giving IDs more status will have an unwelcome side effect of raising the bar to have IDs adopted in a w.g.

Note, I have had drafts that didn’t get adopted, drafts that were adopted but not advanced, drafts that were advanced to the IESG and returned, and drafts that got through all of the process and were published as RFCs.    All of the cases, I think.

Bob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Apr 2021 13:12:56 -0400

On Tue, Apr 27, 2021 at 12:36 PM Keith Moore <[email-masked]>
wrote:

> WG’s opinions.

I have seen that happen many times without any draft being involved.

"We must have a DPRIV solution in 12 months or it won't be any use, so your
ideas can't be considered" - 2014.

"It's too early to consider that" ... "And now it is far too late, the WG
has gone in a different direction"

One of the reasons I make damn sure to flag that type of move is precisely
because I have seen that type of move being tried in the past. And the
people who engage in underhand tactics are usually the same people engaging
in whispering campaigns in the bar.

I am still pretty angry about the 'DNS Directorate' and the people wearing
'black helicopter' hats to ridicule those of us pointing out that it's not
a consensus process when a WG chair can refer the decisions of the WG to a
pocket cabal that takes a year to make up its mind and then decides for the
chair.

And the folk who were eager participants in that were being manipulated
from start to finish by the very organization they thought they were
defeating by keeping DNSSEC pure. I am pretty sure they did the same on
IPSEC as well.

If you want to stop a crypto spec going through, all you need to do is to
pick one feature that makes deployment impractical and persuade enough
people that it is absolutely necessary. So IPSEC didn't work with NAT and
was undeployable except as a worse VPN than  SSH and DNSSEC deployment was
stalled for almost a decade.

Perhaps what we need is not to change the boilerplate in drafts but have a
clearer description of what a consensus process is and introduce moves that
cause data to be logged in the tracker. So that a WG chair can't say 'we
will discuss that later', they have to schedule it as an action that has to
be cleared. I would also like the IESG to have a standing rule that any WG
predicated on the idea there is too little time to discuss the alternative
approaches not be chartered in the first place. If there is too little time
for consensus, this is not the place to have the discussion.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Apr 2021 14:08:55 -0400

Martin,

A draft reflects WG consensus when it has the name draft-ietf-wg-....
(that's the definition of that name). Before then, it's just a proposal
from one or more individuals.

It's the document editor and WG chair's jobs to make sure that WG drafts do
in fact reflect WG status. If a WG participant disagrees with the editor
and the chair that the draft reflects WG consensus, they can appeal to an
AD or the IESG as a whole.

This is from RFC 2418:

6.3. Document Editor

   Most IETF working groups focus their efforts on a document, or set of
   documents, that capture the results of the group's work.  A working
   group generally designates a person or persons to serve as the Editor
   for a particular document.  The Document Editor is responsible for
   ensuring that the contents of the document accurately reflect the
   decisions that have been made by the working group.

   As a general practice, the Working Group Chair and Document Editor
   positions are filled by different individuals to help ensure that the
   resulting documents accurately reflect the consensus of the working
   group and that all processes are followed.

Cheers,
Andy

On Tue, Apr 27, 2021 at 12:07 PM Martin Vigoureux <
[email-masked]> wrote:

> >>>         There was also a suggestion to add something to the
> boilerplate text of individual I-Ds along the lines of "anyone can submit
> an I-D; they have no formal standing until they are adopted by a group in
> the IETF or IRTF". Would that provide additional clarification?
> >>     Oh yes, PLEASE!
> >

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 14:12:52 -0400

On Tue, Apr 27, 2021 at 8:54 AM Keith Moore <[email-masked]> wrote:
> I did say "tends to indicate an assumed direction", so it wasn't an absolute statement.

A working group draft is a starting point, not a direction.

> I agree that some WGs are better off starting early with some assumed draft to focus on, even if they change it later.   Where I disagree is that it's "obvious" to the WG participants that the WG is free to change its mind and that alternative proposals are still welcome.   IMO, hosting non "adopted" drafts at a separate domain would reinforce the perception that the "adopted" drafts are already endorsed by the WG or IETF, and IMO this would be a Bad Thing.
>

Thanks,
Donald

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 14:15:54 -0400

> A draft reflects WG consensus when it has the name draft-ietf-wg-....

In practice, that is often not the case.  And it's misleading in the 
extreme to claim that it is.

Keith

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 14:20:11 -0400

> This process is central to our way of working; we even commissioned specific datatracker functionality for it ten years ago (RFC6174) and discussed the common practice in RFC7221.

I agree. Indeed, becoming a WG draft represents a fundamental change
in the status and process for a draft in that before that the
author(s) can change the body of the draft however they want and
add/remove authors as they want but after it is a WG draft the WG is
in charge of the content and the WG Chairs how the power to appoint
and remove authors/editors. Thus it is reasonable and beneficial that
there be some difference in marking and/or draft name between these
two cases.

Thanks,
Donald

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 14:48:06 -0400

> there be some difference in marking and/or draft name between these

I still maintain that this notion of "fundamental change" is a Bad Idea, 
or at least, that it is often done prematurely and perhaps too often.

Every author or editor of a WG document intended for standards track 
(whether or not it is "adopted") understands that their document has to 
earn WG rough consensus before it can go to IESG.   But this isn't 
really determined until the results of a WGLC because basically it's 
premature to do so and also too much trouble.  Until then, the 
authors/editors are (hopefully) trying to earn consensus and also to 
have their document be of the required quality for the intended status 
(both are requirements).   But something's wrong if anyone thinks that 
the early drafts of a document (whether or not adopted by a WG) are, or 
should be, consensus documents.   They are drafts, after all. Inherent 
in the concept of "draft" is that it's subject to revision.

Certainly in early stages of revision, and sometimes later, 
authors/editors need the freedom to make significant changes to a 
document, including major structural changes or even complete rewrites, 
for a variety of reasons, e.g.: to make the document more readable, to 
address major or minor flaws in earlier versions, to improve 
justification of the technical decisions with more comprehensive 
analysis, etc.   It's even possible that as a result of such editing, 
version -N of a document will be less reflective of consensus than 
version -(N-1).   The document is hopefully still overall converging on 
consensus, even if it oscillates around that point a bit from one 
revision to another.

(This is one reason why I doubt that using github as a collaborative 
editing tool is a good idea for documents in early stages, as I believe 
this can discourage major changes prematurely.)

If you try to insist that documents always strictly approach consensus, 
the effect of this is to slow the process down drastically and also 
produce specifications that are overly complex and don't interoperate well.

The whole concept of Internet-Drafts were that they were supposed to be 
lightweight, have minimal overhead, minimal requirements for 
publication, not subject to any central control.   These attributes 
are/were important precisely because people need to be able to sketch 
out proposals in rough form before trying to get the details right.   
But people keep wanting to make them more and more formal.   Please 
stop.   That defeats their purpose.

It should be possible to crudely scribble some notes or drawings on a 
piece of paper, scan it, add some minimal metadata (like a title, 
authors' names, and a date) and publish that as an Internet-Draft.   We 
need to stop trying to make them look and behave like RFCs.

Keith

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 14:50:32 -0400

> because it can confer status prematurely.

Mistakes can be made but that is a Bad reason to never make a decision
and thus make no progress. The six month expiration of drafts helps a
lot in this area. In fact, if we wanted to, we could incorporate the
expiration into the file name so that it was
draft-......-expires20211027.txt or the like.

> Even expecting people to

I think it is a great idea. It makes it clear whether the authors or
the WG is in charge of the draft.

> And we really don't want to "bless" drafts before they have community

If you can't do anything about the contents of a draft other than send
arguments to the authors/editors, until it passes the IESG (which is
what shows it has IETF community consensus) then, to the first
approximation, the IETF will be totally paralyzed.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 14:55:18 -0400

I agree with Andy below but just to be clear, WG draft has a formal
standing as a starting point for work -- they are a draft over which
the WG has taken control.

Thanks,
Donald

On Tue, Apr 27, 2021 at 11:07 AM Andrew G. Malis <[email-masked]> wrote:
>
> Keith,
>
> I disagree. WGs have charters, which result in RFCs. During that process, they have consensus-based working drafts that are refined to meet their charter goals. That's an "adopted" draft. But it doesn't have to be based on a single individual draft, a working draft can be the result of merging earlier individual drafts, or can even originate as a WG draft without a preceding individual draft or drafts. But yes, working drafts do reflect WG consensus, and they have formal standing as such.
>
> Cheers,
> Andy
>
>
> On Tue, Apr 27, 2021 at 10:27 AM Keith Moore <[email-masked]> wrote:
>>
>> concur.   Except get rid of the "adopted" bit, because even assuming that "adoption" of a draft by a WG is useful, it doesn't imply any kind of broad support from the organization.   Just say that the existence of a draft does not mean it has any formal standing with IETF or any other organization.   Documents with formal standing in IETF are published as RFCs.
>>
>> Keith
>>
>>

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 15:02:10 -0400

> the WG is in charge of the draft.
The authors/editors are ALWAYS "in charge" of the draft until they earn 
WG consensus via a WGLC, and subsequent IESG approval.
> approximation, the IETF will be totally paralyzed.

As far as I know, IETF has always worked that way.   For none of the 
RFCs that I've (co-)written has the responsibility of the 
authors/editors to satisfy the WG and later the IESG, been taken away 
prior to IESG approval.

(Having said that, it is possible that a WG could appoint a different 
author or editors to a document that was submitted to that WG, and I 
feel sure that some version of that has happened once and again.)

Keith

---

From: Michael McBride <[email-masked]>
Date: Tue, 27 Apr 2021 19:02:35 +0000

> A working group draft is a starting point, not a direction.

We should make that into a t-shirt. I'm on board with Keith here. In some wg's (including one I chair) a document is typically adopted if there is broad enough interest to work on it and it's technically sound, with no expectation that it will become an RFC. In some wg's, adoption is akin to wglc. We might want to try to make this more consistent across wg's including perhaps redefining "adoption".

mike

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 15:03:20 -0400

> the WG has taken control.

emphatically disagree, and I believe that's a particularly harmful 
concept to promote.

Keith

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Apr 2021 21:06:18 +0200

On 27. Apr 2021, at 21:02, Michael McBride <[email-masked]> wrote:
> 
> We might want to try to make this more consistent across wg's including perhaps redefining "adoption”.

I hope not.

WGs are different.

Grüße, Carsten

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 15:12:49 -0400

>> We might want to try to make this more consistent across wg's including perhaps redefining "adoption”.

Different WGs are (and need to be) different, but it's confusing if 
"adoption" means very different things from one WG to another.

I have generally interpreted "adoption" as meaning "the WG wants to use 
this document as a basis for (some of) its work".   It's not (and 
shouldn't be) a consensus call on the document itself, that's what WGLC 
is for.   It's not exactly an assertion of WG "control" over the 
document, though everyone should understand that drafts intended to be 
WG drafts need to permit creation of derivative works (i.e. forking).  
Nor should it be taken as a commitment on the part of the WG to try to 
publish that document or earn a particular status for it.

Keith

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 15:29:40 -0400

Hi Phil,

On Tue, Apr 27, 2021 at 11:09 AM Phillip Hallam-Baker
<[email-masked]> wrote:
>
> On Tue, Apr 27, 2021 at 10:18 AM Salz, Rich <rsalz=[email-masked]> wrote:
>>
> If we do this, we should also explicitly say that a document has been adopted and by what group in which organization. Probably on the same line that says where to discuss it
>
> "This draft has been adopted by the IETF FOO working group, comments on the [email-masked] list"
> "This draft has been adopted by the IRTF BAR working group, comments on the [email-masked] list"
> "This draft has been adopted by the PHB foundation XYZ working group, comments on the [email-masked] list"
>
> Why would PHB foundation use an IETF list? Same reason as to publish as an Internet Draft, to be under Note Well.

Authors of a draft can say whatever they want in the body of the draft
about what organizations have adopted / endorsed / implemented /
tested /whatever the draft but the required boilerplate for IETF
stream documents should not say any such thing about non-IETF
entities, the required boilerplate in IRTF stream documents should not
say any such thing about non-IRT entities, etc.

> If we go this route, we really need to have a final status for documents that is not an RFC. For better or worse, every RFC comes with the imprimatur of the IETF whether IETF wants to acknowledge that or not.

That status is Expired Draft. The problem of different types of RFCs
being conflated is a long standing problem that has been discussed
many times before with no consensus about how to rectify it or whether
it is necessary to rectify it. I see no reason to conflate that
problem with the question of draft file naming and draft boilerplate.
Start a different thread with a different subject if you want to get
into that rat hole.

> Does the IETF really want the PHB foundation issuing RFCs? I think not. Does the IETF want to have a place where permanent records can be published of file formats etc that are referenced in specs? I think so.

The PHB foundation has no power to issue RFCs. However, PHB foundation
standards that meet fairly minimal standards can be published as
Informational RFCs.

> The current situation in which there are WG RFCs and AD sponsored RFCs and individual submissions is wide open to abuse and has been abused.

So you think things should not be as "wide open"? That is, things
should be more closed off, restrictive, and difficult?

> Some folk have made a career out of knowing how to get an RFC published without having the faff of going through IETF process.

I do not believe anyone has made a career of that.

> IETF and IRTF drafts should definitely expire after a fixed interval and maybe 6 months is if anything too long. I can't ever remember having a WG draft come close to expiring on me. Not once.

They do expire and I think the current six months is about right.

> I suggest a NOTE series that is simply a terminal state for Internet Drafts that are never intended to become RFCs but represent fixed static outputs. NOTEs would only be allowed to be INFORMATIONAL or EXPERIMENTAL. And the boilerplate would state 'This is not the result of a consensus process'.

Sounds like you are simply re-inventing Independent Submission RFCs
(which are only allowed to be INFORMATIONAL or EXPERIMENTAL). Except,
I guess, you don't want there to be any Editorial or Technical review.
Well, I don't think the IETF should publish any permanent documents
without such review.

> One of the things I would use NOTEs for is to document certain file format arcana which is not otherwise available.

If some file format is actually part of a standard, like the DNS
Master File format, or part of an I* process, like the various RFC XML
formats, then it should be in an RFC. If some file format just comes
from some particular open source or proprietary application, then it
can be documented in an INFORMATIONAL RFC but in most cases I don't
think it should have any special IETF status.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 15:32:52 -0400

> give such draft more status than they deserve.

I think "adopted" is entirely accurate, reasonable, and deserved. But
I'm not sure why we should get too wrapped around the axle about that
word. It would not bother me too much if personal drafts had a file
name like d1-lastname-wgname-... and adopted drafts had a name like
d2-ietf-wgname-... It would even be shorter.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 15:39:08 -0400

Hi Martin,

> Requested" time, or some other time, if any specific one?

I can give you my opinion, which may be different from Andy's:

When a draft is adopted, it means it is the Chair's judgement that
there is WG consensus that it is a reasonable point from which to
start. (Note: "a" reasonable point, not necessarily the only one.)
There can easily be one or more technical items in the draft that, at
the time of adoption, are clearly against WG consensus. (In which case
I think the best practice is to post a -00 with the minimum changes to
make it a WG draft and then post a -01 with those technical items
changed to WG consensus.)

The entire draft is not determined to be WG consensus until the Chair
says so, most commonly at the end of a WG Last Call.

Thanks,
Donald

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Apr 2021 15:43:38 -0400

--On Tuesday, April 27, 2021 14:08 -0400 "Andrew G. Malis"
<[email-masked]> wrote:

> Martin,
> 
> A draft reflects WG consensus when it has the name
> draft-ietf-wg-.... (that's the definition of that name).
> Before then, it's just a proposal from one or more individuals.
>...

Andrew, I'd dispute even that.   Identification as a WG draft
definitely means that the draft represents some sort of WG
consensus that the draft is something the WG intends to discuss
and use as a basis for further development.  It does not imply
WG agreement with the details or ideas expressed in the draft
(if, indeed, details are present) although, at some stages of
development, it might.  I think that position is consistent with
RFC 7221, noting that it says "might be a blank sheet...".

> It's the document editor and WG chair's jobs to make sure that
> WG drafts do in fact reflect WG status. If a WG participant
> disagrees with the editor and the chair that the draft
> reflects WG consensus, they can appeal to an AD or the IESG as
> a whole.

Sure, but let's be very clear about what that consensus is about
or what it means.  

This is the same distinction I hope the IESG intended to make
when they issued as statement that any document published in the
IETF Steam -- including Informational or Experimental ones --
needed IETF consensus.  Consensus that information is good to
publish or that an experiment is worth documenting and
performing does not constitute (and, IMO, should not require)
IETF agreement with the ideas being expressed or even that the
experimental spec would be worth standardizing if the experiment
is later judged as having succeeded.

>...

> This is from RFC 2418:
> 
> 6.3. Document Editor
> 
>    Most IETF working groups focus their efforts on a document,
> or set of    documents, that capture the results of the
> group's work.  A working    group generally designates a
> person or persons to serve as the Editor    for a particular
> document.  The Document Editor is responsible for    ensuring
> that the contents of the document accurately reflect the
>...

Right.  But, again, the WG may have made no decisions more
specific than "this draft, in its current state, is a good
starting point for future discussion".  And that would be true
even if an editor included strawman (or some other straw person
or object) positions intended to stimulate discussion rather
than being expected to reflect WG consensus.

>...
   
best,
   john

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 27 Apr 2021 22:07:30 +0200

Thank you Andy

The point I'm trying to get at is:
since "adoption polls" are not an official part of our processes, I 
guess it means WG chairs can adopt a document without running such 
adoption poll, and I sort of remember having seen that at least once.
If that is effectively possible, what are the elements allowing to claim 
that there is WG consensus the day that document becomes 
draft-ietf-<wg>-...?

If I had had to pick a precise moment I would have in fact said 
"Publication Requested" time.

-m

Le 2021-04-27 à 20:08, Andrew G. Malis a écrit :
> It's the document editor and WG chair's jobs to make sure that WG drafts 
> do in fact reflect WG status. If a WG participant disagrees with the 
> editor and the chair that the draft reflects WG consensus, they can 
> appeal to an AD or the IESG as a whole.
> 
> This is from RFC 2418:
> 
> 6.3. Document Editor
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Andy,
> 
>      > On Tue, Apr 27, 2021 at 10:27 AM Keith Moore
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>     boilerplate text of individual I-Ds along the lines of "anyone can
>     submit an I-D; they have no formal standing until they are adopted
>     by a group in the IETF or IRTF". Would that provide additional
>     clarification?
>      >>     Oh yes, PLEASE!
>      >

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Apr 2021 16:09:26 -0400

On Tue, Apr 27, 2021 at 3:29 PM Donald Eastlake <[email-masked]> wrote:

> >> >    There was also a suggestion to add something to the boilerplate
> text of individual I-Ds along the lines of "anyone can submit an I-D; they
> have no formal standing until they are adopted by a group in the IETF or
> IRTF". Would that provide additional clarification?
> >>
> >> Oh yes, PLEASE!
> >
> >
> > +1
> >
> >
> > Why would PHB foundation use an IETF list? Same reason as to publish as
> an Internet Draft, to be under Note Well.
>

The discussion line comes after the boilerplate. Individual IDs should be
clearly differentiated from WG adopted IDs in the body of the text, not
just some arcare file naming convention only understood by initiates.

> imprimatur of the IETF whether IETF wants to acknowledge that or not.
>
> That status is Expired Draft.

I don't think so. There are drafts that are expired with prejudice and
drafts which have merely not been updated.

> The problem of different types of RFCs

The reductive method doesn't work because this is a system with more than
one issue and if you make changes to one part, other parts change.

> The current situation in which there are WG RFCs and AD sponsored RFCs
> and individual submissions is wide open to abuse and has been abused.
>

I think things should be wide open but the resulting work product should be
clearly marked as such and distinguished from IETF consensus work product.

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Apr 2021 16:11:13 -0400

--On Tuesday, April 27, 2021 16:01 +0300 Lars Eggert
<[email-masked]> wrote:

>> The very notion of "adoption" of a draft by the IETF (or at
>> least by a working group) is a Bad Idea, as it tends to
>> indicate an assumed direction for the WG that isn't yet
>> reflected by a deep understanding of the draft or its
>> implications, and makes it harder for a WG to change
>> direction.
> 
> I'm not sure I follow. WGs have adopted I-Ds for decades; it's
> the usual way in which the IETF works, and is what causes I-D
> names to change from draft-yourname to draft-ietf.

Actually, Lars, formal adoption -- in the form of requiring that
draft-yourname-... exist before it could be reissued or revised
and posted as draft-ietf-wgname... -- and requiring more or less
formal consensus calls to adopt in the WG are a fairly recent
development.  For much longer, that transition was a matter for
the individual WG and its style, with the initial versions of
some documents being posted as draft-ietf-wgname... with only
the permission of, or encouragement from, a WG Chair who was
presumably operating on a general sense of the WG and what would
move things forward.  It was possible for that approach to be
abused although, at least in my experience and awareness, it
rarely was and, if it was, the WG usually had much more serious
problems.  

IIR, the draft-ietf-wgname convention arose, not as an
indication of status but simply to make it easier to find
documents that a WG was working on or had associated with it.
That was long before there was a datatracker or general tools
much stronger than sorting and grep.

It is easy to make a case that we have gained from the
additional formality and procedural steps, but it has not been
that way forever and, in some cases, it has almost certainly
slowed things down without significant benefit.  And it has
occasionally has had the downside of encouraging people to treat
or promote WG documents -- ones that were really no more than
preliminary working drafts --  as "nearly standards".

> This process is central to our way of working; we even
> commissioned specific datatracker functionality for it ten
> years ago (RFC6174) and discussed the common practice in
> RFC7221.

But, as I pointed out in another note, RFC 7221 is actually
extremely relaxed about the degree of "finished" and about when
consensus about actual content is required.  In that sense, it
is completely consistent with long term practice.

While I disagree with much of what Keith has written, I'm in
sympathy with where I think he is coming from.  And I think we
would be much better off if we reserved the term "WG consensus"
for describing a document and its content until it had been
through WG Last Call or some equivalent procedure by which the
WG decides it is ready for forwarding to the IESG, recommending
an IETF Last Call.  Before that "adopted by", "being used as a
basis for discussion in", or something similar, might be much
more appropriate, accurate, and less likely to cause confusion
or be misused.

best,
    john

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 Apr 2021 16:14:56 -0400

On 4/27/2021 2:08 PM, Andrew G. Malis wrote:
> (that's the definition of that name). Before then, it's just a 
> proposal from one or more individuals.
>
> It's the document editor and WG chair's jobs to make sure that WG 
> drafts do in fact reflect WG status. If a WG participant disagrees 
> with the editor and the chair that the draft reflects WG consensus, 
> they can appeal to an AD or the IESG as a whole.

Content consensus of a draft document is judged formally only during 
WGLC. _*The consensus to rebrand the draft document to a WG draft is 
mere housekeeping that has no meaning outside of the WG*_ and does not 
necessarily affect the way the draft is edited and updated.   WG drafts 
can and do fail of achieving WG content consensus.

Any ID is just a proposal from one or more individuals, or a scratch pad 
for rough thoughts, or stupid pranks.  Making them WG drafts does not 
change that.

In my experience, the WG does NOT gain control of the document (and I 
have several worked examples in the DNSOP WG).  In some cases, if it 
did, I might be more successful at getting fixes adopted against the 
author's will, but I think making the WG directly in control of the 
content of a given document prior to the WG submitting it for 
publication is generally a bad idea.

IDs are working documents.  Period.  Regardless of whether they are 
named draft-person... draft-ietf... draft-wgname they have exactly the 
same standing within the community as any other ID. They are explicitly 
NOT standards, although they may be (draft) specifications.  RFC7221 
purports to give WG drafts a special status as WG owned, but I will note 
that that document is not a BCP and the IESG discussion 
(https://datatracker.ietf.org/doc/rfc7221/writeup/)  was clear that 7221 
does not create a new step in the process of publication of RFCs.

https://datatracker.ietf.org/doc/draft-carpenter-gendispatch-rfc7221bis/01/ 
might change things, but as of now, the above holds true.

Later, Mike

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 27 Apr 2021 22:57:19 +0200

Hi Donald

> says so, most commonly at the end of a WG Last Call.

Thank you.
I share this vision

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Apr 2021 14:54:15 -0700

Hi Keith,

> emphatically disagree, and I believe that's a particularly harmful 

Could you elaborate more on how your position relates to the BCP 25
description of "Document Editor"?  §6.3 of RFC 2418 has:

Thanks,

Ben

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 27 Apr 2021 14:58:25 -0700

Hi -

On 2021-04-27 1:14 PM, Michael StJohns wrote:
...
> have several worked examples in the DNSOP WG).

In such a case, where the document editor (who may or may not have been
an author of some earlier version of the content) has failed in their
job, and the WG chair(s) should have replaced them with someone willing
and able to do the job.

>  In some cases, if it 
> author's will,

This discussion seems to confuse author and editor.  In my experience,
once something is "adopted" by a WG, the person "holding the pen" is
supposed to function as an editor, even though they may have authored
much of the contribution serving as the starting point for discussion.

> but I think making the WG directly in control of the 
...

This makes no sense at all to me.  It effectively says that WG last call
is the only opportunity for the WG to affect the content.  To me that
seems to completely undermine the collaborative nature of the work.
Once something has been adopted by a WG, the WG is in charge. Its
instructions to the editor might be as broad as "reorganize the contents
in line with our recent discussion" or as narrow as "change 'behavior to
behaviour' in section 2.3."  If the editor is doing their job, the i-d
will reflect the WG's (evolving) thinking, hopefully converging at WG
last call.

Randy

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 18:09:31 -0400

>     decisions that have been made by the working group.

In my experience WGs have often accepted the original 
author(s)/editor(s) of a document as the Document Editor, and done so 
without much (if any) formality.   I think it mostly works

I'm not sure what this has to do, however, with the bit of the reply 
that you quoted.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Apr 2021 18:11:11 -0400

>    decisions that have been made by the working group.

Let us say we have a square peg and a round hole. There are several options:

Change the shape of the peg
Change the shape of the hole
Increase the size of the hole
Decrease the size of the peg.

As editor, I have on several occasions iterated through multiple cycles of
similar options. Each time a new draft was published, a different set of
people read it and realized it was now their ox being gored.

The document is a tool to help arrive at consensus so it cannot represent
consensus except at the end.

On occasion, I have written up a proposed change knowing full well that the
people who proposed it aren't going to like the result at all.

This sort of situation rarely comes up in 1.0 work. But when you are trying
to make a fix to legacy infrastructures....

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Apr 2021 15:22:19 -0700

> I'm not sure what this has to do, however, with the bit of the reply 

My understanding is that you are objecting to statements that "a WG
draft is one where the WG has taken over change control".  I see your
comments elsewhere that the author/editor should have freedom to make
drastic changes, especially in earlier revisions, to attempt to improve the
document.  I think I agree with you in the sense that requiring
pre-approval to all changes to the text of a WG document hinders progress,
but I also think that if there is a conflict between what the editor wants
to do and what the WG wants to do, the editor must yield to the WG (or be
replaced).  In this sense I would say that the WG has change control, since
the WG consensus prevails.

I would like to understand how you are understanding the concept of "change
control" such that you do not want to say that "the WG has change control
over a WG document", especially in light of the BCP statement that the
document editor has to reflect the WG's decisions.

Does that clarify what I'm trying to ask for?

Thanks,

Ben

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Apr 2021 18:30:07 -0400

I have found repeatedly that
1) having explicit control moved to the WG for a document is very useful 
for a WG working on the document
2) That being explicit about that change is very helpful for keeping 
everyone on the same page.

Net: I agree with Donald.

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Apr 2021 18:47:17 -0400

--On Tuesday, April 27, 2021 14:58 -0700 Randy Presuhn
<[email-masked]> wrote:

>> In my experience, the WG does NOT gain control of the
>> document (and I  have several worked examples in the DNSOP
>> WG).
> 
> In such a case, where the document editor (who may or may not
> have been an author of some earlier version of the content)
> has failed in their job, and the WG chair(s) should have
> replaced them with someone willing and able to do the job.
>...
> This discussion seems to confuse author and editor.  In my
> experience, once something is "adopted" by a WG, the person
> "holding the pen" is supposed to function as an editor, even
> though they may have authored much of the contribution serving
> as the starting point for discussion.

Randy,

We agree.  But the key point, and the answer to Ben's question
about relationships to BCP 25/ RFC 2418, is in "should have
replaced them...".  As long as an editor/author behaves as if
they are free to either ignore comments or say "no, I don't
agree with that or feel like making the change" _and_ WG Chairs
and/or ADs respond by doing nothing or effectively by saying
"Decent editors or hard to find" or equivalent, even "she was
the original author of the outline and text, so she has special
rights", then unless that person is a good interpreter of WG
consensus and decides to put it first, your comments and those
of RRC 2418 are meaningless in practice.

There is also a bit of a contradiction in RFC 2418, which is
that we normally say that WG Chairs are responsible for
interpreting WG consensus, but the description of the editor
role says that, for a specific document, that job belongs to the
editor. 

If we want the system to work as several of us have claimed it
should work, there has got to be a lot more willingness to fire
and replace editors who don't take on the role you describe.  If
a replacement cannot be found and that leaves the document
without an editor, then the WG doesn't care enough about the
document and the work it represents to move it forward,
consensus or no consensus.

    john

---

From: [email-masked]
Date: Tue, 27 Apr 2021 15:26:32 -0700 (PDT)

> move things forward.

And in other cases documents went through the entire process
without being renamed.

And then there are the documents that go through the process
without ever being attached to a WG.

> It was possible for that approach to be

I have to agree.

> much stronger than sorting and grep.

Agreed as well.

> preliminary working drafts --  as "nearly standards".

Formalities are always added with the best of intentions, and often have a
contingent arguing passionately for the change. And in some cases the result is
some immediate and obvious benefit that can be attributed to the change with a
high degree of confidence.

But this is actually pretty rare. In most cases there's some benefit, but
whether or not it's the result of the change is unclear. Or there may be no
benefit at all, but we retain the change anyway, because it's bothersome
to undo.

I have pointed out many times the "death of a thousand cuts" process creep
imposes. The usual response is, "But this is different! This is a change we
really need to make!"

However, in this case I would like to add that we're also having discussions
aobut the difficulty of attracting newcomers to the IETF.

If you seriously believe that adding more process overhead and formality makes
the IETF more attactive to newcomers, especially when - as has been suggested in
this thread - it adds to the required document boilerplate - I have a couple of
bridges I'd like to sell you.

> more appropriate, accurate, and less likely to cause confusion

I've seen the phrase "call for adoption" used quite a few times. Seems
like a reasonable way to put it.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 18:58:04 -0400

> the WG consensus prevails.

I think I would say that, ideally, there is a tension between the role 
of the WG and the role of the document editor.   The WG often has very 
specific issues, concerns, and directions; the editor generally needs to 
think a bit more holistically.   The document editor needs to interpret 
the WG's instructions in such a way that the resulting document has 
coherence.   Sometimes that includes sorting out ambiguities and 
conflicts in the WG's direction, sometimes that can even mean 
synthesizing entirely new language that attempts to capture or address 
the spectrum of the WG participants' inputs.  If, early in the 
document's life cycle, the WG is directing the document editor to use 
exactly specific language, that's maybe a bad sign - the WG is trying to 
do the editor's job.

Now if an editor flatly refuses to try to make the document address the 
WG's concerns, or if perhaps, the WG loses faith in the editor's ability 
or willingness to do that - the WG can certainly fork that document and 
begin producing its own derivative works of that document.   In 
principle a WG can do this with any document that's within the scope of 
their charter and for which the WG has permission to create derivative 
works.   That permission is granted to the IETF Trust as part of the 
boilerplate (by reference, BCP 78, section 5.3 paragraph c).  The WG 
does not need to take any formal action to create a derivative work of a 
document when the IETF Trust already has permission to do this (I assume 
that the IETF Trust granted permission applies to the WG - though not 
sure precisely how that happens).

Note that creating a derivative work is not quite the same thing as 
delegating change "control", since the author of an original work still 
has the right to create derivative works of that work, and the license 
granted to the IETF Trust in BCP78 is explicitly non-exclusive.   Of 
course, in practice the WG decides which document it's going to forward 
to IESG.   But I don't know why the original authors should be forbidden 
to continue to revise their work in hopes of earning WG consensus... 
just as anyone else can submit their own draft to the WG and hope to win 
WG consensus for that draft over the WG's "adopted" version.   Mostly I 
think it's just important to minimize the potential for confusion 
between the two (or more) drafts.

If both the WG and the original author(s) can create derivative works, 
and the WG can decide which work to forward to IESG, the only real issue 
is who gets to keep the I-D identifier and produce revisions that retain 
that draft-ietf-wgname-xxx-yyy prefix.   I have a feeling that I know 
who would win that fight if it came to that, but my recommendation would 
be that neither the author nor the WG get to continue using the old 
prefix.   That seems like the least confusing result and also the one 
least likely to cause pointless conflicts.   Whether the datatracker can 
deal sanely with that case, I have no idea.

So, anyway, I don't think of "adopting" a I-D as asserting change 
control, and AFAIK there's nothing in the process of adopting an I-D 
that requires the original authors to relinquish their rights to create 
derivative works of their contribution.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 19:10:56 -0400

On 4/27/21 6:30 PM, Joel M. Halpern wrote:

> 1) having explicit control moved to the WG for a document is very 
> useful for a WG working on the document

As far as I can tell, such "control" is an illusion, or at best, an 
abstraction of polite cooperation between parties who are not required 
to cooperate.   Happily, that's usually the result.

One potential issue could crop up when a WG asserts "control", makes a 
derivative work of an original author's derivative work, and does so in 
such a way as to (appear to) misrepresent the original author's views.  
My understanding is that "moral rights" aren't respected as part of 
copyright in much of the world, but that they're not entirely 
nonexistent either.

Anyway I think it's probably better to not think of "change control" as 
if nobody else but the WG has the right to edit the original document 
(which is clearly not the case), but instead to think in terms of which 
document the WG is going to collaborate on and which it intends to 
eventually submit for an IETF Last Call. And the WG is free to change 
its mind about that.

Keith

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Apr 2021 19:12:07 -0400

Keith, I have to fundamentally disagree with you.
Once the WG adopts the document, the WG owns it, and the document pen 
holder (original author or otherwise) is expected to work according to 
the direciton of the WG.

For practicality and expediency, we do expect and allow the pen holder 
to make changes they consider appropraite, as long as substantive 
changes are confirmed with the working group.

If the pen holder will not make changes in accordance with the WG, the 
pen holder needs to be replaced.  As AD, when I had chairs and an editor 
who would not do so, I told the chairs to replace the editor.  When they 
resigned, I replaced them too.  (This was well over 20 years ago, which 
gives you an idea of how long this has been the understood process.)

If the pen holder can do whatever they want, then we have made a mess, 
as all decisions are deferred until WG last call.  WG decisions about 
document content do get revisisted.  But we have reasoanble expectation 
that the document reflects what the WG is likely to want.

this also allows the chairs a variety of points to make sure general 
IETF process (like does this document comply with the relevant PS and 
BCP RFCs) are being followed.

There are of course working groups that malfunction.
There are also likely other working groups where the chairs allow 
somewhat more latitude, because it is effective for the WG.  But even 
then, the WG retains the actual authority over the document.

The pen holder retains their rights in their original contribution.  But 
in fact, once it is incorporating text from the WG, it belongs to the WG.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Apr 2021 11:13:30 +1200

On 28-Apr-21 01:33, Phillip Hallam-Baker wrote:
...

> Internet-Drafts are documents submitted according to the 'NOTE WELL'

The NOTE WELL is not binding; it's the actual BCPs that control intellectual property rules and they are of course directly cited in the boilerplate.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 19:14:26 -0400

> holder (original author or otherwise) is expected to work according to 

That's not how I read BCP78, and I'm not aware of any other instrument 
by which the document's original authors give up their right to create 
derivative works.

> The pen holder retains their rights in their original contribution. 
> But in fact, once it is incorporating text from the WG, it belongs to 
> the WG.

Emphatically disagree.  I believe this to be an entirely false statement.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Apr 2021 11:16:14 +1200

On 28-Apr-21 06:08, Andrew G. Malis wrote:
> Martin,
> 
> A draft reflects WG consensus when it has the name draft-ietf-wg-.... (that's the definition of that name). Before then, it's just a proposal from one or more individuals.

Actually, no. It only reflects consensus to work on the topic with draft in question as a basis. It does not imply that the WG will reach rough consensus on the draft. It is not uncommon for adopted drafts to fade away, fail to reach WG Last Call, or fail to reach WG consensus after WG Last Call. As Martin says downthread, it's only when the draft is sent off to the AD that we can be sure that the WG chairs have called consensus.

   Brian

> 
> It's the document editor and WG chair's jobs to make sure that WG drafts do in fact reflect WG status. If a WG participant disagrees with the editor and the chair that the draft reflects WG consensus, they can appeal to an AD or the IESG as a whole.
> 
> This is from RFC 2418:
> 
> 6.3. Document Editor
> 
> On Tue, Apr 27, 2021 at 12:07 PM Martin Vigoureux <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Andy,
> 
>     > On Tue, Apr 27, 2021 at 10:27 AM Keith Moore <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Apr 2021 11:17:56 +1200

> independent-draft-<author>-<subject>

I think this, like the suggestion to post drafts to differently named servers, would make matters worse for several reasons:

1) If people already have intellectual difficulty understanding that a filename starting with "draft-" is only a draft, this difficulty will be even greater with remixed names or multiple servers.

2) I hesitate to write this, but "draft-" has beome a brand, although less so than "RFC".

3) We have a lot of tooling that (for better or worse) assumes the draft- naming conventions, and a single server for all drafts. That isn't only IETF official tooling; I'm sure many of us have our own scripts and working habits. That's a real economic cost.

4) We have a de facto agreement that all RFC streams use common practices as far as possible, including IPR regimes. Remixing names and splitting servers wouldn't change that, but would make it less evident.

5) It is not uncommon for drafts to jump ship (from a WG to AD-sponsored; from IRTF to IETF; from IRTF or IETF to Independent, etc.). Forcing name changes for this reason is just makework.

...
> By the way, "independent" is not immediately clear. "Personal" or "unofficial" would IMHO be better.

"Independent" refers to the Independent Submission RFC stream.

   Brian

---

From: Scott Bradner <[email-masked]>
Date: Tue, 27 Apr 2021 19:25:54 -0400

> On Apr 27, 2021, at 7:14 PM, Keith Moore <[email-masked]> wrote:
> 
>> Once the WG adopts the document, the WG owns it, and the document pen holder (original author or otherwise) is expected to work according to the direciton of the WG.
> 
> That's not how I read BCP78, and I'm not aware of any other instrument by which the document's original authors give up their right to create derivative works.

they do not give up that right , nor do any authors/editors of any ID or RFC

> 
>> The pen holder retains their rights in their original contribution. But in fact, once it is incorporating text from the WG, it belongs to the WG.
> 

maybe the issue is with the word "belongs" - once the WG adopts an ID, as has been previously noted,
the original author or editor is required to reflect the WG consensus - if the original author or editor
refuses to do so he or she can be "fired" and someone else appointed to take over editing the
document (I was involved in a few of those cases when I was an AD) or the document can be
abandoned and the WG move on to other work (also involved in at least one of these) 

the original editor/author can ask that the ID be published in the independent stream (also 
involved in a few of those) or take it to another SDO or punish it as a novel (I was not involved in
any of these) or forget the whole thing

Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Apr 2021 19:26:48 -0400

If the pen holder wants to take their original text, and apply any 
changes they personally have made to the document, I think they can do that.

If the original authors want to write another I-D that uses the words 
from the WG, they probably can, as the note well from everyone else 
grants the rights to use the words in IETF work.

But if the original author wants to take his work somewhere else, and 
make derivative works, he better get rid of all the words from IETF 
contributors.

Heck, any author can create an I-D using any words from any I-Ds or 
RFCs, as long as what they are doing is contributing it to the IETF. 
But they can't just  use those words elsewhere.

And the original author does not have any special authority to tell the 
WG what words it will work with.

I do not know of any reason for the WG to change the name of a WG 
adopted draft just because they make some content changes (with or 
without the original author's agreement.  If someone does not like what 
the WG does with their document, they can ask to have their name removed 
(and people have done so).   The WG can change the name (and does if the 
content changes far enough that they want to talk about it as a 
different thing.)  But that is up to the WG, not copyright law or moral 
right.

And in terms of IETF rights, this goes back quite a number of years.

Yours,
Joel

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Apr 2021 16:33:33 -0700

> 5) It is not uncommon for drafts to jump ship (from a WG to AD-sponsored; from IRTF to IETF; from IRTF or IETF to Independent, etc.). Forcing name changes for this reason is just makework.

I definitely agree with what Brian said. In addition, as a rule, it is a 
rather poor idea to twist names to incorporate properties. The chances 
of ending up with an unstable mix of combinations are just way too high, 
and the effects on document management chains are not great.

Yes, there is a risk of confusion because a draft that I just submitted 
will look and feel exactly like one that a working group has been 
working on for three years. But that risk can be addressed in more 
productive ways than twisting names. If we believe that documents 
acquire different cachet and statuses by going through different hoops, 
then we should say so in the status of the document. Saying things like 
"this is an individual contribution to the IETF", or "this is a working 
document of the FOO working group", or "this is a research contribution 
to the IETF", or "this work was not updated since April 4, 2019, and is 
considered abandoned in the IETF" are all statements that would fit well 
in an updated status.

-- Christian Huitema

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 Apr 2021 19:43:38 -0400

> holder (original author or otherwise) is expected to work according to 

Hi Joel -

I'm lacking a reference for that specific claim in the various documents 
that describe the process of getting a document published as an RFC.    
Could you provide one please?  E.g. where does it say that the WG owns 
it?   For that matter, where does it say that a WG needs to formally 
adopt a document to work on it?

I would say instead that the WG may - when faced with a recalcitrant 
author/editor  a) replace them, b) decline to advance the document.  In 
my experience (a) has been difficult to achieve simply because you may 
not be able to find anyone else who cares enough to do the grunt work of 
taking the slings and arrows of the WG and turning it into a publishable 
document.  So the person who holds the pen, also tends to have a bit 
more say over the content of the document - that's just the reality of 
things.

Later, Mike

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Apr 2021 19:44:02 -0400

On 4/27/21 7:25 PM, Scott Bradner wrote:

> document

Maybe the issue is with the wording "the document" implying that there's 
only one document, when reality is more like a tree-structured series of 
derivative works.   If "the" means the specific branch of a revision 
tree that the WG intends to collaborate on and perhaps eventually 
publish, I agree with you. But there are other documents that "the" 
could refer to, so I suspect it's better to avoid that ambiguity.

> any of these) or forget the whole thing

Presumably the original editor/author could at some later point ask the 
WG to consider adopting the editor/author's current version of the 
work.   I'm not saying it's likely that the WG would accept (since they 
had already lost faith in the original author).  But I've certainly seen 
cases in which there was a bitter disagreement between two parties, in 
which party B initially won favor, only for most people to later admit 
that party A was right.    Anyway I'm not aware of anything in our 
process that would prohibit that.

Keith

---

From: [email-masked]
Date: Tue, 27 Apr 2021 16:32:44 -0700 (PDT)

> abandoned and the WG move on to other work (also involved in at least one of these)

I recall a few cases like that. But IME the most common cause for editor
replacement is that the editor abandons the document. Usually because they don't
have the time. There have even been cases where they simply disappear.

Firing people is not one of the more pleasant parts of the job, that's for sure.

				Ned

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 Apr 2021 19:51:00 -0400

What I am describing is what I have seen practice by MANY working groups 
across many areas.

The working groups clearly have the rights to do what is described.

While it is true that replacing an author can be difficult, I have seen 
it done many times.  It shouldn't need to be done as often as it is.

I would personally prefer to avoid codifying the IETF practice of WG 
adoption and renaming into rigid rules.   They tend to cause as many 
problems as they solve.

It is true that not all WGs adopt documents, and that not all documents 
get their name changed.  There was, for example, one SFC document that 
was sufficiently simple that when the WG adopted it the chairs did not 
ask for a name change.  And then shortly thereafter went to WG last call 
on the document.  The lack of name change actually confused quite a 
number of people.

Yours,
Joel

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Apr 2021 20:47:39 -0400

On Tue, Apr 27, 2021 at 7:13 PM Brian E Carpenter <
[email-masked]> wrote:

> The NOTE WELL is not binding; it's the actual BCPs that control
> intellectual property rules and they are of course directly cited in the
> boilerplate.
>
>
Yea, my point is that the thing boilerplate should start off by making the
statements that are true of the widest number of drafts before making IETF
and IRTF specific statements.

Every draft is subject to the IPR regime. Some are WG working documents,
etc.

I don't particularly like the wording either. But that is the objective.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 27 Apr 2021 21:24:12 -0400

On Wed, Apr 28, 2021 at 11:16:14AM +1200, Brian E Carpenter wrote:
> 
> Actually, no. It only reflects consensus to work on the topic with
> draft in question as a basis. It does not imply that the WG will
> reach rough consensus on the draft. It is not uncommon for adopted
> drafts to fade away, fail to reach WG Last Call, or fail to reach WG
> consensus after WG Last Call. As Martin says downthread, it's only
> when the draft is sent off to the AD that we can be sure that the WG
> chairs have called consensus.

It should also be noted that not all I-D's are proto-RFC's.  There are
cases, in more complex protocols, where an wg I-D might contain some
secondary text that might explore potential (non-normative) use cases,
or possible alternate approaches (which if adopted might replace
several sections or subsections of the primary I-D), etc.  In those
cases, the I-D introduction would explain what the purpose of that I-D
might be, and in the end, some, all or none of that text might *ever*
show up in a published RFC.

Perhaps that's less common now, because people can just throw up that
sort of thing on their blog, or a medium or substack post, etc.  But I
think there is value, if there is a document that is useful to the
working group's consideration, for it to be posted as an I-D for that
working group, without any kind of presumption that it's going to end
up as a standard or some other kind of RFC.  Other standard groups
(the T13 ZONE DOMAINS effort was my most recent experience of this)
have similar types of never-intended-to-be-normative documents used in
the process of the work of standardization, so this is by no means
unique to the IETF.

Cheers,

					- Ted

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Apr 2021 21:13:12 -0700

> eventually submit for an IETF Last Call. And the WG is free to change 

AFAICT, basically everyone other than you in the thread is using "the WG
has change control" to mean "for the document that the WG is going to
collaborate on [and intends to eventually submit for an IETF Last Call],
the WG decides what goes in that document".  That is generally going to be
"the document named draft-ietf-wgname-foo" (though not always, of course),
and I thought that the definite article was implied by the process of WG
adoption.

In particular, if we avoid using the phrase "change control" as shorthand
for anything, I'm seeing very little actual disagreement in this thread.
I see a lot of people saying that for the document (or documents) the WG
intends to do things with, the WG calls the shots, and the editor of the WG
document has some flexibility about how to do that given the nature of the
direction from the WG.  I see approximately nobody saying that once the WG
has adopted a document, the author of the original document cannot continue
to do what they like with the original document('s contents).

Am I missing something?

Thanks,

Ben

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Apr 2021 01:13:32 -0400

--On Tuesday, April 27, 2021 21:13 -0700 Benjamin Kaduk
<[email-masked]> wrote:

>> Anyway I think it's probably better to not think of "change
>> control" as  if nobody else but the WG has the right to edit
>> the original document  (which is clearly not the case), but
>> instead to think in terms of which  document the WG is going
>> to collaborate on and which it intends to  eventually submit
>> for an IETF Last Call. And the WG is free to change  its mind
>> about that.
> 
> AFAICT, basically everyone other than you in the thread is
> using "the WG has change control" to mean "for the document
> that the WG is going to collaborate on [and intends to
> eventually submit for an IETF Last Call], the WG decides what
> goes in that document".  That is generally going to be "the
> document named draft-ietf-wgname-foo" (though not always, of
> course), and I thought that the definite article was implied
> by the process of WG adoption.
> 
> In particular, if we avoid using the phrase "change control"
> as shorthand for anything, I'm seeing very little actual
> disagreement in this thread. I see a lot of people saying that
> for the document (or documents) the WG intends to do things
> with, the WG calls the shots, and the editor of the WG
> document has some flexibility about how to do that given the
> nature of the direction from the WG.  I see approximately
> nobody saying that once the WG has adopted a document, the
> author of the original document cannot continue to do what
> they like with the original document('s contents).
> 
> Am I missing something?

AFAICT, little or nothing.  I do think there is another
sub-issue that has confused the conversation. If the WG, in
calling the shots, feels a need to micromanage a document editor
(whomever that might be) and, in particular, gets to the point
of needing consensus calls on editorial --rather than
substantive technical-- issues to move forward, then the WG has
a problem.  I don't think we can make rules about that, if only
because sometimes the solution will be "new editor", sometimes
"new chair(s)", and sometimes "time to shut down the WG as
having lost sight of what it is supposed to be doing".    Cases
like that may ultimately be the reason we pay you ADs the big
bucks.

    john

---

From: Lloyd W <[email-masked]>
Date: Wed, 28 Apr 2021 15:32:12 +1000

> On 28 Apr 2021, at 15:14, John C Klensin <[email-masked]> wrote:
> 

I think you've just described TERM, where the charter and
its document editor are already being micromanaged.

Lloyd Wood
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Apr 2021 02:16:12 -0400

--On Wednesday, April 28, 2021 15:32 +1000 Lloyd W
<[email-masked]> wrote:

>> calling the shots, feels a need to micromanage a document
>> editor (whomever that might be) and, in particular, gets to
>> the point of needing consensus calls on editorial --rather
>> than substantive technical-- issues to move forward, then the
>> WG has a problem.  I don't think we can make rules about
>> that, if only because sometimes the solution will be "new
>> editor", sometimes "new chair(s)", and sometimes "time to
>> shut down the WG as having lost sight of what it is supposed
>> to be doing".    Cases like that may ultimately be the reason
>> we pay you ADs the big bucks.
> 

Lloyd,

<rant>
It is probably (almost) a separate issue but as the more time
goes by and the IETF evolves [1], the more I'm convinced that it
was a mistake in the 1990s to conflate our procedures and
mechanisms for handling and defining procedures for the IETF
with those we use to deal with Internet protocol specifications.
That includes the relationship between BCPs about the operation
of the protocols and the Internet with ones about how the IETF
does its work, assumptions about expertise in WGs and maybe even
about how WGs are organized and run, and possibly whether the
same Last Call and approval model are appropriate to both.  And,
of course, the introduction of the IETF Administration LLC into
the works just heightens the distinctions.  

I remember when we created the idea of a "general area".  It was
not intended at the time to be an actual area that would run
multiple WGs, make decisions about AD-sponsored documents, and
compete with technical/engineering WGs in the other areas for
resources.  Instead, it was a quick solution (some would say
"kludge") to quickly get around our sudden realization that the
post-Kobe POISED reorganization had not made provisions for a WG
without an AD.   So now we have a full-fledged Area to add to
the responsibilities of the IETF Chair (as if IETF Chairs don't
already have enough to do) including a mechanism for generating
new WGs.   Better?  Maybe.  But I contend that trying to treat
them as the same has periodically been the source of some
awkward situations and confusion.

But there has never seemed to be any energy to try to sort it
out.  I assume it will have to get even worse before there is.
</rant>

I am not personally convinced, but maybe the nature or TERM and
the decision to run it as if it were a "normal" WG is a symptom
of the problem.

best,
   john

[1] I'd like to say "matures" but that is sometimes not obvious.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Apr 2021 23:25:00 -0700

On Tue, Apr 27, 2021 at 1:15 PM Michael StJohns <[email-masked]>
wrote:

> WGLC.    *The consensus to rebrand the draft document to a WG draft is
> mere housekeeping that has no meaning outside of the WG* and does not
> necessarily affect the way the draft is edited and updated.   WG drafts can
> and do fail of achieving WG content consensus.
>

When I'm acting as a document editor, it's my job to record the consensus
of the working group.  (Is it different if I'm an author?  Maybe not.)
Effectively what I'm doing in that role is judging the consensus of
completed discussions on this point or that one and modifying the document
accordingly.  Sometimes that might just be writing down what the chair
declares to be consensus, or sometimes I'm being trusted by the chair to do
that on my own for each revision I publish, and in either case WGLC is the
last big chance for the WG to verify that I did it correctly.

Also what you're saying is strictly true, but the fact that the tools treat
them differently these days based on the name, and the published guidelines
do establish a naming convention, could be perceived as more than mere
housekeeping.

In my experience, the WG does NOT gain control of the document (and I have
> several worked examples in the DNSOP WG).  In some cases, if it did, I
> might be more successful at getting fixes adopted against the author's
> will, but I think making the WG directly in control of the content of a
> given document prior to the WG submitting it for publication is generally a
> bad idea.
>

If the content must ultimately contain the consensus output of the working
group on a particular topic, I don't understand how that sidesteps what I
think of as "control".

-MSK

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2021 05:30:44 -0400

> to do what they like with the original document('s contents).

I think that's about right, and I think the discussion is/was converging 
on that view.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2021 05:32:24 -0400

> its document editor are already being micromanaged.

Well, TERM isn't a WG (yet), and its creation is AFAIK still in doubt, 
and now is the appropriate time to debate the charter and the wisdom of 
creating the group at all.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Apr 2021 05:36:58 -0400

On 4/28/21 2:25 AM, Murray S. Kucherawy wrote:

>
> When I'm acting as a document editor, it's my job to record the 
> consensus of the working group.

I would say this differently.  IMO it's the job of the document editor 
to write coherent text that attempts to capture the consensus of the 
working group.

If a WG is making consensus calls about what specific text should appear 
in a document early in that document's evolution, IMO the WG is 
micromanaging the author.   The WG has the right to do this (IMO) and 
maybe sometime it's the only way to make progress, but it's likely to 
result in a stilted document that has internal inconsistencies and takes 
longer to finish.   Assuming that there's a capable document editor, of 
course.

Keith

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 28 Apr 2021 11:54:04 +0200

Brian E Carpenter <[email-masked]> writes:

> I don't what made this click in my brain now rather than 20 years ago,
> but think about this extract from our I-D boilerplate**:
>
> "Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF). Note that other groups may also distribute working
> documents as Internet-Drafts."
>
> quoted without the second, it is actively misleading when (say) an
> IRTF draft is concerned.
>

Sometimes the solution to a problem isn't to add or modify something, it
is to take away something.  I suggest to drop this paragraph instead.

As far as I can tell, the I-D boilerplate is something like the text
below.  If BCP78/BCP79, including their normative references, do not
contain sufficient information to explain this, I believe it is better
to solve whatever the problem is there.  Further, the third paragraph
about expiration is covered already by the normative reference to RFC
2026 section 2.2.

Repeating things in different words can clarify, but it can also make
things harder to understand when subtle differences creep in, as it
appears to have done here.

   Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 September 2021.

/simon

---

From: Lloyd W <[email-masked]>
Date: Wed, 28 Apr 2021 19:58:01 +1000

On 28 Apr 2021, at 19:33, Keith Moore <[email-masked]> wrote:
> Well, TERM isn't a WG (yet), and its creation is AFAIK still in doubt, and now is the appropriate time to debate the charter and the wisdom of creating the group at all.

TERM is now of the seventh revision of its WG charter. Do comment before it reaches its eighth.

https://mailarchive.ietf.org/arch/msg/ietf-announce/7v2o3SVpq-5A4spPC_s9RYrLmVc/

(What's the record for number of charter revisions?)

Lloyd Wood
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Apr 2021 14:28:33 +0000

on that view.

I do not think it is.  "Change control" hasn't bveen discussed really, until the past day or so.

Change control is important, particularly when first-timers are bringing outside work into the IETF.  "You can't just approve my doc?"

---

From: "Gorman, Pierce" <[email-masked]>
Date: Wed, 28 Apr 2021 15:33:15 +0000

I agree with the assertion that the discussion is/was converging.

An author can write whatever they like.  A WG is free to adopt, or not, whatever I-D is made available to them.  An author/editor can write whatever they like.  WG members are free to suggest and request substantive and editorial changes to an I-D.  And, as the venerable Scott Bradner observed, "... once the WG adopts an ID, as has been previously noted, the original author or editor is required to reflect the WG consensus - if the original author or editor refuses to do so he or she can be "fired"."  (The operative words there being "can be".)

Consensus can resemble insufficiently persuasive arguments to require (further) change.  Ultimately, an I-D does not become an RFC unless WG consensus is achieved regardless of whether consensus happens prior to, or at, Last Call.

The topic of I-D and RFC "change control" is broad, but that is my summary of what I perceive as the convergence in the discussion so far.

Pierce

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Salz, Rich
Sent: Wednesday, April 28, 2021 9:29 AM
To: Keith Moore <[email-masked]>; [email-masked]
Subject: Re: Status of this memo

[External]

    on that view.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 28 Apr 2021 17:01:28 +0100

Gorman, Pierce wrote on 28/04/2021 16:33:
> An author can write whatever they like.  A WG is free to adopt, or
> not, whatever I-D is made available to them.  An author/editor can
> write whatever they like.  WG members are free to suggest and request
> substantive and editorial changes to an I-D.

+ notably, a protocol can evolve in parallel with ietf WG drafts.  The 
final written specification may or may not end up converging with 
production implementations.

Nick

---

From: tom petch <[email-masked]>
Date: Wed, 28 Apr 2021 17:40:49 +0100

> to do what they like with the original document('s contents).

Only a reference to RFC7221 which uses the phrase 'IETF Working Group 
revision control' rather than change control.  I think that every other 
point in this thread is covered in the RFC,

Tom Petch

> .

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Apr 2021 15:40:01 -0400

On Wed, Apr 28, 2021 at 5:58 AM Lloyd W <lloyd.wood=
[email-masked]> wrote:

> Well, TERM isn't a WG (yet), and its creation is AFAIK still in doubt, and
> now is the appropriate time to debate the charter and the wisdom of

Well, IOTOPS had 18, but ~14 of those were simply fighting with a (now
fixed) bug that rendered lists in a funny format...

W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Apr 2021 11:12:14 +1200

Simon,

> appears to have done here.

That's true, but the people we are most concerned about when they
misinterpret the boilerplate (e.g. tech journalists) are highly
unlikely to read BCP78/BCP79 and, if they were to read BCP9 (RFC2026),
they would recoil in horror. So IMHO this boilerplate is essential.
That's why I was so annoyed with myself for not noticing the
internal inconsistency 20 years ago.

   Brian

---

From: S Moonesamy <[email-masked]>
Date: Wed, 28 Apr 2021 23:14:43 -0700

Hi Lars,
At 01:41 AM 27-04-2021, Lars Eggert wrote:
>individual drafts from another domain would help make that distinction clearer?

I doubt that serving I-Ds from another site would change much [1].

>of individual I-Ds along the lines of "anyone can submit an I-D; 
>they have no formal standing until they are adopted by a group in 

The following thread is an illustration of the discussions which 
occur every now and then outside the IETF: 
https://mailarchive.ietf.org/arch/msg/cfrg/ved8f1t70B0M2aDuc6I0DcsDH1o/ 
The github repository [2] for the research group mentions "Standard 
Draft".  The research group is either publishing misleading 
information or not bothered by what goes into its repository.

It would be good to have the status represent the current status of 
the draft instead of a boilerplate clause which does not match reality.

Regards,
S. Moonesamy

1. All I-Ds are listed under the same domain name in the datatracker.
2. https://github.com/cfrg/draft-irtf-cfrg-bls-signature