Subject: Re: Last Call: <draft-crocker-id-adoption-05.txt> (Creating an IETF Working Group Draft) to Informational RFC

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 3 Jan 2014 10:35:35 -0500

The document is in pretty good shape and looks pretty ready for
publication. Note that in the "NOTE" at the top of section 3, at the
beginning of the fourth line, the word "authors" is missing.

Also, the draft uses the older convention of "Network Working Group"
at the top of the boilerplate. If there was ever a draft that should
use the newer convention of "Internet Engineering Task Force (IETF)"
instead, this one probably qualifies.

Cheers,
Andy

On Fri, Jan 3, 2014 at 10:14 AM, The IESG <[email-masked]> wrote:
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Creating an IETF Working Group Draft'
>   <draft-crocker-id-adoption-05.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-01-31. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    The productive output of an IETF working group is documents, as
>    mandated by the working group's charter.  When a working group is
>    ready to develop a particular document, the most common mechanism is
>    for it to "adopt" an existing document as a starting point.  The
>    document that a working group adopts and then develops further is
>    based on initial input at varying levels of maturity.  An initial
>    working group draft might be a document already in wide use, or it
>    might be a blank sheet, wholly created by the working group, or it
>    might represent any level of maturity in between.  This document
>    discusses how a working group typically handles the formal documents
>    that it targets for publication.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-crocker-id-adoption/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-crocker-id-adoption/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 3 Jan 2014 17:32:49 +0000

Hi,

Two small comments, based on observations in TCPM. Obviously, this draft cannot handle all WG specifics, but maybe my two remarks also apply to other WGs...

First, the document could perhaps mention that during the adoption of a draft there can be a discussion about the planned status (e.g., STD vs. EXP), even if the status can change later in the process. In TCPM, this is almost always the case, and therefore the chairs have to consider the planned status as one question when creating/adopting a WG draft.

Second, I am not sure if the following statement in Section 2.2 could be detailed a bit:

      *  Is there strong working group support for working on the draft?

Actually, in TCPM, the "working group support for working on the draft" is often not the most important criteria for adoption. The key one is the more specific question whether there indeed "working group energy for contributing and reviewing". For instance, sometimes, we have the following situation: The community really likes a new, interesting idea, and the WG therefore really wants that "somebody" works out all the nasty protocol details that a full spec would require. This is typically left to the authors of the individual document proposing this idea. Yet, since TCPM deals with a core Internet protocol, having a WG document also implies that the WG should indeed verify this spec, e.g., in all the corner cases that can occur in a complex protocol. And, surprise, surprise, finding volunteers for that is often more difficult than finding people that really like an idea and want the WG to work on it... As a result, the chairs have to think about the completion of any new WG document quite a bit in advance...

If this effect should exist in other WGs as well, maybe one could add some additional explanation regarding the "willingness to contribute and review" to a new WG document. It could also relate to Section 4 as one aspect of document "maturity".

Thanks

Michael

________________________________________
Von: IETF-Announce [[email-masked]]&quot; im Auftrag von &quot;The IESG [[email-masked]]
Gesendet: Freitag, 3. Januar 2014 16:14
An: IETF-Announce
Betreff: Last Call: <draft-crocker-id-adoption-05.txt> (Creating an IETF Working Group Draft) to Informational RFC

Abstract

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Jan 2014 15:11:05 -1000

this draft could be used by those nasty ADs to abuse working groups and
draft authors.  perhaps if it is experimental.

randy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 4 Jan 2014 09:58:16 -0500

> draft authors.  perhaps if it is experimental.

I disagree with Randy. It's the lack of such a draft that can
potentially cause more abuse by ADs "making it up as they go". With
this draft, there's an open, written process to follow, and that
written process can be amended in the future if necessary.

Cheers,
Andy

---

From: Dave Crocker <[email-masked]>
Date: Sat, 04 Jan 2014 14:22:08 -0800

> draft authors.  perhaps if it is experimental.

Even if such pointedly mocking behavior were professionally acceptable, 
the effectiveness of the pseudo-echoing taunt is undermined by its basic 
misapplication.

