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@xxxxxxxx [ietf-bounces@xxxxxxxx] On Behalf Of Brian E Carpenter [brian.e.carpenter@xxxxxxxxx] 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