Subject: When to adopt a draft as a WG doc (was RE: "IETF work is done on the mailing lists")

From: "George, Wes" <[email-masked]>
Date: Wed, 28 Nov 2012 10:36:29 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Leslie
>
>     I'm increasingly seeing a "paradigm" where the review happens
> _before_ adoption as a WG draft. After adoption, there's a great lull
> until the deadline for the next IETF week. There tend to be a few,
> seemingly minor, edits for a version to be discussed. The meeting time
> is taken up listing changes, most of which get no discussion. Lather,
> rinse, repeat...

[WEG] I've seen several discussions recently across WG lists, WG chairs list, etc about this specific topic, and it's leading me to believe that we do not have adequate guidance for either WG chairs or participants on when it is generally appropriate to adopt a draft as a WG document. I see 3 basic variants just among the WGs that I'm actively involved in:
1) adopt early because the draft is talking about a subject the WG wants to work on (may or may not be an official charter milestone), and then refine a relatively rough draft through several I-D-ietf-[wg]-* revisions before WGLC
2) adopt after several revisions of I-D-[person]-[wg]-* because there has been enough discussion to make the chairs believe that the WG has interest or the draft has evolved into something the WG sees as useful/in charter; Then there are only minor tweaks in the draft up until WGLC (the above model)
3) don't adopt the draft until some defined criteria are met (e.g. interoperable implementations), meaning that much of the real work gets done in the individual version

It seems to me that these variants are dependent on the people in the WG, the workload of the group, the chairs, past precedent, AD preferences, etc. It makes it difficult on both draft editors and those seeking to follow the discussion for there to be such a disparity from WG to WG on when to adopt drafts. I'm not convinced that there is a one-size-fits-all solution here, but it might be nice to coalesce a little from where we are today.
So I wonder if perhaps we need clearer guidance on what the process is actually supposed to look like and why. If someone can point to a document that gives guidance here, then perhaps we all need to be more conscientious about ensuring that the WGs we participate in are following the available guidance on the matter.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 28 Nov 2012 16:55:00 +0100

Hi, Wes, all,

+1 to "no one-size-fits-all". 

A model that's worked well in a few groups I've been involved in is something between (2) and (3), where the defined criteria is "complete enough that interoperable implementations could conceivably be produced", a slightly lower bar; with the added caveat that discussion of the developing individual draft is encouraged on the working group list, and will be given second-preference agenda time at meetings.

This allows a smaller group around the initial authors to build a coherent proposal, without shutting those out from the process who are motivated to contribute. The WG -00 then has at least plausible suggested answers to the most obvious questions raised, and can be modified by the WG from there (or, indeed, eventually rejected if it turns out the broad approach is incapable of drawing consensus support). This looks basically like a design team approach with self-appointed design teams.

This approach would tend to work better for incremental or self-contained work around an already-elaborated framework or theme.

Best regards,

Brian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 Nov 2012 10:58:56 -0500

> we do not have adequate guidance for either WG chairs or participants on
> when it is generally appropriate to adopt a draft as a WG document.
...
> It seems to me that these variants are dependent on the people in the WG,
> the workload of the group, the chairs, past precedent, AD preferences, etc.
> It makes it difficult on both draft editors and those seeking to follow the
> discussion for there to be such a disparity from WG to WG on when to adopt
> drafts. I'm not convinced that there is a one-size-fits-all solution here, but it
> might be nice to coalesce a little from where we are today.
>
> So I wonder if perhaps we need clearer guidance on what the process is
> actually supposed to look like and why.

Let's start with a basic point and work from there:
There is no formal process that involves "adopting" anything.  Working
group chairs appoint document editors (this is in RFC 2418, Section
6.3).  There is nothing anywhere that specifies how the first version
of a WG document is formed.  One mechanism could be that the charter
says that the WG will develop a Lightweight Modular Network Operations
Protocol, so the WGCs say, "We appoint Wes George as the document
editor for the LMNOP doc."  Wes then goes off and creates
draft-ietf-xyzwg-lmnop-00 based on discussion so far, or even based on
his own opinion of a good start for the protocol spec.  Discussion
ensues and Wes makes changes based on the discussion, because, being a
good document editor, he knows how to make the document reflect what
the WG wants.  A couple of issues are contentious, and the WGCs handle
the evaluation of consensus for those, and Wes incorporates that.  In
the end, the WG as a whole thinks that the document accurately
reflects WG rough consensus, and the chairs request publication.

