[secdir] SecDir review of draft-farrell-ft-03

"Moriarty, Kathleen" <kathleen.moriarty@emc.com> Fri, 01 February 2013 02:35 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4447421F856D for <secdir@ietfa.amsl.com>; Thu, 31 Jan 2013 18:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.27
X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=1.329, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id viiUxde4jVED for <secdir@ietfa.amsl.com>; Thu, 31 Jan 2013 18:35:58 -0800 (PST)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com []) by ietfa.amsl.com (Postfix) with ESMTP id 46ED421F8480 for <secdir@ietf.org>; Thu, 31 Jan 2013 18:35:57 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r112ZsEe018556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 21:35:54 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com []) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 31 Jan 2013 21:35:34 -0500
Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r112ZXlF018823; Thu, 31 Jan 2013 21:35:33 -0500
Received: from mxhub38.corp.emc.com ( by mxhub16.corp.emc.com ( with Microsoft SMTP Server (TLS) id; Thu, 31 Jan 2013 21:35:33 -0500
Received: from mx15a.corp.emc.com ([]) by mxhub38.corp.emc.com ([]) with mapi; Thu, 31 Jan 2013 21:35:33 -0500
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: "iesg@ietg.org" <iesg@ietg.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-farrell-ft.all@tools.ietf.org" <draft-farrell-ft.all@tools.ietf.org>
Date: Thu, 31 Jan 2013 21:34:15 -0500
Thread-Topic: SecDir review of draft-farrell-ft-03
Thread-Index: AQHOACSgBSbJvNzxgEuAal4Y5/4w5Q==
Message-ID: <F5063677821E3B4F81ACFB7905573F24CE33F904@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SecDir review of draft-farrell-ft-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Feb 2013 02:35:59 -0000


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.

   This memo describes an optional, fast-track way to progress a working
   group document to IESG review.  It is provided as a process
   experiment as defined in RFC 3933 for use when working group chairs
   believe that there is running code that implements a working group

I think the draft is well written and just see one nit and one security loop hole that should be addressed or noted as such in the security considerations section.

Nit: Can you clarify if in Section 3, step #7, "some" AD is from that area or from any area?  I think you mean any AD, but would think this would be a requirement from the Area of the WG.

Consideration: I don't agree with the document going forward unless one of the Area ADs has looked at the document.  If this were in my WG, I would coordinate the two week period with the AD on a time frame that will be possible for them to perform the review.  Sometimes a few days makes a difference.

I think changing #3 of step 4 to require coordination could prevent the problem of scheduling during a period that will not work for an AD.  This is a loop hole if the time period is not coordinated.  I could have gotten a lot of documents through during Sean's honeymoon if I wanted to (if he actually went offline ;-)  ).

This is the one loop hole I see as important to add to the security considerations if it is not changed.

Best regards,