The current draft is seeking Informational, not BCP.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Sat, 04 Jan 2014 14:33:44 -0800

Michael,

Thanks for the comments.  Responding strictly on my own behalf:

On 1/3/2014 9:32 AM, Scharf, Michael (Michael) wrote:
> First, the document could perhaps mention that during the adoption of
> a draft there can be a discussion about the planned status (e.g., STD
> vs. EXP), even if the status can change later in the process. In
> TCPM, this is almost always the case, and therefore the chairs have
> to consider the planned status as one question when creating/adopting
> a WG draft.

This sounds like another bullet in the Section 2.2. Criteria for 
Adoption list.  Possibly:

    *  Does the intended status of the document seem reasonable to the
       working group?

> Actually, in TCPM, the "working group support for working on the
> draft" is often not the most important criteria for adoption. The key
> one is the more specific question whether there indeed "working group
> energy for contributing and reviewing". For instance, sometimes, we
> have the following situation: The community really likes a new,
> interesting idea, and the WG therefore really wants that "somebody"
> works out all the nasty protocol details that a full spec would
> require. This is typically left to the authors of the individual
> document proposing this idea. Yet, since TCPM deals with a core
> Internet protocol, having a WG document also implies that the WG
> should indeed verify this spec, e.g., in all the corner cases that
> can occur in a complex protocol. And, surprise, surprise, finding
> volunteers for that is often more difficult than finding people that
> really like an idea and want the WG to work on it... As a result, the
> chairs have to think about the completion of any new WG document
> quite a bit in advance...

Hmmm.  Certainly a reasonable scenario, IMO, but I would have thought 
the current draft covers what you describe.

The fact that you don't see that leaves me unclear how to fix this, so 
that there's no doubt it is considered a legitimate scenario.

      1. The document discusses the difference between having the 
document be author-driven vs. working-driven, in Section 3.

      2. I think of the wg reviewing effort you describe as "working on 
the draft" and hence qualifying under the bullet you quote.

Best I can think of is to ask you for suggested text changes/additions.

d/

---

From: S Moonesamy <[email-masked]>
Date: Sun, 05 Jan 2014 03:01:13 -0800

Hi Dave, Adrian,
>final comments on this action. Please send substantive comments to the

Thanks for writing this document.  Over a year ago there was a 
discussion on the a working group mailing list about the (WG) 
adoption of a draft.  It highlighted that a significant number of 
participants do not share the same view of what they are being asked 
when there is a call for adoption of a draft.  The lack of 
documentation, whether formal or informal, makes it difficult for 
someone new to understand what is being asked.  I don't have a strong 
opinion about whether the documentation should be in a Wiki or a RFC.

 From Section 1.2:

   "A core premise of IETF working groups is that the working group has
    final authority over the content of its documents, within the
    constraints of the working group charter.  No individual has special
    authority for the content."

This can be interpreted in different ways.  It has been stated that 
the document editor is responsible for ensuring that a draft 
accurately reflects the decisions that have been made by the working 
group.  The above text can be read as meaning that the document 
editor does not have any authority over the editorial changes.  An 
alternative would be to drop the "no individual ..." sentence.

In Section 3:

   "NOTE:    The distinction between an 'author' and an 'editor' is, at
       best, subjective.  A simplistic rule of thumb is that editors tend
       to do the mechanics of incorporating working group detail, whereas
       tend to create the detail, subject to working group approval."

The word "authors" may be missing before "whereas tend ...".

In Section 4:

   "Absent charter restrictions, a working group is free to create new
    documents."

Such decisions can be controversial.  It is stated (in another 
document) that a charter
is a contract between a working group and the IETF to perform a set 
of tasks.  As an example, a charter might not mention that the 
working group can work on standardizing X.  The working group Chair 
posts a message about the intent to adopt a draft about standardizing 
X.  It might not be clear to some participants that the working group 
intended to take on such work as that task was not mentioned in the 
charter.  To say it differently, a person may consider the new 
document as something minimal where the administrative overhead is 
not worth the effort; someone else might consider that he or she has 
not been given a fair chance to submit a proposal (see competing 
draft discussed in Section 5.2).