Another model is that two or more people submit candidate documents,
and the WG decides which one is the best starting point.  That's where
"adoption" comes in.  From there, the rest of the process goes the
same.

However we get to the -00 document, as long as the rest of the process
goes the way it's supposed to, we're fine.  We seem to have settled
into a culture of starting with individual submissions and "adopting"
them, but there's nothing that requires that, and for documents where
there's not significant contention between radically different
starting points, there's probably no need for it.

So, yes, the chairs get to decide how they want to seed the document
development process, and they have a pretty free hand in making that
decision.  Your ADs are always there for further guidance if you need
or want it.  But there's no formal process for that, and I think
that's how we want it to be.

Barry

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Nov 2012 16:00:27 -0000

I led the discussion in the WG Chairs lunch at IETF 78 on this topic.
Slides at http://wiki.tools.ietf.org/group/edu/wiki/IETF78#

Adrian

> -----Original Message-----
> George, Wes
> Sent: 28 November 2012 15:36
> To: John Leslie; Barry Leiba
> Cc: IETF discussion list
> Subject: When to adopt a draft as a WG doc (was RE: "IETF work is done on the
> mailing lists")
> 
> [WEG] I've seen several discussions recently across WG lists, WG chairs list,
etc
> about this specific topic, and it's leading me to believe that we do not have
> adequate guidance for either WG chairs or participants on when it is generally
> appropriate to adopt a draft as a WG document. I see 3 basic variants just
among
> the WGs that I'm actively involved in:
> 1) adopt early because the draft is talking about a subject the WG wants to
work
> on (may or may not be an official charter milestone), and then refine a
relatively
> rough draft through several I-D-ietf-[wg]-* revisions before WGLC
> 2) adopt after several revisions of I-D-[person]-[wg]-* because there has been
> enough discussion to make the chairs believe that the WG has interest or the
> draft has evolved into something the WG sees as useful/in charter; Then there
> are only minor tweaks in the draft up until WGLC (the above model)
> 3) don't adopt the draft until some defined criteria are met (e.g.
interoperable
> implementations), meaning that much of the real work gets done in the
> individual version
> 
> It seems to me that these variants are dependent on the people in the WG, the
> workload of the group, the chairs, past precedent, AD preferences, etc. It
makes
> it difficult on both draft editors and those seeking to follow the discussion
for
> there to be such a disparity from WG to WG on when to adopt drafts. I'm not
> convinced that there is a one-size-fits-all solution here, but it might be
nice to
> coalesce a little from where we are today.
actually
> supposed to look like and why. If someone can point to a document that gives
> guidance here, then perhaps we all need to be more conscientious about
> ensuring that the WGs we participate in are following the available guidance
on
> the matter.
> 
> Wes George
> 
> This E-mail and any of its attachments may contain Time Warner Cable
proprietary
> information, which is privileged, confidential, or subject to copyright
belonging to
> Time Warner Cable. This E-mail is intended solely for the use of the
individual or
> entity to which it is addressed. If you are not the intended recipient of this
E-mail,
> you are hereby notified that any dissemination, distribution, copying, or
action
> taken in relation to the contents of and attachments to this E-mail is
strictly
> prohibited and may be unlawful. If you have received this E-mail in error,
please
> notify the sender immediately and permanently delete the original and any copy
> of this E-mail and any printout.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 28 Nov 2012 11:36:06 -0500

I guess that a better question is:
	"What are the expectations if a draft becomes an WG document?"

The opinions ranges from:
a) It is something that some members of the WG consider inside the scope
of the charter.
....
z) This is a contract that the IESG will bless this document!

