Subject: When to adopt a WG I-D

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 May 2013 10:32:50 +0100

Hi,

Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication.

We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input.

What is not clear?
What have we got wrong?
How should we resolve the remaining editor notes?

Thanks,
Adrian
(per pro Dave)

[1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 28 May 2013 11:09:50 +0000

Hi,

Good work. Here are a few thoughts after a first reading.

- We seem not to have a definition of what a WG I-D is, although we know how to recognize a WG I-D because of the naming convention. So, if I am not mistaken the phrase 

Working Group drafts are documents that are subject to IETF Working
   Group revision control.

in section 1.1 introduces such a definition. Is everybody happy with this? 

- I am lacking from the criteria in 2.2 the stability of the technical solution (as per WG consensus). In my mind this is in current practice the principal specific difference between individual submission I-Ds and WG I-Ds - the fact that the I-D makes a clear (it may be drafty but yet clear) statement about what the technical solution is. 

- I less like the following: 

      *  If not already in scope, is a simple modification to the
         charter feasible and warranted?

Without being extremely strict on the process aspect, I believe that WGs should not work on items that are not chartered, and even less adopt WG I-Ds on non-chartered items. If they feel that something is missing from the charter they can ask the ADs for a charter update, or for adding milestones, we have today at hand light processes which can lead to fast incremental additions to charters, and if the addition is more than incremental than it should go through a proper rechartering process. 

-      *  What is the position of the working group chairs, concerning
         the draft?

            [[editor note: I am not sure this is relevant.  Indeed is
            might be specifically not relevant.  /a]]

Not relevant IMO. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: Tuesday, May 28, 2013 12:33 PM
> To: [email-masked]
> Subject: When to adopt a WG I-D
> 
> Hi,
> 
> Dave Crocker and I have this little draft [1] discussing the process and
> considerations for creating formal working group drafts that are
> targeted for publication.
> 
> We believe that this may help clarify some of the issues and concerns
> associated with this part of the process. We are targeting this as
> Informational (i.e. commentary on existing process, not new normative
> definition of process) and would like your input.
> 
> What is not clear?
> What have we got wrong?

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 28 May 2013 07:34:37 -0400

Nicely written, largely stating what might be obvious for many, but still nice to see it in black and white.  

	A few comments/suggestions:

	1) Section 3.  Authors/Editors

	I suggest that you suggest that WG (co)chair(s) add an editor that is unrelated to the draft, but that they trust who has good editing skills. As we all well know, that is half the battle for getting a draft successfully across the finish line and to the IESG. How many times has the IESG seen drafts that are not up to snuff in some (editorially-related) manner?  This person might also keep the draft's trajectory motivated in the forward progress direction.  Finally, in cases where a draft is controversial, this //might// aid in diffusing any electric situations. 

	2) Section 5.2.  Competing Drafts  states:

   Engineering for interesting topics often produces competing,
   interesting proposals.

	I suggest replacing "interesting proposals" with just "competing proposals"

	I'd also put a reference here to the point I made above.

	3) A little further in this section, I suggesting amending the text a bit from:

	Sometimes,
   multiple versions are formally published, absent consensus among the
   alternatives.

	to something like:

	Sometimes, multiple versions are formally published, absent consensus among the
   alternatives. In this way, marketplace economics and preferences are allowed to weigh-in on the relevancy of one approach versus the other(s).   In these cases, the working group should be prepared to revisit the drafts later once a clear preference in the marketplace exists. At this time the working group should be prepared to amend, narrow or delete the competing approaches as necessary, in order to clarify the multiple approaches to as narrow a selection of options as possible once the approaches are ready for Proposed Standard status.

	4) There is also no mention of functioning and interoperability of implementations, and hence no reference to the "working code" part of the mantra. I think it is important to provide some guidance in this regard during all phases of the document's states.  For example, two competing approaches, but one with running and demonstrable interoperating code might cause a WG to err in that direction rather than having competing approaches just because a second one was dreamt up at the last minute for political reasons.

	--Tom

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 May 2013 16:24:35 +0200

