RE: I-D Action: draft-crocker-id-adoption-02.txt

[Adrian Farrel]

Thanks Lloyd,

I doubt that we should make commentary on IRTF practices, but you are right that
it would help to clarify This document applies to the IETF stream only (i.e.,
not the IAB, IRTF, or Independent streams)

Thanks,
Adrian

 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
 l.w...@surrey.ac.uk
 Sent: 03 June 2013 02:52
 To: brian.e.carpen...@gmail.com; ietf@ietf.org
 Subject: RE: I-D Action: draft-crocker-id-adoption-02.txt
 
 I'd argue that the draft also needs to discuss IRTF processes, such as they
are.
 
 though the IRTF groups are sufficiently similar to IETF WGs that you might
think
 the same processes apply, having a draft being adopted by an IRTF group means
 far less, for example, and there appear to be other differences.
 
 At the very least, a 'this doesn't cover IRTF research groups, where practices
 very widely' is needed. 
 
 Lloyd Wood
 http://sat-net.com/L.Wood/
 
 
 
 From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Brian E
 Carpenter [brian.e.carpen...@gmail.com]
 Sent: 03 June 2013 00:27
 To: IETF discussion list
 Subject: Re: I-D Action: draft-crocker-id-adoption-02.txt
 
 Hi,
 
 My main positive comment is that it's a good idea to document guidelines
 in this area, and that (viewed as guidelines) I largely agree with
 the draft.
 
 My main negative comment is that although the draft says it's not a
 formal process document, its language in many places belies that.
 For example:
 
  2. Adoption Process
 
 
  2.1. Formal Steps
 
 
 To adopt a new working group document, the chairs need to:
 
 would be better phrased as:
 
  2. Adoption Guidelines
 
  2.1. Typical Steps
 
 To adopt a new working group document, the chairs often:
 
 I'd suggest a careful pass through the text, removing instances
 of words like process, formal and need, and emphasising words
 like guideline and typical and might.
 
 Now some minor comments:
 
 The convention for
 identifying an I-D formally under the ownership of a working group is
 by the inclusion of ietf in the second field of the I-D filename
 and the working group name in the third field,
 
 It's a useful convention but *not* a requirement afaik.
 
 Note
 that from time to time a working group will form a design team to
 produce the first version of a working group draft.
 
 I think that's slightly wrong. A design team draft is *not*
 automatically a WG draft. I think this is more accurate:
 
Note
that from time to time a working group will form a design team to
produce the first version of a document that may be adopted as
a working group draft.
 
 That's an important difference - we've seen cases where design teams
 falsely believed that they had been delegated authority by the WG.
 
   *  Is there strong working group support for the draft?
 
 I think that's going a bit far. Actually a WG might adopt
 a draft because there is support for the *topic* but not for
 the details of the draft as it stands. Indeed, one objective of
 adopting a draft is so that the WG as a whole obtains control
 of the contents - so that they can change it.
 
*  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]]
 
 Actually I'd go the other way: the WG chairs' job at that point is to
 judge the WG's opinion of the draft, not their own opinion. (At least
 once, as a WG chair, I had to declare adoption of a draft to which
 both I and my co-chair were strongly opposed.)
 
  5.1. Individual I-Ds Under WG Care
 ...
 
 OK, but there are in fact four possible outcomes for such a draft
 
 1. As you describe;
 2. The document proceeds as an individual submission to the IESG
without continued WG discussion;
 3. The document proceeds as an Independent Submission to the RFC Editor;
 4. The document is abandoned.
 
 Regards
Brian

Re: I-D Action: draft-crocker-id-adoption-02.txt

[Dave Crocker]

On 6/3/2013 1:27 AM, Brian E Carpenter wrote:

My main negative comment is that although the draft says it's not a
formal process document, its language in many places belies that.
For example:

...

I'd suggest a careful pass through the text, removing instances
of words like process, formal and need, and emphasising words
like guideline and typical and might.


ack.



Now some minor comments:


The convention for
identifying an I-D formally under the ownership of a working group is
by the inclusion of ietf in the second field of the I-D filename
and the working group name in the third field,


It's a useful convention but *not* a requirement afaik.


Times change.  It's now a requirement:

   If the document is accepted as a working
   group document, then it will have the draft-ietf-wg acronym I-D
   filename and will be announced on the working group mailing list by
   the IETF Secretariat. 

--  http://www.ietf.org/ietf-ftp/1id-guidelines.txt



Note
that from time to time a working group will form a design team to
produce the first version of a working group draft.


I think that's slightly wrong. A design team draft is *not*
automatically a WG draft. I think this is more accurate:

Note
that from time to time a working group will form a design team to
produce the first version of a document that may be adopted as
a working group draft.

That's an important difference - we've seen cases where design teams
falsely believed that they had been delegated authority by the WG.


I think what I wrote doesn't mean what you took from it, but of course 
it's worth rewording, to avoid that possibility.


And to broaden its scope a bit, perhaps:

   Note that one way of formulating the first version of a working 
group draft is for the group to commission a design team, or even for 
the design team to self-organize and offer its output for working group 
consideration.




  *  Is there strong working group support for the draft?


I think that's going a bit far. Actually a WG might adopt
a draft because there is support for the *topic* but not for
the details of the draft as it stands. Indeed, one objective of
adopting a draft is so that the WG as a whole obtains control
of the contents - so that they can change it.


Yeah.  Wording is off.  Meant what you suggest, not literally what was 
written.  Will modify accordingly.




   *  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]]