Not all working groups are the same, some work on brand new stuff and it
makes sense to have competing ideas progress and then the WG makes a
choice. In other cases the WG is just fixing something in an important
deployed protocol thus stricter criteria makes sense.

For a WG I have chaired we have two adoption paths:
a) publish draft as draft-<editor>-<wg>---, discuss on WG mailing list
once document is on track and people can make intelligent choice ask
for adoption.
b) Chairs based on discussion on lists or events, will
"commission" a WG document to address a particular issue. This will be
published as draft-ietf-<wg>- in version 00. Most of the time this is
reserved for updated version of published RFC's.

	Olafur

On 28/11/2012 10:36, George, Wes wrote:
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of John Leslie
>>
>> _before_ adoption as a WG draft. After adoption, there's a great
>> lull until the deadline for the next IETF week. There tend to be a
>>  few, seemingly minor, edits for a version to be discussed. The
>> meeting time is taken up listing changes, most of which get no
>> discussion. Lather, rinse, repeat...
>
> [WEG] I've seen several discussions recently across WG lists, WG
> chairs list, etc about this specific topic, and it's leading me to
> believe that we do not have adequate guidance for either WG chairs or
> participants on when it is generally appropriate to adopt a draft as
> a WG document. I see 3 basic variants just among the WGs that I'm
> actively involved in: 1) adopt early because the draft is talking
> about a subject the WG wants to work on (may or may not be an
> official charter milestone), and then refine a relatively rough draft
> through several I-D-ietf-[wg]-* revisions before WGLC 2) adopt after
> several revisions of I-D-[person]-[wg]-* because there has been
> enough discussion to make the chairs believe that the WG has interest
> or the draft has evolved into something the WG sees as useful/in
> charter; Then there are only minor tweaks in the draft up until WGLC
> (the above model) 3) don't adopt the draft until some defined
> criteria are met (e.g. interoperable implementations), meaning that
> much of the real work gets done in the individual version
>
> It seems to me that these variants are dependent on the people in the
> WG, the workload of the group, the chairs, past precedent, AD
> preferences, etc. It makes it difficult on both draft editors and
> those seeking to follow the discussion for there to be such a
> disparity from WG to WG on when to adopt drafts. I'm not convinced
> that there is a one-size-fits-all solution here, but it might be nice
> to coalesce a little from where we are today. So I wonder if perhaps
> we need clearer guidance on what the process is actually supposed to
> look like and why. If someone can point to a document that gives
> guidance here, then perhaps we all need to be more conscientious
> about ensuring that the WGs we participate in are following the
> available guidance on the matter.
>
> Wes George
>
>  proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>
>

---

From: Geoff Huston <[email-masked]>
Date: Thu, 29 Nov 2012 13:48:01 +1100

> 3) don't adopt the draft until some defined criteria are met (e.g. interoperable implementations), meaning that much of the real work gets done in the individual version

4) adopt after seeing a reasonable number of WG members post "NOT in favour of adoption", on the purported grounds that such expressions of disinterest in adopting the draft by some strange twist of logic are portrayed to point to "interest in discussing the document"

  Geoff

---

From: "George, Wes" <[email-masked]>
Date: Thu, 29 Nov 2012 11:24:23 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Barry Leiba
>
> 6.3).  There is nothing anywhere that specifies how the first version of
> a WG document is formed.
[WEG] snip
> We seem to have settled into
> a culture of starting with individual submissions and "adopting"
> them, but there's nothing that requires that