On 2013-05-28 13:09, Romascanu, Dan (Dan) wrote:
> - We seem not to have a definition of what a WG I-D is,
> although we know how to recognize a WG I-D because of the naming
 > convention. So, if I am not mistaken the phrase
>

No not really - first it is not a definition - it is something that
follow from that the document is a wg document.

I guess the following is closer to a definition:

   "A working group document is any document that the working group
    chairs says is a working group document."

The revision control follows from that, but is nevertheless necessary.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 28 May 2013 15:36:00 +0100

It is difficult to read, because I am expecting a process and find
something else,

I started to read, but got confused (stoped reading), why you are titling
it as creating WG-draft and mentioning the adoption into the document. I
understand that the creating first is *individual-draft* not *WG-draft*,
the adoption happens after the creation of individual draft. If creating is
WG creation, then it is already adopted as *idea* not *draft*, and then
draft-00 is the WG-draft.

I don't see the process clear at all, I maybe missing something,

AB

On Tue, May 28, 2013 at 10:32 AM, Adrian Farrel <[email-masked]> wrote:

> considerations for creating formal working group drafts that are targeted
> for publication.
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 28 May 2013 15:52:13 +0100

On 28/05/2013 15:36, Abdussalam Baryun wrote:
> I started to read, but got confused (stoped reading), why you are 
> titling it as creating WG-draft and mentioning the adoption into the 
> document. I understand that the creating first is *individual-draft* 
> not *WG-draft*,

Incorrect, the first incarnation of a draft can be a WG draft. The only 
requirement is that the chairs conclude that the existence such a draft 
has WG consensus.

> the adoption happens after the creation of individual draft. If 
> creating is WG creation, then it is already adopted as *idea* not 
> *draft*, and then draft-00 is the WG-draft.
Yes you are.

Stewart
> AB
>
>
> On Tue, May 28, 2013 at 10:32 AM, Adrian Farrel <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     Dave Crocker and I have this little draft [1] discussing the
>     process and considerations for creating formal working group
>     drafts that are targeted for publication.
>
>     We believe that this may help clarify some of the issues and
>     concerns associated with this part of the process. We are
>     targeting this as Informational (i.e. commentary on existing
>     process, not new normative definition of process) and would like
>     your input.
>
>     What is not clear?
>     What have we got wrong?
>     [1]
>     http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt
>
>
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 May 2013 16:59:42 +0200

Adrian,

I'm fine with this draft as long as it stays informational and is
viewed as a commentary on how what we are doing in the border land
between individual and formal working group documents, i.e. this is
not an IETF process text.

Names of ID file are a bit trickier than what I get from this draft

It is true that a document with a file name as:

draft-<wgname>-ietf-... uniquely is a working group document; you need
the approval of the wg chair(s) to have a draft with that file name
posted.

However, a draft with the file name:

draft-<individual>-ietf... may or may not be wg document, and it is
actually so when the the working group chairs states on the wg mailing
list that it is.

Admittedly this is often followed by a request to re-post it with
the common format of file names for wg documents, but it is not the
posting with the wg name format that makes it a wg document, it is the
announcement from wg chairs.

It is nowhere required to change the file name just because the
document has become a working group document. Stupid not to do it,
but not required. For example the appsawg does have two parked
*wg documents* that does not follow the naming convention above.

Now in section 5.1. you talk about a special case "documents supported
by a working", but that remains an individual draft but progress
according to the wg processes. I think that what is now RFC 3468 was
such a case; even though we at that did not talk about in those terms.

I think it would be clearer if you in section 5.1. just said that there
might be individual documents that is supported by a working group, and
that follows the naming conventions for individual documents.

/Loa

--

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 May 2013 11:20:43 -0400

On 5/28/2013 10:52 AM, Stewart Bryant wrote:
> ... The only
> ...

Strictly speaking, I believe the only requirement for a document to be
published as a WG document is that a WG chair approves it.

