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