[WEG] What this says to me is that we are adhering to an ad hoc or de facto process, and therefore in most cases we're not really thinking about why we do it, or even if we should, we're just going with the flow of past precedent. AKA, "that's the way we've always done it/that's just the way we do things around here". We wouldn't do that with a technical protocol that we defined, we'd update the standard to reflect reality as implemented. So why are we behaving differently with our internal protocol?
If it works and people like it, let's document it so that it can be applied consistently. If people think it's unnecessary and we should stick to the documentation as written (no adoption), let's do that. If we actively *don't* want an IETF-wide procedure here, we can even document that the process for WG adoption of drafts is WG-specific and could document those specifics in a WG policies wiki document maintained by the chairs. There are plenty of WGs that have specific ways that they like to handle document submission, reviews, and requests for agenda time. It might be useful to have that all in one place so that people can know what's expected of them.
> decision.  Your ADs are always there for further guidance if you need or
> want it.  But there's no formal process for that, and I think that's how
> we want it to be.
[WEG] Barry, I respectfully disagree. The whole point I'm making here (and Geoff underscored nicely) is that it's currently too variable and too reliant on a small group of individual volunteers implementing it correctly. When things are not documented, we are dependent on having leadership who innately know how to do the right thing. But that leadership turns over fairly frequently. so assuming that we'll always have people in leadership who know how to make this process work "correctly" without some guidance is pretty risky, IMO. As the IETF ages and grows, and personnel (participants and leaders) turn over, the oral tradition breaks down in a hurry. Further, no matter how good the individuals are at their "jobs" within the IETF, applying undocumented policy (especially doing it inconsistently) looks to the outside world as arbitrary and capricious, or as centralizing authority, and that's not at all productive in an open standards development process. It can be discouraging to new participants, because it contributes to the overwhelming nature of figuring out how to get started as a new document author, and it can make the process seem more closed than it actually is.

It is quite possible to document a policy or procedure with directional guidance and enough flexibility to allow intelligent adults to think for themselves and adapt to the reality of the situation during implementation. I'm willing to work on an update to 2418 to cover this apparent gap, but I'd like to know whether others agree that this is a problem (and are willing to work on the update with me).

Wes George

---

From: Barry Leiba <[email-masked]>
Date: Thu, 29 Nov 2012 14:06:40 -0500

> If we actively *don't*
> want an IETF-wide procedure here, we can even document that the process
> for WG adoption of drafts is WG-specific and could document those specifics
> in a WG policies wiki document maintained by the chairs.

I believe that one is the case, though others can weigh in with
opinions as well.  Yes, we could change our documentation to
explicitly say that this particular decision is a management choice.
But I'll caution you against trying to do that in general: we have a
million things that are unspecified and should be unspecified and left
to management choice.  Trying to find all of those and explicitly say
so will be a frustrating exercise, and one that won't have a lot of
value in the end.  In general, we specify what we want to specify, and
what's left is up to judgment and management.

> Further, no matter how good the individuals are at their "jobs" within the IETF,
> applying undocumented policy (especially doing it inconsistently) looks to the
> outside world as arbitrary and capricious

Here's where we have a gap, you and I: what you call undocumented
policy I call a management choice.  How to assign document editors is
a management choice.  How to record track issues is a management
choice.  How much to open up general discussion, vs requiring focus on
certain things now, and others later, is a management choice.  Whether
to process one or two documents at a time, or do five or six is a
management choice.  Even whether to have a formal "working group last
call" is a management choice -- that one *is* discussed in 2418,
because it's common enough and we thought it important enough.  But a
WGC who decides it's not necessary for a particular document isn't
violating any process or policy.

We hire the best and the brightest as our working group chairs in
order to rely on their judgment and management abilities, exactly
because a lot of flexibility is necessary, so a lot of judgment is
necessary as well.

Again, trying to nail everything down isn't desirable.  And even
trying to nail down the list of things that aren't nailed down isn't,
as I see it.

Barry

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Nov 2012 10:45:44 -0900

> what's left is up to judgment and management.

Hear, hear (and I feel pretty strongly about this).  There are
correction mechanisms if someone feels that a process has gone
off the rails and I prefer to rely on those than trying to
micromanage IETF process.  Right now it seems to be the case
that keeping much unspecified and having strong chairs is a better
use of limited resources than trying to shove everything into a
box.  I'll note that it seems possible that overspecifying process
could potentially cause more protests rather than fewer.

Melinda

---

From: SM <[email-masked]>
Date: Thu, 29 Nov 2012 12:03:59 -0800

