Subject: A quick poll about RFC 7221

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Sep 2020 21:10:17 +0100

Hi WG chairs,

I'm just curious to see who has read RFC 7221.

Rather than clutter this list, I made a Doodle poll

https://doodle.com/poll/2w77cuh5h46vnkhk

Feel free to respond anonymously (e.g., give your name as "Anon 7" or some
such) if you like.

There's nothing more to this than wondering whether RFCs like 7221 get read.
I may come on later to whether this type of RFC is useful or could be made
more useful.

Thanks!

Adrian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Sep 2020 22:50:41 +0200

Interesting.  I didn’t actively know about this document.
(I might have heard about it in 2014, but have since forgotten about it.)

The title is misleading:

           Handling of Internet-Drafts by IETF Working Groups

Instead, it mostly is about adoption of WG documents (and the selection of authors for that segment of its life), except for the introduction where it states in passing that a WG document is (at least substantively) always representing the WG rough consensus.  

This is the second time I need to use the term “process confabulation” today.  While having this statement in an (albeit informational) document is a great stick with which WG chairs can beat up errant authors, it does not reflect reality (even if it does more so in the times of development by github than it used to be), not even an actually always desired process.  (If it actually were true, we wouldn’t need a WGLC.)  

The reality is that in many WGs, authors have pretty wide authority [sic!] to generate new I-Ds that they believe will bring the process forward, and obtain feedback [that could be (but most often is not) judged by the WG chairs to represent WG consensus] only after publishing the new I-D.  Very large WGs may have more elaborate processes that might be closer to mini-WGLCs before accepting changes (in particular with github’s help), but as a universal process requirement, requiring consensus before publishing each update would really impede progress.  The WG needs something concrete to discuss, and I-Ds are that concrete writeup that is input, not output of the current discussion.

Grüße, Carsten

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 12 Sep 2020 17:39:56 -0400

Actually Carsten, I would phrase your comment differently.

We allow the editors of documents to make changes during the process. 
We expect them to tell the WG what they are doing.
The important part is that if the WG disagrees, the editors are required 
(not merely expected, required) to make the changes to conform with the 
WG rough consensus.

Many years ago I fired a WG document editor for refusing to do so.
I have come close to doing so more than once since.

The document belongs to the WG, not to the editor.
For practical reasons, we allow the editors a lot of room to work on the 
document.

The WG LC should, if things are going right, serve as a final 
confirmation that nothing has gone wrong.  That does not mean it is 
unnecessary.

Yours,
Joel

---

From: Erik Kline <[email-masked]>
Date: Sat, 12 Sep 2020 14:49:30 -0700

> confirmation that nothing has gone wrong.  That does not mean it is

Sadly changes can also creep in during IETF LC and IESG eval (and during
AUTH48), without much awareness by the working group(s).  :-/

Yours,
> > Instead, it mostly is about adoption of WG documents (and the selection
> of authors for that segment of its life), except for the introduction where
> it states in passing that a WG document is (at least substantively) always
> representing the WG rough consensus.
> >
> > This is the second time I need to use the term “process confabulation”
> today.  While having this statement in an (albeit informational) document
> is a great stick with which WG chairs can beat up errant authors, it does
> not reflect reality (even if it does more so in the times of development by
> github than it used to be), not even an actually always desired process.
> (If it actually were true, we wouldn’t need a WGLC.)
> >
> > The reality is that in many WGs, authors have pretty wide authority
> [sic!] to generate new I-Ds that they believe will bring the process
> forward, and obtain feedback [that could be (but most often is not) judged
> by the WG chairs to represent WG consensus] only after publishing the new
> I-D.  Very large WGs may have more elaborate processes that might be closer
> to mini-WGLCs before accepting changes (in particular with github’s help),
> but as a universal process requirement, requiring consensus before
> publishing each update would really impede progress.  The WG needs
> something concrete to discuss, and I-Ds are that concrete writeup that is
> input, not output of the current discussion.
> >
> > Grüße, Carsten
> >
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 13 Sep 2020 08:44:25 -0400

Erik,