Actually I'd go the other way: the WG chairs' job at that point is to
judge the WG's opinion of the draft, not their own opinion. (At least
once, as a WG chair, I had to declare adoption of a draft to which
both I and my co-chair were strongly opposed.)


moved to the next list, of stuff that's inappropriate...





5.1. Individual I-Ds Under WG Care

...

OK, but there are in fact four possible outcomes for such a draft

1. As you describe;
2. The document proceeds as an individual submission to the IESG
without continued WG discussion;
3. The document proceeds as an Independent Submission to the RFC Editor;
4. The document is abandoned.



mumble. yeah.

but i hope we don't spend too much energy on this topic, given how rare 
it is.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: I-D Action: draft-crocker-id-adoption-02.txt

[Brian E Carpenter]

Hi,

My main positive comment is that it's a good idea to document guidelines
in this area, and that (viewed as guidelines) I largely agree with
the draft.

My main negative comment is that although the draft says it's not a
formal process document, its language in many places belies that.
For example:

 2. Adoption Process
 
 
 2.1. Formal Steps
 
 
To adopt a new working group document, the chairs need to:

would be better phrased as:

 2. Adoption Guidelines

 2.1. Typical Steps

To adopt a new working group document, the chairs often:

I'd suggest a careful pass through the text, removing instances
of words like process, formal and need, and emphasising words
like guideline and typical and might.

Now some minor comments:

The convention for
identifying an I-D formally under the ownership of a working group is
by the inclusion of ietf in the second field of the I-D filename
and the working group name in the third field,

It's a useful convention but *not* a requirement afaik.

Note
that from time to time a working group will form a design team to
produce the first version of a working group draft.

I think that's slightly wrong. A design team draft is *not*
automatically a WG draft. I think this is more accurate:

   Note
   that from time to time a working group will form a design team to
   produce the first version of a document that may be adopted as
   a working group draft.

That's an important difference - we've seen cases where design teams
falsely believed that they had been delegated authority by the WG.

  *  Is there strong working group support for the draft?

I think that's going a bit far. Actually a WG might adopt
a draft because there is support for the *topic* but not for
the details of the draft as it stands. Indeed, one objective of
adopting a draft is so that the WG as a whole obtains control
of the contents - so that they can change it.

   *  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]]

Actually I'd go the other way: the WG chairs' job at that point is to
judge the WG's opinion of the draft, not their own opinion. (At least
once, as a WG chair, I had to declare adoption of a draft to which
both I and my co-chair were strongly opposed.)

 5.1. Individual I-Ds Under WG Care
...

OK, but there are in fact four possible outcomes for such a draft

1. As you describe;
2. The document proceeds as an individual submission to the IESG
   without continued WG discussion;
3. The document proceeds as an Independent Submission to the RFC Editor;
4. The document is abandoned.

Regards
   Brian

RE: I-D Action: draft-crocker-id-adoption-02.txt

[l.wood]

I'd argue that the draft also needs to discuss IRTF processes, such as they are.

though the IRTF groups are sufficiently similar to IETF WGs that you might think
the same processes apply, having a draft being adopted by an IRTF group means
far less, for example, and there appear to be other differences.

At the very least, a 'this doesn't cover IRTF research groups, where practices
very widely' is needed.

Lloyd Wood
http://sat-net.com/L.Wood/



From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Brian E 
Carpenter [brian.e.carpen...@gmail.com]
Sent: 03 June 2013 00:27
To: IETF discussion list
Subject: Re: I-D Action: draft-crocker-id-adoption-02.txt

Hi,

My main positive comment is that it's a good idea to document guidelines
in this area, and that (viewed as guidelines) I largely agree with
the draft.

My main negative comment is that although the draft says it's not a
formal process document, its language in many places belies that.
For example:

 2. Adoption Process


 2.1. Formal Steps


To adopt a new working group document, the chairs need to:

would be better phrased as:

 2. Adoption Guidelines

 2.1. Typical Steps

To adopt a new working group document, the chairs often:

I'd suggest a careful pass through the text, removing instances
of words like process, formal and need, and emphasising words
like guideline and typical and might.

Now some minor comments:

The convention for
identifying an I-D formally under the ownership of a working group is
by the inclusion of ietf in the second field of the I-D filename
and the working group name in the third field,

It's a useful convention but *not* a requirement afaik.

Note
that from time to time a working group will form a design team to
produce the first version of a working group draft.

I think that's slightly wrong. A design team draft is *not*
automatically a WG draft. I think this is more accurate:

   Note
   that from time to time a working group will form a design team to
   produce the first version of a document that may be adopted as
   a working group draft.

That's an important difference - we've seen cases where design teams
falsely believed that they had been delegated authority by the WG.

  *  Is there strong working group support for the draft?

I think that's going a bit far. Actually a WG might adopt
a draft because there is support for the *topic* but not for
the details of the draft as it stands. Indeed, one objective of
adopting a draft is so that the WG as a whole obtains control
of the contents - so that they can change it.

   *  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]]

Actually I'd go the other way: the WG chairs' job at that point is to
judge the WG's opinion of the draft, not their own opinion. (At least
once, as a WG chair, I had to declare adoption of a draft to which
both I and my co-chair were strongly opposed.)

 5.1. Individual I-Ds Under WG Care
...

OK, but there are in fact four possible outcomes for such a draft

1. As you describe;
2. The document proceeds as an individual submission to the IESG
   without continued WG discussion;
3. The document proceeds as an Independent Submission to the RFC Editor;
4. The document is abandoned.

Regards
   Brian