In Section 4:

   "It is not required that all drafts start as the effort of an idividual."

There is a typo for "individual".

In Section 5:

   "If the working group has already adopted an I-D on a specific
    topic, the posting of a new individual I-D on the same topic
    could be seen as an attack on the working group processes or
    decisions.  However, posting an I-D is often a good way to put
    new ideas into concrete form and into the public domain for
    consideration and discussion."

As a nit the draft is not in the public domain.  That term is 
sometimes read as "no one owns or controls the material in any 
way".  The quoted text mentions that posting a new (individual) draft 
can be seen as an attack but it is a good way to put ideas in 
concrete form.  It is like saying doing X is good but if a person 
does X the person will look bad.  It is not clear what the guide to 
common practice is.

Regards,
S. Moonesamy

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 5 Jan 2014 18:30:21 +0000

Hi Dave,

Yes, a statement like "Does the intended status of the document seem reasonable to the working group?" in Section 2.2 would make sense a lot of sense to me. This is what I was looking for.

I agree that the WG energy and willingness to review is somehow part of "working on the draft", but I still wonder whether it can be made more explicitly. I am not sure whether it belongs to Section 3, which is about authors/editors selection. WG energy also seems somehow orthogonal to most other sections. Here is one idea for specific text (there are other options as well): If it is hard to find reviewers for a given topic, the document will inherently move forward rather slowely... So, what about the following question in Section 2.2:

  * After adoption, is it likely that the document will move forward in a reasonable timeframe, e.g., as defined by a charter milestone? 

In general, I don't have a particularly strong opinion on my second point, and I don't strongly insist on a change of the draft.

Thanks

Michael

________________________________________
Von: Dave Crocker [[email-masked]]
Gesendet: Samstag, 4. Januar 2014 23:33
An: Scharf, Michael (Michael); [email-masked]
Betreff: Re: Last Call: <draft-crocker-id-adoption-05.txt> (Creating an IETF Working Group Draft) to Informational RFC

Michael,

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 05 Jan 2014 10:43:06 -0800

On 1/5/2014 3:01 AM, S Moonesamy wrote:
> This can be interpreted in different ways.  It has been stated that the
> document editor is responsible for ensuring that a draft accurately
> reflects the decisions that have been made by the working group.  The
> above text can be read as meaning that the document editor does not have
> any authority over the editorial changes.  An alternative would be to
> drop the "no individual ..." sentence.

Frankly, that sentence is what motivated the paragraph.  The IETF 
periodically has a problem with an author who thinks that their 
judgement carries more weight than the working group's.  This paragraph 
is meant to remind us all that authors are not the final authority for 
content.

If A is an employee of B, A has job responsibilities.  But those 
responsibilities do not (usually) include having more authority over the 
work than B.  A is (merely) and agent of B.

(And B is probably an agent of C.  Everybody works for somebody.  They 
should probably write a song about that.)

An author is appointed by the Chair, but works for the working group and 
the working group has final authority, not the author.  Note that WG 
Guidelines and Procedures (RFC 2418) already makes this point:

      6.1. WG Chair
      ...
      Document development

       Working groups produce documents and documents need authors. The
       Chair must make sure that authors of WG documents incorporate
       changes as agreed to by the WG (see section 6.3).

I'm not sure how to have the text make this point more clearly in the draft.

> The word "authors" may be missing before "whereas tend ...".

You're the third person to note this.  I think that counts as consensus...

> Such decisions can be controversial.  It is stated (in another document)

Working Group Guidelines & Procedures

> that a charter
> is a contract between a working group and the IETF to perform a set of
> tasks.  As an example, a charter might not mention that the working
> group can work on standardizing X.  The working group Chair posts a
> message about the intent to adopt a draft about standardizing X.  It
> might not be clear to some participants that the working group intended
> to take on such work as that task was not mentioned in the charter.  To
> say it differently, a person may consider the new document as something
> minimal where the administrative overhead is not worth the effort;
> someone else might consider that he or she has not been given a fair
> chance to submit a proposal (see competing draft discussed in Section 5.2).

Interesting point.

