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

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Fri, 17 January 2014 17:46 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763451A16F0; Fri, 17 Jan 2014 09:46:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level:
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPqV9SGw10Wf; Fri, 17 Jan 2014 09:46:24 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 372951A1F1B; Fri, 17 Jan 2014 09:46:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5750; q=dns/txt; s=iport; t=1389980772; x=1391190372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S2dH8f+vA3/gCPgO5PhxP9HeHbuw2AM53eqPhluxjbk=; b=mweZJ/4uEU6Ee/WCHbXa1oJv/fSa6Zmt0osO/zjw/5vp7OcUVjawkbIR k9IxMYoPbbQc5U4AmwaKKhxhyrHGitGB2PRGv1UQZJ+pV92E6HIO8Gmng 18ZPvfK1fZVDQ4yXNOFEwP352iQ/mN8L6SaehJ5R+9eNn09IvT31HMtBd o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAAJp2VKtJXG8/2dsb2JhbABZgwuqPZFsgQ4WdIIlAQEBAwE6OgUFCwIBCBgeEDIlAgQKBAWHfAjEEBeOTDMHgySBFASYIZIXgy0
X-IronPort-AV: E=Sophos;i="4.95,675,1384300800"; d="scan'208";a="13662548"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-1.cisco.com with ESMTP; 17 Jan 2014 17:46:11 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0HHkBGL019621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jan 2014 17:46:11 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 17 Jan 2014 11:46:10 -0600
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "<adrian@olddog.co.uk>" <adrian@olddog.co.uk>
Thread-Topic: review of draft-crocker-id-adoption-05
Thread-Index: AQHPE5I77i18p0U40EKrtcrrUBqywpqJdMeAgAAPmYD//6x+FQ==
Date: Fri, 17 Jan 2014 17:46:10 +0000
Message-ID: <C1C3F240-7C57-4D90-8C1D-4D068409A73E@cisco.com>
References: <8D28F665-CDF8-4FAA-869E-CA5EF6E673D2@cisco.com> <52D950F9.7050909@bbiw.net>, <05a201cf13a3$7a2e10b0$6e8a3210$@olddog.co.uk>
In-Reply-To: <05a201cf13a3$7a2e10b0$6e8a3210$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-crocker-id-adoption.all@tools.ietf.org" <draft-crocker-id-adoption.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, Dave Crocker <dcrocker@bbiw.net>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] review of draft-crocker-id-adoption-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 17:46:26 -0000

Hi,

> On 17 jan. 2014, at 17:45, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
> 
> 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"
> or
> "Adopting an IETF Working Group Draft"
> or
> "Handling of Internet Drafts by IETF Working Groups"

I like the third

> 
>>> - 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.

I think you misunderstand what I tried to say, I am in no way advocating this, I am stating behavior that I observe. What I am proposing text along the lines of "authors and/or editors may feel like that they "own" the document and strongly influence the final text. The WG chair will have to make sure that WG consensus is properly reflected"

> 
>>> 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.

I understand that, but further down in the document you mention individual submissions without much explanation, I think including it here makes sense to give the reader that is not familiar so the process (the target audience of the document after all) a bit of context.

> 
> [snip]
> 
>>> 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!

Yup, not making a value judgment before, just observing behavior

> 
>> What is the specific change you want?
> 
> [KW] between bullit 2 and 3 add:
> [KW]
> [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)

Yes, this non-native speaker humbly bows his head

> 
>>> 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.


Ok


[snip]

Klaas