At 08:24 29-11-2012, George, Wes wrote:
>adoption), let's do that. If we actively *don't* want an IETF-wide 
>procedure here, we can even document that the process for WG 
>adoption of drafts is WG-specific and could document those specifics 
>in a WG policies wiki document maintained by the chairs. There are 
>plenty of WGs that have specific ways that they like to handle 
>document submission, reviews, and requests for agenda time. It might 
>be useful to have that all in one place so that people can know 
>what's expected of them.

There is a wiki for WG Chairs.  Melinda Shore posted some comments on 
this list several months ago.  She followed up and added material to 
the wiki [1].  There must be over a hundred WG Chairs.  Only a 
handful of them have bothered to add material to the wiki.

>[WEG] Barry, I respectfully disagree. The whole point I'm making 
>here (and Geoff underscored nicely) is that it's currently too 
>variable and too reliant on a small group of individual volunteers 
>implementing it correctly. When things are not documented, we

The problem which Geoff Huston commented about might have occurred in 
a working group within the Routing Area.

According to some RFC:

   "All relevant documents to be discussed at a session should be published
    and available as Internet-Drafts at least two weeks before
    a session starts."

If the above was followed there shouldn't be any draft submissions 
during the week a meeting is held.  The following working groups 
posted drafts during that period:

  DHC
  BMWG
  MPLS
  TSVWG
  MMUSIC
  CODEC
  6MAN
  MANET
  HIP
  APPSAWG
  P2PSIP
  SAVI
  DIME
  DNSOP
  OAUTH
  IDR
  SIPREC
  SIPCORE
  L2VPN
  FECFRAME
  MILE
  EAI
  STRAW
  PRECIS
  XMPP
  JOSE
  PCP
  URNBIS
  LISP
  NFSV4
  MBONED
  SIPCLF
  OPSEC
  TRILL
  CCAMP
  MIF
  REPUTE
  ECRIT
  PAWS

At 11:45 29-11-2012, Melinda Shore wrote:
box.  I'll note that it seems possible that overspecifying process
>could potentially cause more protests rather than fewer.

Yes.  Section 6.5.1 of a document, which everyone claims to have read 
and understood, spells out what people should do if they want to protest.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg75826.html

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Nov 2012 06:14:16 +0900

> I'll note that it seems possible that overspecifying process

or good folk just walking away.  there is a reason we are at the ietf
and not the itu.  rule obsessed and process hidebound is probably not
the most productive use of smart folks' time.

randy

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Nov 2012 21:16:05 -0000

Just picking at one point...

> during the week a meeting is held.

What about drafts that not for discussion at a session? What about drafts that
have completed last call or are in IESG processing?

Cheers,
Adrian

---

From: Geoff Huston <[email-masked]>
Date: Fri, 30 Nov 2012 09:37:04 +1100

> the most productive use of smart folks' time.

On the other hand any organised social activity is organised by virtue of the adoption
of a common set of "norms" about the behaviour of individuals - we call em "rules"
and "processes", but the purpose is common. To what extent the activity is tolerant
of exceptions, and to what extent the group activity is capable of self
examination and evolution in the light of such exceptions is critical for longevity.

Rigid systems tend to ossify while flexible systems tend to adapt.

So for me its not that the ITU is any more rule and processed obsessed than the IETF's WGs. 
I'm sure we could all cite instances all along the spectrum of behaviour in both
forums. The distinction for me is the ability of the forum to undertake
self examination and evolve the rules and processes in the light of what may have
originally been seen as exceptional behaviour.

Geoff

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 29 Nov 2012 17:16:33 -0600

> have completed last call or are in IESG processing?

In addition to the cases Adrian asked about, isn't there also the case 
of an author/editor updating a draft that has already been discussed and 
then submitting it during IETF week?

Thanks,

Spencer

---

From: "George, Wes" <[email-masked]>
Date: Thu, 29 Nov 2012 18:32:05 -0500