I believe working groups often do things like adding a document, or 
splitting a document into two or even combining documents, without 
changing their charter.  I guess I've understood the essential question 
for changing the charter to be when the substance of the group's work is 
changed.

To the extent that a scenario, of the type you describe, causes debate 
within a working group, I would think that it's usually healthy for the 
group, since it can produce better clarity about the group's work.

I'm not sure a document like the current draft should seem to be more 
precise on this than it currently is.  In other words, yes, the 
controversy/confusion you cite happens, but we probably should not 
change the current draft to affect that.

> As a nit the draft is not in the public domain.  That term is sometimes

hmmm. yeah.  Strange wording choice, especially since as you note the 
phrase is a formal term of art.  No memory of what produced that 
wording.  I think better wording would be:

       However, posting an I-D is often a good way to put
       new ideas into concrete form, for public
       consideration and discussion."

> read as "no one owns or controls the material in any way".  The quoted
> text mentions that posting a new (individual) draft can be seen as an
> attack but it is a good way to put ideas in concrete form.  It is like
> saying doing X is good but if a person does X the person will look bad.
> It is not clear what the guide to common practice is.

The paragraph is meant to counter-act the reaction people sometimes 
have, that posting an alternative draft is automatically a bad thing, by 
noting that it can be a valid form of commenting on an existing, other 
draft.

d/

---

From: t.p. <[email-masked]>
Date: Mon, 6 Jan 2014 10:29:36 +0000

<inline <tp>>

----- Original Message -----
From: "Scharf, Michael (Michael)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Sunday, January 05, 2014 6:30 PM

Hi Dave,

Yes, a statement like "Does the intended status of the document seem
reasonable to the working group?" in Section 2.2 would make sense a lot
of sense to me. This is what I was looking for.

I agree that the WG energy and willingness to review is somehow part of
"working on the draft", but I still wonder whether it can be made more
explicitly. I am not sure whether it belongs to Section 3, which is
about authors/editors selection. WG energy also seems somehow orthogonal
to most other sections. Here is one idea for specific text (there are
other options as well): If it is hard to find reviewers for a given
topic, the document will inherently move forward rather slowely... So,
what about the following question in Section 2.2:

<tp>
Michael

I track TCPM and so know of your approach, but other WGs are at the
other end of the spectrum, seeming almost to say
 - noone has said anything so we will adopt this I-D
 - noone has said anything so we will move to WGLC
 - noone has said anything so we will move this to the IESG
even when dealing with core Internet Procotols.

I have not analysed the results but suspect that the output of such WG
lead to more IETF LC comments or more errata or more -bis or ...

But there is an enormous spectrum.  Another example is a limit on the
cache size of WG I-Ds - no further I-Ds can be adopted until one of the
current ones has been handed on to the IESG; this, for me, is the worst
approach so far - perhaps sound business management practice but not so
sound engineering, at least from my perspective.

So, the concern as alway with these process I-Ds is that they tend to
become overprescriptive and reduce the quality or rate or both of the
work that the IETF does.

A good process I-D is one that seeks to eliminate bad practice, one that
increases the mean by focussing on the minima, one that seeks to remove
the defective WG Chair behaviour - or if that proves impractical, remove
the WG Chair :-(  Ones that seek to promote best practice usually
constrain the good practioners too much, prevent us from finding better
ways of working.

Tom Petch

  * After adoption, is it likely that the document will move forward in
a reasonable timeframe, e.g., as defined by a charter milestone?

In general, I don't have a particularly strong opinion on my second
point, and I don't strongly insist on a change of the draft.

Thanks

Michael

________________________________________
Von: Dave Crocker [[email-masked]]
Gesendet: Samstag, 4. Januar 2014 23:33
An: Scharf, Michael (Michael); [email-masked]
Betreff: Re: Last Call: <draft-crocker-id-adoption-05.txt> (Creating an
IETF Working Group Draft) to Informational RFC

Michael,

d/

---

From: S Moonesamy <sm@+ietfelandsys.com>
Date: Sun, 05 Jan 2014 11:46:47 -0800

Hi Dave,
>I'm not sure how to have the text make this point more clearly in the draft.

Thanks for the explanation.  I am okay with no changes.

>You're the third person to note this.  I think that counts as consensus...

:-)