I do agree/think there are many practical restrictions, notably charter
& WG support.

WRT to the I-D: the text in section 2.4 that says "the chairs need
to..." can mislead some to believe that this is the required process.  I
think the "the chairs typically..." would be more accurate.

Lou

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 May 2013 11:22:06 -0400

In reading through the draft, particularly the section on questions for 
WG adoption of a draft, I did not see the questions I consider most 
pertinent:
Does the WG think this is a reasonable (preferably good) basis for 
starting to work collectively on the deliverable?

(Apologies if it was there and I missed it.)

Another question many WGs have found useful is:
Are there enough people interested and willing to write and / or review 
the document?
This is not the same as WG support for the document.

Yours,
Joel

PS: The chairs opinion on the technical content of the document ought to 
be irrelevant as far as I can tell.  On the other hand, detecting and 
raising concerns if the document is badly written is probably part of 
the chair's job.

On 5/28/2013 5:32 AM, Adrian Farrel wrote:
> Hi,
>
> Dave Crocker and I have this little draft [1] discussing the process
> and considerations for creating formal working group drafts that are
> What is not clear? What have we got wrong? How should we resolve the
> remaining editor notes?
>
> Thanks, Adrian (per pro Dave)
>
> [1]

---

From: manning bill <[email-masked]>
Date: Tue, 28 May 2013 08:38:18 -0700

there is also the not uncommon event where an idea starts as an individual idea,
moves into a WG, is rejected by the WG, becomes an individual idea, is picked up
by another WG, rejected,  (lather, rinse, repeat), and then the -right- WG is formed 
and it is processed that way.  In the current state of affairs, at each name-change, the
document counter is reset, particularly for IP challenges.

and there is also Mr. Bush's dispensation to use neither WG or name in his drafts…
he gets to use  "YMBK"

Naming of IDs, while important, is not an accurate reflection of the growth and evolution of 
an idea in the IETF context.

/bill

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 28 May 2013 12:43:17 -0500

> WG adoption of a draft, I did not see the questions I consider most

I appreciate Dave and Adrian for producing this helpful start, and I'm 
mostly comfortable with where this conversation has gone since Adrian 
asked for feedback on this list.

I wanted specifically to echo Joel's suggestions for additional questions.

> starting to work collectively on the deliverable?

I read this as "is this stable enough for a working group to work on it, 
or might we still want to tell some small number of people to go off in 
a corner and try again to produce something that IS a reasonable basis?"

I agree. To the extent that a working group really does control the 
contents of a working group draft, if the working group doesn't agree 
that the draft is a reasonable basis, making consensus calls about 
massive rewrites seems more painful than we are hoping for.

> Are there enough people interested and willing to write and / or review

Exactly. We should work on working group drafts. If a working group 
doesn't have the resources and willingness to work on the document, I'm 
not sure how much sense it makes to adopt it as a draft that's being 
officially ignored by the working group :-)

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 May 2013 08:26:16 +1200

> We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new…

I haven't read the draft yet, and *before* I do so, I'd like to express
some doubt whether we should even informally describe this using the
word "process". It seems to me that it's each WG's prerogative how it
does this; it has no impact on the standards process as a whole. The
word "adopt" doesn't even occur in RFC 2418, and it is not used in
the context of WG adoption in RFC 2026.

In other words, I don't think this action is part of the standards process.
It's WG folklore.

   Brian

> .

---

From: Arturo Servin <[email-masked]>
Date: Tue, 28 May 2013 18:31:50 -0300

Hi,

	I have never been a wg chair but I think that this document may be very
useful and helpful (at least it clarifies many things to me).

	I have some comments:

- To me Section 2.1 (Formal Steps) looks better after 2.2 (Criteria of
Adoption).

- Section 2.2 does not set up a criteria. It just ask questions, it
would be good to set basic criteria at least.

- Section 2.2, The paragraph under "REMINDER" it is very important but I
am not convinced 100% how you raised the attention to it (by using
"reminder") But I think that it is very important to point out this.

