Re: [Last-Call] Opsdir last call review of draft-ietf-lsr-pce-discovery-security-support-10

Qin Wu <bill.wu@huawei.com> Thu, 22 September 2022 01:29 UTC

From: Qin Wu <bill.wu@huawei.com>
To: "Liushucheng (Will LIU, Strategy & Industry Development)" <liushucheng@huawei.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "draft-ietf-lsr-pce-discovery-security-support.all@ietf.org" <draft-ietf-lsr-pce-discovery-security-support.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-lsr-pce-discovery-security-support-10
Thread-Index: AdjOIeNfNnyScE2QRXGGKlZNfjdi5Q==
Date: Thu, 22 Sep 2022 01:24:09 +0000
Message-ID: <a803f3561cfe46ab8247ae890c8c79b6@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/5Dns4nM-EBqe72TGs3sEnDKMSuI>
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-lsr-pce-discovery-security-support-10
Precedence: list

Thanks Will, good catch for the nits. Have fixed in v-11
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-11

-Qin
-----邮件原件-----
发件人: Will LIU via Datatracker [mailto:noreply@ietf.org] 
发送时间: 2022年9月16日 14:56
收件人: ops-dir@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support.all@ietf.org; last-call@ietf.org; lsr@ietf.org
主题: Opsdir last call review of draft-ietf-lsr-pce-discovery-security-support-10

Reviewer: Will LIU
Review result: Has Nits

Hi all,

I have reviewed draft-ietf-lsr-pce-discovery-security-support-10 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. 
Document editors and WG chairs should treat these comments just like any other last call comments.

“When a Path Computation Element (PCE) is a Label Switching Router
   (LSR) participating in the Interior Gateway Protocol (IGP), or even a
   server participating in the IGP, its presence and path computation
   capabilities can be advertised using IGP flooding.  The IGP
   extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
   to advertise path computation capabilities using IGP flooding for
   OSPF and IS-IS respectively.  However these specifications lack a
   method to advertise PCE Communication Protocol (PCEP) security (e.g.,
   Transport Layer Security (TLS), TCP Authentication Option (TCP-AO))
   support capability.”

My overall view of the document is almost 'Ready' for publication, except some editorials below.

** Technical **

No.

** Editorial **

        • Section 1. Introduction
                ○ The fifth paragraph: s/This documents update [RFC5088]/This
                document updates [RFC5088]/
        • Section 3.1 Use of PCEP security capability support for PCE discovery
                ○ The last paragraph: s/If a client is configured to require
                that its PCE server support TCP-AO/If a client is configured to
                require that its PCE server supports TCP-AO; ○ s/If a client is
                configured to require that its PCE server support TLS/If a
                client is configured to require that its PCE server supports TLS
        • Section 5 Backward Compatibility Considerations
                ○ The second paragraph: How to understand "KEYNAME" here?
                s/KEYNAME/KEY-ID and KEY-CHAIN-NAME/?
        • The title of Section 8.1: s/PCE Capability Flag/PCE Capability Flags/
        • Section 9 Acknowledges
                ○ s/speical/special/

Regards,
Will (Shucheng LIU)

[Last-Call] Opsdir last call review of draft-ietf… Will LIU via Datatracker
Re: [Last-Call] Opsdir last call review of draft-… Qin Wu