>changing their charter.  I guess I've understood the essential 
>question for changing the charter to be when the substance of the 
>group's work is changed.
>
>To the extent that a scenario, of the type you describe, causes 
>debate within a working group, I would think that it's usually 
>healthy for the group, since it can produce better clarity about the 
>group's work.
>
>I'm not sure a document like the current draft should seem to be 
>more precise on this than it currently is.  In other words, yes, the 

I am okay with the above.

>hmmm. yeah.  Strange wording choice, especially since as you note 
>the phrase is a formal term of art.  No memory of what produced that 

The (above) wording is fine.

>have, that posting an alternative draft is automatically a bad 
>thing, by noting that it can be a valid form of commenting on an 
>existing, other draft.

Ok.

Regards,
S. Moonesamy

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 6 Jan 2014 16:20:56 +0000

Hi Tom,

Obviously WGs operate very differently. My observation when reading draft-crocker-id-adoption-05 was that it has a lot of good thoughts - and that is why I find the document indeed useful. I just want to feed back some additional questions that I sometimes have to deal with, under the assumptions that other WGs may run into similar questions from time to time, too. Obviously, that assumption might be wrong, and I stated this already in my initial posting. I don't want to start a process discussion.

But, for what it is worth, I don't understand why mentioning a question about the intended status of a document as well as a question on the milestone deadline would "constrain the good practioners". I have to deal with both questions each time we adopt a new draft as WG document, and I thought it could be useful to have them in the kind of checklist that draft-crocker-id-adoption provides. For instance, both questions are also valid ones for a WG that adopts all drafts nobody objects to.

Thanks

Michael

________________________________________
Von: t.p. [[email-masked]]
Gesendet: Montag, 6. Januar 2014 11:29
An: Scharf, Michael (Michael); [email-masked]; [email-masked]
Betreff: Re: Last Call: <draft-crocker-id-adoption-05.txt> (Creating an IETF Working Group Draft) to Informational RFC

<inline <tp>>

----- Original Message -----
From: "Scharf, Michael (Michael)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Sunday, January 05, 2014 6:30 PM

Hi Dave,

<tp>
Michael

Tom Petch

Thanks

Michael

Michael,

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Jan 2014 10:17:21 -0800

>    that it targets for publication.

I think this generally looks good, especially given SM's comments and
Dave's replies.  A few other minor points:

The process for adoption described in Section 2.1 is obsolete, as I
understand it.  I believe the current process is to have the
authors/editors submit the -00 version to the tracker, and the tracker will
block publication until a WG co-chair approves.  I also believe the
"replaced-by" step is now available via the tracker to WG chairs, so
there's no need to contact the secretariat.

The document needs a spell check ("idividual", for example).

Along the lines of the above: What do people think about documents that
describe how the tools work, other than the ones that explicitly define the
tools?  If the datatracker evolves in the near future, the tools-specific
remarks of this document could become obsolete.  Might it be better to talk
about tools-specific processes more in the abstract?

That's all that jumped out at me.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Jan 2014 15:49:56 -0800

On 1/6/2014 10:17 AM, Murray S. Kucherawy wrote:
> authors/editors submit the -00 version to the tracker, and the tracker
> will block publication until a WG co-chair approves.  I also believe the

I think this highlights the need for some documentation on the use of 
the tracker, explicitly covering some specific scenarios such as this one.

The -adoption document is meant to focus on the working group side of 
things.

So I'd wish that the portion of -adoption that gives sequences for the 
tracker could, instead, simply cite a tracker document. The draft 
provides detail about using the tracker only because there does not 
appear to be any existing documentation to point to.  (The only existing 
document is an RFC that specifies requirements, not procedures.)  And 
just so there is no confusion:  what is needed is more than a document 
of individual functions; there needs to be instruction for accomplishing 
common /sequences/. That is, how to combine the individual functions.

Absent that, here's the change to -adoption that covers what Murray has 
highlighted:

>           1.  Inform the working group of the intent.
>
>           2.  Check for known IPR that needs to be disclosed, using some
>               technique like those described in [RFC6702]
>
>           3.  Obtain working group rough consensus.
>
>           4.  Choose document editors.
>
>           5.  Pre-approve the document as an Internet Draft, using
>               [Approval].
>
>           6.  Tell the editors to submit the -00 version of the document.
>
>           7.  Request Secretariat to ensure that the Datatracker records
>               that the old internet-draft has been replaced by the new
>               working group draft.
>
>           8.  Enjoy the ensuing working group discussion...
>

becomes:

       1.  Inform the working group of the intent.

       2.  Check for known IPR that needs to be disclosed, using some
           technique like those described in [RFC6702]

       3.  Obtain working group rough consensus.

       4.  Choose document editors.

       5.  Authors/editors submit the -00 version to the tracker;
           the tracker will block publication.

       6.  WG co-chair approves the draft to the tracker.

       7.  WG co-chair uses tracker "Replaced-By" featres, to indicate
           that that the old internet-draft has been replaced by the new
           working group draft.

       8.  Enjoy the ensuing working group discussion...

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jan 2014 16:32:36 +1300

Hi,

I'm sorry to come late to this draft. It's very useful but
I have a few comments.

> Working groups use this mechanism
> for producing their official output, per Section 7.2 of [RFC2418] 

Perhaps this also needs to refer to Section 2.2 of [RFC2026] which
is the basic description of I-Ds.

>    draft-ietf-<wgname>-...

Maybe it's mentioned later, but I think a warning that this
convention is not always followed would be useful.
(If you doubt me, check draft-rosen-rph-reg-policy, a sipcore
draft that I recently reviewed for Gen-ART.)

> In formal terms, a working group raises and discusses each item of
> document content.  For difficult topics and/or difficult working
> group dynamics, this is the required mode.  It is laborious, but
> diligent, and it validates progress at each step along the way.

Excuse me if I describe this text as turgid; it's certainly hard to
read. Does it mean the following?

 In theory, a working group considers each item in a document and
 possibly modifies it before approval. For difficult topics, or for
 cases where the working group is contentious, there is no alternative
 to discussing each item. This is a laborious process requiring great
 diligence, and it validates progress at each step along the way.

> *  Can an Individual I-D be under the care of a WG?

How about adding

 *  Can a WG I-D become an Individual I-D?

>    When there is an existing document and the chairs want to propose
>    adopting it as a new working group document

There are two paths to this point:

1. The existing document was solicited by the WG, because it corresponds
to an item in the WG charter, and the normal expectation is that the
document will be adopted.

2. The existing document was unsolicited, and might even require a charter
update.

> Adoption, not approval:    The document is not required to already
> contain a complete and/or sufficient solution, although of
> course this can be helpful.

Also, adoption does not guarantee eventual publication as
an RFC; the WG could later abandon the document.

> 5.1. Individual I-Ds Under WG Care
...
> Typically such documents are handled according to normal, internal
> working group process management.  However matters of ownership,
> working group final approval, and the like are all subject to
> negotiation amongst the document authors, working group and area
> directors.

I am not so sure about that "typically". In fact I'm confused by
what you mean. If I write draft-carpenter-6man-foobar, and 6man
is interested in it, it will end up as draft-ietf-6man-foobar.
If 6man isn't interested in it, and I decide to pursue it, it's
possible I will submit it to an AD, with or without the 6man
chairs being helpful, or maybe I'll submit it to the Independent
Series Editor. But I don't know what you mean about such a draft
being handled *under its individual name* according to normal
working group process management, unless it's been adopted but
not renamed (like draft-rosen-rph-reg-policy).

Regards
   Brian Carpenter

---

From: Randy Bush <[email-masked]>
Date: Mon, 13 Jan 2014 15:34:54 +0900

> possibly modifies it before approval.

if you mean approval as in wglc, indeed.  if you mean approval as a wg
draft to be worked on by the wg, hell no.  the purpose of a wg adopting
a draft is specifically so it can go through it with a fine toothed
comb, get consensus, and get it in publishable shape.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Jan 2014 10:30:38 +1300

> comb, get consensus, and get it in publishable shape.

Correct. s/approval/final approval/ might clarify.

   Brian