- Section 3. Also not convinced about the "NOTE", it would be better to
me to include it as part of the text (similar to my comment of
"reminder" of section 2.2.

- There are some questions in different parts of the document, for
example "Shall it be adopted and entirely replace the current working
group draft?  Shall the new ideas be incorporated into the work of the
working group through the normal editorial process? ..." I am not sure
the purpose of those, I imagine that they are helpful questions to ask,
if so I suggest to add something like this to clarify "Important
questions that WG chairs should ask or consider are 'Shall it be adopted
and entirely replace the current working group draft?'..."

Best regards,
as

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 May 2013 10:31:15 -0700

This doc seems more useful as a section of an update to the TAO of the 
IETF. I agree with Brian that putting it forth as a separate document 
may give the unintended impression that this is the formal procedure.

Joe

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 May 2013 19:36:05 +0200

> may give the unintended impression that this is the formal procedure.

Nevermind that it isn't standards track or BCP and that it says quite 
explicitly that it isn't normative?

Just the mere fact that it's a "separate" document will somehow impart 
and implication of official normativeness?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 May 2013 10:44:32 -0700

On May 29, 2013, at 10:36 AM, Dave Crocker <[email-masked]> wrote:

> Nevermind that it isn't standards track or BCP and that it says quite explicitly that it isn't normative?
> 
> Just the mere fact that it's a "separate" document will somehow impart and implication of official normativeness?

Yes. We even have that problem with the Tao itself.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 May 2013 10:42:45 -0700

> explicitly that it isn't normative?

Yes, nevermind that. ;-)

> and implication of official normativeness?

Yes, to some - especially newbies who don't know the process. Except 
that's exactly whom you're trying to reach.

Consider yourself a newbie who has been told that the TAO gives all the 
informal information on how the IETF works. Then you find out about this 
doc. Wouldn't you wonder why it was treated separately? Was it that 
important? Was it not informal enough for the TAO?

There's a lot of nuance here, but overall, I said what I meant - it 
would give the *unintended* *impression* of something beyond what I 
think is the goal.

Joe

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 May 2013 19:51:59 +0200

On 5/29/2013 7:42 PM, Joe Touch wrote:
> informal information on how the IETF works.

OK.  So your premise is that someone has been given seriously flawed 
guidance and based on that we need to fear their misunderstanding of things?

As a rule, the analytic template "somebody somewhere said something 
wrong or critical or otherwise problematic..." is a very, very poor 
basis for making policy.

For any interesting topic and any possible misstatement or criticism, 
there is certain to be someone, somewhere that suffers from having heard 
or said it.

Unless your view is that we must never do anything, let's instead try to 
look at the merits of what exists and how it is seen by reasonable 
people who are being reasonable, rather than make policy decisions on 
the hypothetical of a stray distortion.

> There's a lot of nuance here,

There is no nuance at all in this document.

d/

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 May 2013 10:57:42 -0700

> guidance and based on that we need to fear their misunderstanding of

My premise is that when introducing people to a new game, it makes sense 
to keep things simple and in one place p the TAO.

You can continue to disagree with that if you prefer.

Joe

---

From: Arturo Servin <[email-masked]>
Date: Wed, 29 May 2013 15:40:25 -0300

You can always include add some text from this document in the TAO and
add a reference so anybody wanting to know more could follow.

	Also, to me, this I+D also targets new and not so new WG chairs, not
just new comers.

.as

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 May 2013 20:56:40 +0200

> You can continue to disagree with that if you prefer.

I haven't disagreed with doing that.  I disagreed with saying that that 
document contains everything they need to know.

Entirely different semantics to the two statements.

I think it's a dandy starting document.  But it's a really crappy 'last' 
document.

And by the way, the draft that's been put forward isn't just for 
beginners...

d/

ps.  The real consideration was whether to try to folk this draft into 
Working Group Guidelines and Procedures.  I think that idea actually has 
some reasonable logic to it; but it doesn't have enough benefit to be 
worth the effort of opening up WGG&P a third time, for now.

