Re: [secdir] review of draft-crocker-id-adoption-05

"Adrian Farrel" <> Fri, 17 January 2014 16:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E36F1AE152; Fri, 17 Jan 2014 08:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0F2Ry9HXiTtj; Fri, 17 Jan 2014 08:45:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 262E81AE11E; Fri, 17 Jan 2014 08:45:27 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id s0HGj4Zv009647; Fri, 17 Jan 2014 16:45:04 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s0HGj0Ym009606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Jan 2014 16:45:02 GMT
From: "Adrian Farrel" <>
To: "'Dave Crocker'" <>, "'Klaas Wierenga \(kwiereng\)'" <>, <>, <>, <>
References: <> <>
In-Reply-To: <>
Date: Fri, 17 Jan 2014 16:45:03 -0000
Message-ID: <05a201cf13a3$7a2e10b0$6e8a3210$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHG90e9rK7IrlCmVkLUD6+RlR5XMgENcrQtmpDof/A=
Content-Language: en-gb
Subject: Re: [secdir] review of draft-crocker-id-adoption-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jan 2014 16:45:29 -0000

Hi all,

> > - I think the title "Creating an IETF Working Group Draft" is a
> > misnomer, at least it led me to believe that it would be a guide for
> > creating a draft, i.e. what template, what sections, how to use the
> > tools etc. Something like "the lifecycle of an IETF WG Draft" seems
> > more appropriate.
> Well, the scope of the document did expand, over iterations.  At this
> point I'm probably too deep in the details to have a good sense of a
> good title, though I always appreciate efforts at better titles.  If
> folks think the document really is broad enough to cover wg doc
> lifecycle, that's fine with me.
> Adrian?

Noting that the filename is I offer

"Observations on the Process for Creating an IETF Working Group Draft"
"Adopting an IETF Working Group Draft"
"Handling of Internet Drafts by IETF Working Groups"

> > - Since this is a document that aims to document the actual way the
> > WG drafts are handled I wonder whether you should mention that
> > reality is not always what is put on paper. For example whereas
> > change control lies with the WG rather then the author, in reality
> > the author often has a strong influence on what is being published.
> I thought there were enough qualifiers in the document, to this point.
> So please suggest specific addition/changes.  Sometimes too much of that
> kind of commentary can overload a doc to the point of distraction, but
> that's not likely for this case.  So you point and suggest text and I'll
> add it.  (Adrian has also been easy-going about such things with the draft.)

While I would welcome suggestions of text on this point I am less that
easy-going about documenting worst current practice. In fact, I think I take
issue with what Klaas says: it may well be that document editors/authors have
strong influence on the text that is generated, but if the WG is being denied
the opportunity to review and object to the text (possibly after a revision of
the I-D has been posted), then the WG is not being run well. So I am happy with
the text as it stands.

> > 1.1:
> >
> > - since in section 5.1 the individual submissions pops up, it may
> > make sense to add a  note here that says something like: "NOTE: in
> > addition to WG drafts each individual can also independently submit a
> > draft (that may at a later stage either or not be adopted by a WG)"
> How's this (adding after <wgname>):

It's a good change as Dave presents it, but this document is not attempting to
reproduce a discussion of all the mechanics of the IETF.


> > 2.1:
> >
> > - I usually (especially with relative newcomers) explicitly make the
> > authors of a submitted draft aware of the fact that they give up
> > change control for their love baby to the WG.
Which was, I thought, the point of the text that you objected to before!

> What is the specific change you want?

[KW] between bullit 2 and 3 add:
[KW] - verify that the draft submitters are aware that they transfer
[KW]    change control for the document to the WG (and the IETF)

Works for me, but maybe...
 - remind the draft submitters that they transfer change control for
    the document to the WG (and the IETF)

> > 2.2:
> >
> > - Also in other sections, but especially when it is about adopting a
> > draft and/or determining whether it fits in the charter there is
> > often quite a bit of involvement from the AD's, I think you need to
> > at least mention the role of the AD wrt the WG process.
> I think this varies quite a bit, and suggest we be careful about saying
> anything that sounds like a requirement for this, especially since there
> is a long-standing desire to /reduce/ AD load, not increase it.
> In formal terms, I believe the AD is /not/ part of the draft adoption
> process.  They can interact about anything in the wg, of course, but
> noting any specific like this could too easily confuse folk that it is
> necessary.

Whether it is a matter of AD load or obsessive micro-management, the chairs run
the WGs not the ADs. Sure, if a chair is found to be in the weeds, the AD will
yank him back or cut him loose, but that is not the AD making the decisions. (Oh
and a chair can ask the AD for any advice, of course.)

Thus, the point of this document is to tell chairs what they are free to do. If
the ADs object, no doubt they will shout at us during IESG review, but I am
pretty confident that the current IESG will say that it is not the AD's job to
make the decisions, merely to hold chairs' feet to the flames.

> > - I usually also try to judge if we have a reasonable expectation of
> > finishing up the to be adopted work (workload WG, research character
> > etc.)
> So add to Criteria:
>     o Is the draft likely to be completed in a timely manner?
> That's more generic than you've suggested, but I figure the whole point
> of such a bullet is simply to get folk to think about the going-forward
> pragmatics.

Looks good.

> > - "is a simple modification to the charter feasible and warranted",
> > how about large modifications, are they ever feasible and warranted?
> I think the first bullet implies this issue well enough:
>     o Is there a charter milestone that explicitly calls for such a
> document?
> We need to be careful that the list isn't too picky with details.
> > - "Group, not chairs:   Concerning the draft, the position of the
> > working group chairs has no special authority.", I think that is only
> > true wrt technical content, the chair does have special authority to
> > make sure that WG consensus is properly represented, that due process
> > is followed etc.
>     Concerning the draft, the position of the working group chairs has
>     no special authority, except to assess working group consensus.