> we have a
> to management choice.  Trying to find all of those and explicitly say so
> will be a frustrating exercise, and one that won't have a lot of value
> in the end.  In general, we specify what we want to specify, and what's
> left is up to judgment and management.
[WEG] I'm sorry if it was unclear, but I am not saying that *everything* must be specified, nor do I think anyone should undertake an effort to even identify all of the things that are currently unspecified. I'm pointing out a specific area of confusion and inconsistency that has been created by something that is unspecified and asking "should we specify?"
>
> > Further, no matter how good the individuals are at their "jobs" within
> > the IETF, applying undocumented policy (especially doing it
> > inconsistently) looks to the outside world as arbitrary and capricious
>
> Here's where we have a gap, you and I: what you call undocumented policy
> I call a management choice.
[WEG] that's not really a gap, especially because you can replace my words with yours and the statement above still holds. I am saying is that there is an inconsistency because different people are making different choices on how to proceed, hopefully with the consensus of the WG behind them. IMO, the inconsistency goes beyond merely being flexible to accommodate the widest variety of cases, and adds confusion and variability to the process. I think the gap arises from the fact that you do not see this as inconsistent or that you do not see the inconsistency as a bad thing. It may not be bad in all cases, but I think there's a middle ground between overcreation and overapplication of rules and relative anarchy. I'm just trying to make sure we're actually in that happy medium, and that this is indeed the result of a conscious decision rather than simply imitating what we see in other WGs because that seems to work. FWIW, the WG Chairs wiki is also silent on this matter, and perhaps that is the best place to add a discussion about WG adoption of I-Ds. Is that more palatable?

>
> We hire the best and the brightest as our working group chairs in order
> to rely on their judgment and management abilities,

[WEG] Well, no disrespect to any current or former AD, but this is giving us entirely too much credit for why the vast majority of our WG chairs are good at their jobs when it's more likely attributable to luck. Unlike other leadership positions in IETF, there's no formal interview or "hiring" process to determine who out of the group of engineers that make up IETF is best qualified to start chairing a WG. I certainly had no specific experience that made me any better than anyone else at being a WG chair the first time around. My qualifications included a non-zero amount of common sense, available cycles, interest in the topic, and <joking> the poor sense not to decline when asked to serve </joking>. There's no mandatory training class. If one is lucky, you get paired with an experienced co-chair (I did) and given a pointer to the wiki (I didn't) to help you learn on the fly. It's clear that we trust our WG chairs, and there's nothing wrong with that. But sometimes providing them with more guidance is helpful.

Wes George

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Nov 2012 14:38:52 -0900

On 11/29/12 2:32 PM, George, Wes wrote:
> [WEG] I'm sorry if it was unclear, but I am not saying that
> *everything* must be specified, nor do I think anyone should
> undertake an effort to even identify all of the things that are
> currently unspecified. I'm pointing out a specific area of confusion
> and inconsistency that has been created by something that is
> unspecified and asking "should we specify?"

I'm not very clear on what problem you're trying to solve, or
why it's a problem.  I've seen some stuff around working
group draft adoption that I don't like very much but am not
sure that I'd identify those as a "problem," per se, or that
they would be done better with yet another process document.

Lo, those many years ago I co-chaired (with Avri Doria) the
"problem" working group.  It was a very bad experience, and
I think left me convinced that dorking around with formalizing
process stuff should absolutely not be done unless someone's
identified a specific problem that interferes with getting
documents out.  Process we just don't happen to like is not
a problem.

Melinda

---

From: SM <[email-masked]>
Date: Thu, 29 Nov 2012 15:39:51 -0800

Hi Adrian,
>have completed last call or are in IESG processing?

I did not verify the state of the drafts for above when I listed the 
working groups.  I listed a working group which did not have any 
session.  I know that one of the working groups in the list has 
documents going through IESG processing.  If you ask me whether the 
list is a good representation of the text I quoted, my answer would be no.

There are three meetings slots in a year.  If a group misses that 
slot it losses the opportunity for three months of work (assuming 
that there is discussion on the mailing list).  People are free to 
object to object about the process not being followed to the letter 
or about arbitrary decisions of the chair.  If I was a WG Chair and 
somebody asked why the work is being delayed or the working group is 
doing nothing I would point to the objection.  What I won't say is 
whether people who will be implementing the work or who are actually 
going to review the work will walk away.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Thu, 29 Nov 2012 16:37:46 -0800