d/

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 May 2013 12:49:49 -0700

> document contains everything they need to know.

Agreed, but if we have more to say, it would be useful to keep it in a 
single place - esp. given we have that vehicle for doing so.

> I think it's a dandy starting document.  But it's a really crappy 'last'

Good reason to make it better, rather than fracturing that sort of info, 
though.

> And by the way, the draft that's been put forward isn't just for

Nor is the TAO, AFAICT, either.

Joe

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 30 May 2013 07:53:24 +0100

OK, I think Dave and I are going to discuss this.

I see a wedge :-)
The problem is where to stop.

I completely agree that the current I-D does not cover everything and I can see that *some* things can usefully be added. 

OTOH, if we don't draw lines, mission creep will lead us, step-by-step, to attempt to document everything about the IETF in one document. I don't want to go there :-)

So I can see this I-D *possibly* becoming a document lifecycle description.

I can also see potential for adding some info to the Tao, but the danger there is that document becomes too big and too detailed to be of use.

Cheers,
Adrian

> From: Joe Touch [mailto:[email-masked]]
> Sent: 29 May 2013 20:50
> To: [email-masked]
> Cc: Dave Crocker; Brian E Carpenter; [email-masked]; [email-masked]
> Subject: Re: When to adopt a WG I-D
> 
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 29 May 2013 23:06:34 -0800

> The problem is where to stop.

Well, I don't know.  Maybe the problem is where to
start.  That is to say, I don't know what problem
this document is trying to solve, or if there even
is a problem.  I know that we've had some major
document quality issues in opsawg and Benoit has
provided some needed guidance on document adoption,
but this doesn't seem to be dealing with that sort
of issue.  Is it that people are confused about when
to adopt a document (or not)?  Is this intended to
provide some sort of context to resolve complaints?
Is this a tutorial?

To be honest at this point I'm sort of reflexively
anti-process-documents, unless there's an actual problem
that needs actual solution.

Melinda

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 30 May 2013 08:16:51 +0100

Hi Melinda,

Funny, but I agree.

> that needs actual solution.

Which is why this isn't a process document.

The origin is a WG chairs Edu session. Turns out there was not a lot of clarity among a bunch of WG chairs about what they did and why. My assumption is that if the chairs needed some time to discuss this, the community might need that as well.

The problem I am now hearing is that "the document lifecycle is not described coherently in one place." That wasn't the problem I was aiming to solve, but maybe enough others consider it is a problem.

> Is this a tutorial?

Mainly. To quote...

      NOTE:    This draft is intentionally non-normative.  It is meant as a
      guide to common practice, rather than as a formal definition of
      what is permissible.

Adrian

---

From: Melinda Shore <[email-masked]>
Date: Wed, 29 May 2013 23:19:06 -0800

> Which is why this isn't a process document.

Are you sure?

Melinda

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 May 2013 09:24:07 +0200

On 5/30/2013 9:06 AM, Melinda Shore wrote:
> is a problem.

Like you, I think we need to be very careful about creating stray 
process documents or... stray processes.

That said, we have processes and we need to do them well.

The IETF permits an extraordinary degree of flexibility in much of the 
detail for doing the actual work. The main benefit is that it lets a 
group adjust its style of work according to the nature of the work and 
the preferences of the workers.

A small, well-integrated group that is focusing on a narrow, 
well-understood topic can reasonably use a very different daily style 
than a large, highly heterogeneous group that is working on a difficult, 
poorly understood topic.

Currently, that tends to mean that folk invent things on the fly, often 
importing models from other groups.  Both the spontaneous invention and 
the importation risk assorted problems ranging from serious inefficiency 
to outright mismatch with the culture.

What we've lacked is much effort to capture 25+ years of experience of 
doing the grunt work of IETF daily management.  We don't really pass on 
the culture very well, beyond some clever catch phrases and formal 
process structure and criteria specifications.

