Re: [secdir] review of draft-ietf-pals-redundancy-spe-02

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 16 October 2015 07:50 UTC

Return-Path: <jie.dong@huawei.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 E9B271B302E; Fri, 16 Oct 2015 00:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JrSoxKo5sW30; Fri, 16 Oct 2015 00:50:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEFB1B302D; Fri, 16 Oct 2015 00:50:50 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYW51049; Fri, 16 Oct 2015 07:50:48 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Oct 2015 08:50:46 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Fri, 16 Oct 2015 15:50:38 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Joseph Salowey <joe@salowey.net>, secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-pals-redundancy-spe.all@tools.ietf.org" <draft-ietf-pals-redundancy-spe.all@tools.ietf.org>
Thread-Topic: review of draft-ietf-pals-redundancy-spe-02
Thread-Index: AQHRB8a/ZADRztC2aE6hhQoD0pCi+J5tvmKQ
Date: Fri, 16 Oct 2015 07:50:38 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927743BB161@nkgeml512-mbx.china.huawei.com>
References: <CAOgPGoCauOqQpddpp+8tvztw20j7nvpPCCFSY=S_tvT4opnfUw@mail.gmail.com>
In-Reply-To: <CAOgPGoCauOqQpddpp+8tvztw20j7nvpPCCFSY=S_tvT4opnfUw@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.131]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927743BB161nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/-FR1DVBDPDAY0HmWunXL5flL3rE>
X-Mailman-Approved-At: Thu, 22 Oct 2015 07:18:02 -0700
Subject: Re: [secdir] review of draft-ietf-pals-redundancy-spe-02
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: <https://mailarchive.ietf.org/arch/browse/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, 16 Oct 2015 07:50:54 -0000

Hi Joe,

Thanks a lot for your review and suggestions.  We will expand all the acronyms on first use.

Best regards,
Jie

From: Joseph Salowey [mailto:joe@salowey.net]
Sent: Friday, October 16, 2015 11:57 AM
To: secdir; The IESG; draft-ietf-pals-redundancy-spe.all@tools.ietf.org
Subject: review of draft-ietf-pals-redundancy-spe-02

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.

From a security perspective I think the document is ready.  I think the document could be cleaned up a little to make reading a little bit easier.

The document discusses a new pseudo wire redundancy mode.  I did not find the document particularly clear, it would probably help to expand all the acronyms on first use.   The document only refers to several other documents for its security considerations.  While this is often not the favored approach in this case it seems to be OK as best as I can tell.  The document doesn't appear to be defining anything fundamentally new that would change the considerations in the referenced documents or require special attention.

Cheers,

Joe