Re: [secdir] SECDIR draft-secretaries-good-practices.06.txt
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Mon, 30 June 2014 16:42 UTC
Return-Path: <cpignata@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 89ABB1A03BC; Mon, 30 Jun 2014 09:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 pDHhn_pOJVtY; Mon, 30 Jun 2014 09:42:26 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A021A0397; Mon, 30 Jun 2014 09:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6128; q=dns/txt; s=iport; t=1404146546; x=1405356146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=43yeDQ6uDvovRbtzUBrCnxyDw/hgzRKDbL1CXMS0OnY=; b=VR5TheC5/OQPgQR1oxqT+RR1a9frdtgCRiz5Ea6w9YB0MMnYZkmyaWTQ SuRZOuHyudxNDjglJHk8fdKE7g9+HVTM36JSsFAVIkuJamzaQteZN5XPV ZPYcI8OC1w/P/oPf4T6CkyZ/ir5vwU4d4QcQnJjd4BOanUtnx+PXi9Av2 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYHALiSsVOtJV2c/2dsb2JhbABagw2BLKsZAQEBAQEBBQFuAZlGAYEOFnWEAwEBAQMBDg9IFAULAgEIRiERJQIEDgWILgMJCMEcDYZSF4Vkg2iDFIF0MweDLYEWAQSKDY5TgX6Na4YSg0KBbiIg
X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="57118567"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 30 Jun 2014 16:42:25 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5UGgPtI004322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 16:42:25 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.80]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 11:42:25 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Chris Lonvick <lonvick.ietf@gmail.com>
Thread-Topic: SECDIR draft-secretaries-good-practices.06.txt
Thread-Index: AQHPjmw7xagMpwpCCE6l9c8WzBkTXZuKO4oA
Date: Mon, 30 Jun 2014 16:42:25 +0000
Message-ID: <264A8ABD-CA61-48A0-8A72-7045DA768AB4@cisco.com>
References: <53A75D6E.3020502@gmail.com>
In-Reply-To: <53A75D6E.3020502@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.102.157.229]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <ED5340E9E7731345A0BEE46CA787E7C1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yOfTmy1fyXPjczFEBIQ5HOgmT7U
Cc: "draft-secretaries-good-practices.all@tools.ietf.org" <draft-secretaries-good-practices.all@tools.ietf.org>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR draft-secretaries-good-practices.06.txt
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: Mon, 30 Jun 2014 16:42:28 -0000
Thank you very much, Chris! Carlos. On Jun 22, 2014, at 6:49 PM, Chris Lonvick <lonvick.ietf@gmail.com> wrote: > Hi, > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Overall the document appears to be well written and thorough. I > have one security related suggestion and some nits. > > It appears that this document suggests that some Secretaries should > be given access to tools that are normally reserved for Chairs, such > as maillist administration. It would be prudent to note in the > Security Considerations section that the Chairs know how to revoke > those privileges in case of problems. > > The authors may wish to consider the following nits. > > The third line of the first paragraph of the Introduction is a bit confusing. > current: > of RFC 2418 [1]). Over time, the WG Secretary role's has greatly > suggested: > of RFC 2418 [1]). Over time, the role of the WG Secretary has greatly > > The last sentence of the second paragraph of the Introduction seems to run on for a bit. > current: > In that regard, part or even all of the guidelines it > provides might not be relevant for the smaller WGs, the Chairs of > which do not need to delegate operational tasks as they handle them > by themselves. > suggested: > In that regard, part or even all of the guidelines provided in this > document might not be relevant for the successful operation of > smaller WGs. In those, the Chairs may not need to delegate > operations tasks. > > The last two sentences of second bullet in Section 3.1.1 could use some more explanation. > current: > The call for discussion slots > should remind these policies as well as how should the requests be > formulated, together with a deadline for sending them. The call would > also typically include information on when will the particular WG > session be held during the IETF meeting noting that the IETF agenda > is draft until being final. > proposed: > The note sent by the Secretary should remind the WG members of the > policies, the formats of requests, and deadlines. > Note: I would just strike the last sentence as that seems to be better discussed in the > next bullet. > > I'll suggest some rewording of "Proposing a WG session agenda" > current: > Based on the collected discussion's slot requests, and depending on > the known preferences of the WG Chairs for the typical structure of > their WG sessions, or on the objectives Chairs have for a particular > WG session, and/or on his/her personal view, the Secretary could > propose to the Chairs a structured agenda for the upcoming WG > session. Following that, the WG Secretary could work with the Chairs > to finalise the agenda in view of publishing a first draft agenda. > proposed: > While the decisions for the slot are to be made by the WG Chairs, > the Secretary can further aid them by proposing a session agenda > based upon his/her knowledge of the preference of the Chairs and > the topical work of the WG. Following that, the WG Secretary could > work with the Chairs to finalize the agenda. > > I'll suggest some rewording of the third paragraph in Section 4. > current: > Although typically a WG might only have one Secretary there is no > reason why two Secretaries might not be appointed. This might be to > help transition a new WG secretary into the role, before the previous > Secretary steps down, or simply to load balance the tasks across two > Secretaries. Reciprocally, a person may perfectly be Secretary of > multiple WGs. This primarily depends on his/her ability to deal with > the induced workload, noting nevertheless that synergies may be > realised in such a situation. In any case, this document does not > give a recommendation on what should be the appropriate value for the > "Secretary / WG" ratio. > proposed: > Typically a WG may have a Secretary to cover the expected workload. > However, a WG may consider having multiple Secretaries if the > workload is very excessive, or to provide an overlap of Secretaries > to transition the role as one steps down. There may also be other > reasons for multiple Secretaries that have not been recognized yet. > > Similar to individuals holding Chair roles in multiple WGs, there is > no known reason why individuals cannot hold Secretary roles in > multiple WGs, or that they may be a Chair of some WGs and Secretary of > other WGs. This will depend on his/her ability to deal with the > workload, noting that synergies may be realized in such situations. > > A couple of minor things in the first paragraph of Section 5 > current: > Section 3 has listed the typical functions and responsibilities of WG > Secretaries. The role of a WG Secretary can range from a few of these > to the full spectrum of them, and even beyond. In that regard, there > is a number of additional WG related events to which the support of > the WG Secretary would be useful. Those for example include planning > and setting for WG interim meetings, design team meetings, etc. > Nevertheless, some tasks described herein apply to these contexts. > proposed: > Section 3 has listed the typical functions and responsibilities of WG > Secretaries. The role of a WG Secretary can range from a few of these > to the full spectrum of them, and even beyond. In that regard, there > may be additional WG related events to which the support of > the WG Secretary would be useful; for example, planning WG interim > meetings. > > Best regards, > Chris
- [secdir] SECDIR draft-secretaries-good-practices.… Chris Lonvick
- Re: [secdir] SECDIR draft-secretaries-good-practi… Carlos Pignataro (cpignata)