So the intent of the current draft is to capture one aspect of the 
collective wisdom and pass it on to others.  It is "us" -- all of us -- 
speaking to "them", as if sitting around the bar, talking about how to 
get things done.

The document is quite explicit that it has no force other than 
representing some collective wisdom.

d/

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 30 May 2013 08:56:12 +0100

> > Which is why this isn't a process document.

Oooh, a quiz. I like quizzes.

Let me see. Yes or no. Hmmm.

Yes, I'm sure.

Your turn now.

Are you sure?

Ciao,
Adrian

---

From: Melinda Shore <[email-masked]>
Date: Wed, 29 May 2013 23:58:39 -0800

> Are you sure?

No, not at all.

Melinda

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 May 2013 10:05:57 +0200

> On 5/29/13 11:56 PM, Adrian Farrel wrote:

Let me try to help...

A process document is a normative statement of structure and sequence 
for a process.  It is the organization's means of saying how things must 
be done.  That 'must' might include degrees of freedom, of course, but 
they key point is that whatever it specifies has formal authority within 
the organization.

The current draft is quite explicitly not that.

The current draft is a kindly mentor, sitting around the bar, imparting 
sage advice for how something can be reasonably done, within the formal 
bounds of IETF rules and culture.

It's only 'force' is whatever credibility the individual reader choose 
to assign to the text, as is true for any "Informational" RFC...

d/

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 May 2013 06:17:31 -0700

> No, not at all.

did you somehow miss the pdu data formats and exchange ladder diagram?

if this is not a process document, then what the heck is it, chopped
liver?

randy

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 May 2013 07:59:34 -0700

> I can also see potential for adding some info to the Tao, but the danger there is that document becomes too big and too detailed to be of use.

Many would claim it already is. We discussed that here a few years ago, and informally decided "too long" was better than "too short and with a lot of pointers to other documents that needed to be read".

Mainly. To quote...

Proposal: maybe don't do this as an Internet Draft, but do it as a tutorial.

--Paul Hoffman

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 May 2013 13:40:25 -0400

> Which is why this isn't a process document.

Watching this thread, I sense the authors trying hard not to make a
process document, presumably because that would be hard, contentious,
low probability of success, or something.

But this idea that this ID is just a random collection of thoughts
that folk might find interesting and therefore is informative is also
pretty silly.

Melinda has it right. First decide on what problem you are solving. If
you can't do that, no solution (or document) will be satisfactory.

IMO, this document absolutely needs to be a "process" document if it
is to have any value. It is presumably trying to collect experience
and wisdom. Presumably folk should make use of that experience and
wisdom. If that is not a best practices document, what is?

If this document doesn't provide guidance, in the "should" sense, with
an explanation of why a particular practice makes sense and what can
go wrong if that advice is not followed... then what good is it?

> The origin is a WG chairs Edu session. Turns out there was not a lot
>  of clarity among a bunch of WG chairs about what they did and
>  why. My assumption is that if the chairs needed some time to
>  discuss this, the community might need that as well.

If this document is clarifying, isn't that "updating" an existing
document and charting new ground? I.e, how can this not be normative?

>       guide to common practice, rather than as a formal definition of

What is the difference between a "guide to common practice" and a BCP?
Is attempting to find a difference a case of hair splitting?

Thomas

---

From: t.p. <[email-masked]>
Date: Fri, 31 May 2013 11:08:08 +0100

---- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, May 30, 2013 8:06 AM
> this document is trying to solve, or if there even

So don't start!

I-D adoption is in the gift of the WG Chairs and some do an excellent
job, others make a hash of it (which in turn increases the workload on
other parts of the IETF).

Question is, can we do anything to reduce the hashes without at the same
time impairing excellence (short of improving the quality of WG Chairs,
which I suspect is not realistic)?

I note that this discussion last surfaced on this list six months ago,
almost to the day; my sense then was that that most thought that this
should not become a process but perhaps, like European referenda, the
question will go on being put until the acceptable answer emerges:-)

Tom Petch

                             I know that we've had some major