During IETF LC and IESG eval, all new revisions are uploaded to the
datatracker and are announced by email, so anyone interested can see the
changes. And the WG is copied on most, if not all, of the discussion of the
changes. And finally, during this process the WG chairs and especially the
ADs are watching very closely.

During AUTH48, all changes should only (at least in theory) be editorial in
nature. In addition to the authors, the document shepherd, WG chairs and
ADs are all copied on all of the emails and see the changes, so again,
there are plenty of eyes on the process.

Cheers
Andy

---

From: David Noveck <[email-masked]>
Date: Sun, 13 Sep 2020 08:50:10 -0400

I haven't seen this be a major problem in recent years, although it is an
illustration of the fact that, once WGLC has happened, its ownership of the
document has effectively lapsed and only the authors have a role in dealing
with potential changes that would interfere with the wg consensus.

Way back in 2003, the internationalization section of rfc3530 was
essentially rewritten at IESG direction.  The fact that the wg was not
aware of the change meant that nobody implemented it.  As a result, all
nfsv4 implementations followed the WGLC document rather than the iesg's
revision. The wg had the last word since they were the implementers as
well.  This was all corrected for nfsv4.0 by rfc7530

I'm not sure what would have happened if the wg had been made aware of this
change but the process would probably have been quite contentious. It
almost certainly would have prevented rfc5661 internationalization from
following the unimplemented rfc3530 one. We now have to deal with this as
part of rfc5661bis.  Sigh!

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 13 Sep 2020 11:44:48 -0400

Without trying to revisit ancient history, what you describe is not the 
case.

The IESG never owns the document.  One can argue that the IETF owns it 
during and after IETF last call.  If events transpired as you say, I 
would have said that the chairs were obliged to notify the WG of the 
changes.  If they were indeed of that magnitude, a new WG LC could well 
have been appropriate.  In some cases, I have seen a new IETF LC as well 
when the changes were sufficiently large.

Yours,
Joel

On 9/13/2020 8:50 AM, David Noveck wrote:
> I haven't seen this be a major problem in recent years, although it is 
> an illustration of the fact that, once WGLC has happened, its ownership 
> of the document has effectively lapsed and only the authors have a role 
> in dealing with potential changes that would interfere with the wg 
> consensus.
> 
> I'm not sure what would have happened if the wg had been made aware of 
> this change but the process would probably have been quite contentious. 
> It almost certainly would have prevented rfc5661 internationalization 
> from following the unimplemented rfc3530 one. We now have to deal with 
> this as part of rfc5661bis.  Sigh!
> 
> On Sat, Sep 12, 2020, 5:49 PM Erik Kline <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Sat, Sep 12, 2020 at 2:40 PM Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     Sadly changes can also creep in during IETF LC and IESG eval (and
>     during AUTH48), without much awareness by the working group(s).  :-/
> 
>         Yours,
>         Joel
> 
>          > Instead, it mostly is about adoption of WG documents (and the
>         selection of authors for that segment of its life), except for
>         the introduction where it states in passing that a WG document
>         is (at least substantively) always representing the WG rough
>         consensus.
>          >
>          > This is the second time I need to use the term “process
>         confabulation” today.  While having this statement in an (albeit
>         informational) document is a great stick with which WG chairs
>         can beat up errant authors, it does not reflect reality (even if
>         it does more so in the times of development by github than it
>         used to be), not even an actually always desired process.  (If
>         it actually were true, we wouldn’t need a WGLC.)
>          >
>          > The reality is that in many WGs, authors have pretty wide
>         authority [sic!] to generate new I-Ds that they believe will
>         bring the process forward, and obtain feedback [that could be
>         (but most often is not) judged by the WG chairs to represent WG
>         consensus] only after publishing the new I-D.  Very large WGs
>         may have more elaborate processes that might be closer to
>         mini-WGLCs before accepting changes (in particular with github’s
>         help), but as a universal process requirement, requiring
>         consensus before publishing each update would really impede
>         progress.  The WG needs something concrete to discuss, and I-Ds
>         are that concrete writeup that is input, not output of the
>         current discussion.
>          >
>          > Grüße, Carsten
>          >
>