Hi Spencer,
At 15:16 29-11-2012, Spencer Dawkins wrote:
>In addition to the cases Adrian asked about, isn't there also the 
>case of an author/editor updating a draft that has already been 
>discussed and then submitting it during IETF week?

Yes.

Regards,
-sm

---

From: "George, Wes" <[email-masked]>
Date: Fri, 30 Nov 2012 09:09:49 -0500

> Melinda Shore
> I'm not very clear on what problem you're trying to solve, or why it's a
> problem.  I've seen some stuff around working group draft adoption that
> I don't like very much but am not sure that I'd identify those as a
> "problem," per se, or that they would be done better with yet another
> process document.
[WEG] My original message simply notes that this is the 3rd or more time in my recent memory that there has been a serious question within some part of the IETF about when in a document's lifecycle and maturity is the "right" time to adopt it as a WG document, and whether it is appropriate to discuss an individual document in a WG at any length without adopting it. It seemed odd to me that there would be this much confusion on the matter, and I provided several examples of different philosophies that I have observed when it comes to handling this question. The response I got back indicated that WG adoption of drafts isn't really "a thing" as far as the official documentation of document lifecycle is concerned, which made me wonder if perhaps we do as much WG adoption of drafts as we do mainly out of inertia, either people doing it because that's how they've seen others do it in the past, or doing it because they assume it's part of the documented process, rather than for any real reason. I'm not a big fan of doing things for no reason, so the ensuing discussion was intended to tease this out a bit to see whether we should have some clearer guidelines around WG draft adoption, better education on the reasoning behind it, or whether maybe we should stop doing it. Is it the largest problem facing the IETF? Not by a long shot. But it seemed worth a little discussion, at least to me.

> Process we just don't happen to like is not a problem.
>
[WEG] process we don't happen to like because it adds no value or confuses people or wastes time is very much a problem. But I didn't bring this up because I didn't like the process, I brought it up because I was seeking a little clarity on the underlying reasons we use the process (at least partially to improve my own knowledge as a WG chair and draft author). Thus far that clarity has still not presented itself.

Wes George

---

From: Dave Crocker <[email-masked]>
Date: Fri, 30 Nov 2012 08:06:17 -0800

On 11/28/2012 7:58 AM, Barry Leiba wrote:
> There is no formal process that involves "adopting" anything.

If you mean that we haven't documented a/the formal process, you are 
correct.  If you mean that the IETF has not moved towards rather formal 
steps for explicitly adopting working group drafts, I disagree.

There is flexibility in the process that has developed, but it's become 
quite formal.  The first shakey steps were controlling assignment of 
"draft-<wgname>" roughly 20 years ago and it has evolved from there.

Today, there is typically explicit text in the charter about adoption or 
there is explicit wg approval.

>   There is nothing anywhere that specifies how the first version
> of a WG document is formed.

Right.  Our documentation of our formal processes has lagged.

The next part of your note summarizes a couple of common starting points 
for drafts.

On 11/29/2012 11:06 AM, Barry Leiba wrote:
> policy I call a management choice.

There certainly are parts of wg management that are left to chair 
discretion.  However the IETF also likes to use squishy language like 
"management choice" to avoid being disciplined in its formal processes. 
We are constantly afraid of edge conditions, and use that fear as an 
excuse for being inconsistent in the handling of typical cases.

In the current discussion, I think there needs to be an essential 
distinction:  For example, choosing editors is /formally/ a management 
choice.  Approval of drafts is not.

I think the essential point is the difference between 'what' and 'how'.

The IETF has unusual flexibility in the 'how', and often leaves the 
choices to management... but implicitly based on acceptance of the 
working group.

In very specific circumstances, such as selecting editors, the freedom 
of management choice is permitted for the 'what'.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: SM <[email-masked]>
Date: Fri, 30 Nov 2012 08:43:11 -0800

