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-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk
Sent: 03 June 2013 02:52
To: brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com;
ietf(_at_)ietf(_dot_)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-bounces(_at_)ietf(_dot_)org [ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Brian E
Carpenter [brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)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