---

From: David Noveck <[email-masked]>
Date: Sun, 13 Sep 2020 12:29:19 -0400

> Without trying to revisit ancient history, what you describe is not the

Nevertheless, it happened.

> The IESG never owns the document.

Perhaps not, but the fact that it cannot be published without the IESG's
assent makes the question of ownership irrelevant.

  One can argue that the IETF owns it
> during and after IETF last call.

Perhaps so, but I'm not clear what this "ownership" consists of.

If events transpired as you say, I
> changes.

Perhaps so but they didn't, for reasons that are starting to become clear
to me.

If

> they were indeed of that magnitude, a new WG LC could well
> have been appropriate.

Formally perhaps, but what would have been the likely result?  There is no
way the working group would ever have accepted the IESG's approach.  And
the wg's approach had been rejected by the IESG once.   The most likely
result would have been the death of nfsv4 and that is probably what
motivated the chairs to avoid the discussion.

After all, in a discussion of documents, the IESG has the upper hand so it
was not in the working group's interest to have that discussion.  In the
years running up to RFC 7530, the wg's approach was successfully
implemented while stringprep, thought of as salvific by the IESG in 2003,
lost its previous sheen.

In some cases, I have seen a new IETF LC as well

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 17 Sep 2020 18:35:48 -0500

Just to confirm,

> when the changes were sufficiently large.

I've done both AUTH48 WGLCs (as a WG chair) and AUTH48 LCs (as an AD) for
non-editorial changes when that seemed like the Right Thing To Do, so my
experience matches Joel's understanding.

Best,

Spencer

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Sep 2020 17:39:56 -0700

And, it would appear, quickly closed it.

I went and read RFC 7221, saw nothing I disagreed with, and went to respond to your poll. Hmm, it was closed, so now I’m responding.

As to “are documents of this sort useful?”, yes, I believe they are. I’m thinking about doing something similar, probably in the v6ops wiki, because I find myself explaining very basic things repeatedly, and would find it helpful to have a link to point to. In my case, it’s “I have an internet draft that <proposes a new protocol>/<is operationally less than useful>/<etc>; may I have a slot on your agenda?” The rule in v6ops is that agenda slots are handed out to people
   -  with updated drafts (e.g., posted since the recent meeting)
   -  consistent with the working group charter 
   -  that are being discussed on the mailing list 
   -  by people that find them interesting and useful in their networks

not unlike other working groups. I probably write that sentence, or something like it, at least once for every meeting. There are individuals that I have said that to on multiple, even many, occasions.

So, yes, these can be useful. I’m less convinced that they need to be normative. But then RFC 7221 isn’t. It’s informative. 

> On Sep 12, 2020, at 1:10 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi WG chairs,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Sep 2020 10:41:34 +0100

Thanks Fred, 

Well it *was* a quick poll 😊

I can add you to the category "This poll prompted me to read it". For those of you who like numbers, I got:

* Yes, read it
  12
* This poll prompted me to read it
  14
* No, not read it
  8

Given that the RFC was somewhat targeted at WG chairs (it had roots in a WG chair lunch session), I have learned something about marketing.

Best,
Adrian

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Sep 2020 13:47:09 +0000

>    Given that the RFC was somewhat targeted at WG chairs (it had roots in a WG chair lunch session), I have learned something about marketing.

Should we have a suggested reading list for new WG chairs?

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Sep 2020 14:54:04 +0100

Rich,

It's a good idea. There is a wiki and it might benefit from some edits.

A

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Sep 2020 16:45:53 +0000

>   It's a good idea. There is a wiki and it might benefit from some edits.

Link?

And then we need to get the AD's to point first-time chairs to look at that.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Sep 2020 19:09:01 +0100

>>   It's a good idea. There is a wiki and it might benefit from some edits.

https://trac.ietf.org/trac/wgchairs/wiki/WikiStart

Also via https://www.ietf.org/chairs/

> And then we need to get the AD's to point first-time chairs to look at that.

Or, indeed, the other chairs who may be considered friendly.

A