At 06:09 30-11-2012, George, Wes wrote:
>[WEG] My original message simply notes that this is the 3rd or more 
>time in my recent memory that there has been a serious question 
>within some part of the IETF about when in a document's lifecycle 
>and maturity is the "right" time to adopt it as a WG document, and 
>whether it is appropriate to discuss an individual document in a WG 
>at any length without adopting it. It seemed odd to me that there 
>would be this much confusion on the matter, and I provided several 
>examples of different philosophies that I have observed when it 
>comes to handling this question. The response I got back indicated 
>that WG adoption of drafts isn't really "a thing" as far as the 
>official documentation of document lifecycle is concerned, which 
>made me wonder if perhaps we do as much WG adoption of drafts as we 
>do mainly out of inertia, either people doing it because that's how 
>they've seen others do it in the past, or doing it because they 
>assume it's part of the documented process, rather than for any real 
>reason. I'm not a big fan of doing things for no reason, so the 
>ensuing discussion was intended to tease this out a bit to see 
>whether we should have some clearer guidelines around WG draft 
>adoption, better education on the reasoning behind it, or whether 
>maybe we should stop doing it. Is it the largest problem facing the 
>IETF? Not by a long shot. But it seemed worth a little discussion, 
>at least to me.

You seem to have things under control in SUNSET.  After reading your 
messages to this mailing list I didn't understand what you were asking.

There is no such thing as a "right" time to adopt a document.  Look 
at it this way, if you get it right nobody will know, if you get it 
wrong the working group will say bad things about you, if you get it 
really wrong the Area Director will be on your back.  The choices for 
a working group chair are:

  (a) To get the work done

  (b) Not to do anything wrong

If you choose (a) you will end up a lot of enemies.  If you choose 
(b) you may or may not have a long career in the IETF.

It is possible to discuss an individual document in a working group 
without adopting it.  It is, as you mentioned, a matter of 
philosophy.  If you find it disruptive you can say no.

A lot of the things done in the IETF are done because we see others 
doing it.  In essence they are done for no reason.  On the Internet 
there is something called a sense of entitlement.  The author of a 
draft may assume that he has a right to a RFC number.  You can help 
him/her to get that RFC number as you were selected as working group 
chair to make everyone happy (or is it something else :-)).

I'll quote 
http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF78/IETF78-WGchairs-Adrian-Farrel.ppt?format=raw

   '"Do you think this I-D should become a WG draft?"

    - Can easily turn into a vote

    - Ask for reasons to be given to accompany a "no" opinion

    - Ask for expressions of willingness to work on or review the draft

    Avoid votes!'

>[WEG] process we don't happen to like because it adds no value or 
>confuses people or wastes time is very much a problem. But I didn't 
>bring this up because I didn't like the process, I brought it up 
>because I was seeking a little clarity on the underlying reasons we 
>use the process (at least partially to improve my own knowledge as a 
>WG chair and draft author). Thus far that clarity has still not 
>presented itself.

I'll edit what you said: "[adoption] doesn't happen because it adds 
no value or confuses people or wastes time".

It seems that what you are asking about is a sanity check.  You could 
sound some people to get a sense of which direction to take.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Fri, 30 Nov 2012 18:29:10 -0500

...
> there is explicit wg approval.

Indeed: we always have the option of having the charter limit
management options.  That's a fine thing to do when it's appropriate,
and some combination of the working group proponents, the community as
a whole, and the IESG decides what's appropriate.  For chartering, the
IESG has the final word.

> Right.  Our documentation of our formal processes has lagged.

I find that to be an interesting interpretation.  I don't see it that way.

I do, indeed, mean that the IETF has not moved towards rather formal
steps for explicitly adopting working group drafts.  We have a common
custom, which many -- probably most -- working groups use.  As Wes
noted, it's not used in a consistent way, exactly because it is NOT a
formal process in any sense.

We have a very well defined mechanism (a formal process) for making it
a formal process, and we haven't done so.  Wes noted that he'd like
to; perhaps you'd like to join him in that.  The formal process, as
you know, would be to submit an Internet Draft with a target status of
BCP, and either find an AD to sponsor it as an individual submission
or make a BoF request and try to get a working group chartered for it.

Only when that document becomes an approved BCP will we actually have
formal steps.  Until then, we have a custom that's usually, but not
always, followed.

Barry