MIME-Version: 1.0
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Wed, 28 Aug 2024 15:09:36 +0530
Message-ID: 
 <CAP7zK5b6=3V1b6LTLtmoant-_WrBKfMWGHZqeD8-2MsEPkSF-A@mail.gmail.com>
To: draft-ietf-pce-stateful-pce-vendor@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001425e50620bb256e"
Message-ID-Hash: 32IHLHYOCYAYOX5DE74NACNCVEPH6UUP
CC: pce@ietf.org, pce-chairs <pce-chairs@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BPce=5D_Shepherd_review_of_draft-ietf-pce-stateful-pce-vendor-06?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/pce/DlVAxL2SCNnPsbWhBT_sg6Q4By8>

--0000000000001425e50620bb256e
Content-Type: text/plain; charset="UTF-8"

Hi Authors,

I have completed my shepherd review. There are only a few comments and
nits. Please fix them and we would be ready to ship this to our AD.

## Comments

- Introduction, the last paragraph
````
OLD:
This document extends the usage of the Vendor Information Object and
the VENDOR-INFORMATION-TLV to Stateful PCE.  The VENDOR-INFORMATION-
TLV can be carried inside any of the new objects added in PCEP for
Stateful PCE as per [RFC7470], this document extends the stateful
PCEP messages to include the Vendor Information Object as well.
NEW:
The Vendor Information Object and the VENDOR-INFORMATION-TLV are
also valuable in the Stateful PCE model. The VENDOR-INFORMATION-TLV
can be included within any of the new objects introduced in PCEP
for Stateful PCE as defined in [RFC7470]. This document extends
stateful PCEP messages to incorporate the Vendor Information
Object.
END
````

- Add a new section 1.2
````
1.2.  Use of RBNF

   The message formats in this document are illustrated using Routing
   Backus-Naur Form (RBNF) encoding, as specified in [RFC5511].  The use
   of RBNF is illustrative only and may elide certain important details;
   the normative specification of messages is found in the prose
   description.  If there is any divergence between the RBNF and the
   prose, the prose is considered authoritative.
````

- I am unsure about this text in Section 4.6 - "Further, the mechanism
described in this document can help the operator to request control of the
LSPs at a particular PCE." Is it a copy-paste error when you borrowed the
text from a different document?

- I also suggest changing this text "Section 6.6 of [RFC7470] describes
congestion mitigation methods for a PCC for Stateless PCEP messages" to
"Section 6.6 of [RFC7470] highlights how the presence of additional
vendor-specific information in PCEP messages may congest the operations and
how to detect and handle it"

- Section 7, I suggest this text, which we have been using in the recent
RFCs -
````
OLD:
   As stated in [RFC6952], PCEP implementations SHOULD support the TCP-
   AO [RFC5925] and not use TCP MD5 because of TCP MD5's known
   vulnerabilities and weakness.  PCEP also supports Transport Layer
   Security (TLS) [RFC8253] as per the recommendations and best current
   practices in [RFC9325].
NEW:
   As per [RFC8231], it is RECOMMENDED that these PCEP extensions
   only be activated on authenticated and encrypted sessions across PCEs
   and PCCs using Transport Layer Security (TLS) [RFC8253], as per the
   recommendations and best current practices in RFC 9325 [BCP195]
   (unless explicitly set aside in [RFC8253]).
````

## Nits

- s/traffic engineered/traffic-engineered/

- s/stateless Path Computation Element Communication Protocol
(PCEP)/stateless PCE Communication Protocol (PCEP) messages/

- s/with [RFC8231] as base/with [RFC8231] as the base/

- s/update attributes of an LSP/update the attributes of an LSP/

- s/In addition, requirements and considerations/In addition, the
requirements and considerations/

- s/The registrations procedures/The registration procedures/

Thanks!
Dhruv

--0000000000001425e50620bb256e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:trebuche=
t ms,sans-serif;color:#073763">Hi Authors,=C2=A0</div><div class=3D"gmail_d=
efault" style=3D"font-family:trebuchet ms,sans-serif;color:#073763"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:trebuchet ms,sans-seri=
f;color:#073763">I have completed my shepherd review. There are only a few =
comments and nits. Please fix them and we would be ready to ship this to ou=
r AD.=C2=A0<br><br>## Comments<br><br>- Introduction, the last paragraph<br=
>````<br>OLD:<br>This document extends the usage of the Vendor Information =
Object and<br>the VENDOR-INFORMATION-TLV to Stateful PCE.=C2=A0 The VENDOR-=
INFORMATION-<br>TLV can be carried inside any of the new objects added in P=
CEP for<br>Stateful PCE as per [RFC7470], this document extends the statefu=
l<br>PCEP messages to include the Vendor Information Object as well.<br>NEW=
:<br>The Vendor Information Object and the VENDOR-INFORMATION-TLV are <br>a=
lso valuable in the Stateful PCE model. The VENDOR-INFORMATION-TLV <br>can =
be included within any of the new objects introduced in PCEP <br>for Statef=
ul PCE as defined in [RFC7470]. This document extends <br>stateful PCEP mes=
sages to incorporate the Vendor Information <br>Object.<br>END<br>````<br><=
br>- Add a new section 1.2<br>````<br>1.2.=C2=A0 Use of RBNF<br><br>=C2=A0 =
=C2=A0The message formats in this document are illustrated using Routing<br=
>=C2=A0 =C2=A0Backus-Naur Form (RBNF) encoding, as specified in [RFC5511].=
=C2=A0 The use<br>=C2=A0 =C2=A0of RBNF is illustrative only and may elide c=
ertain important details;<br>=C2=A0 =C2=A0the normative specification of me=
ssages is found in the prose<br>=C2=A0 =C2=A0description.=C2=A0 If there is=
 any divergence between the RBNF and the<br>=C2=A0 =C2=A0prose, the prose i=
s considered authoritative.<br>````<br><br>- I am unsure about this text in=
 Section 4.6 - &quot;Further, the mechanism described in this document can =
help the operator to request control of the LSPs at a particular PCE.&quot;=
 Is it a copy-paste error when you borrowed the text from a different docum=
ent? <br><br>- I also suggest changing this text &quot;Section 6.6 of [RFC7=
470] describes congestion mitigation methods for a PCC for Stateless PCEP m=
essages&quot; to &quot;Section 6.6 of [RFC7470] highlights how the presence=
 of additional vendor-specific information in PCEP messages may congest the=
 operations and how to detect and handle it&quot;<br><br>- Section 7, I sug=
gest this text, which we have been using in the recent RFCs - =C2=A0<br>```=
`<br>OLD:<br>=C2=A0 =C2=A0As stated in [RFC6952], PCEP implementations SHOU=
LD support the TCP-<br>=C2=A0 =C2=A0AO [RFC5925] and not use TCP MD5 becaus=
e of TCP MD5&#39;s known<br>=C2=A0 =C2=A0vulnerabilities and weakness.=C2=
=A0 PCEP also supports Transport Layer<br>=C2=A0 =C2=A0Security (TLS) [RFC8=
253] as per the recommendations and best current<br>=C2=A0 =C2=A0practices =
in [RFC9325].<br>NEW:<br>=C2=A0 =C2=A0As per [RFC8231], it is RECOMMENDED t=
hat these PCEP extensions<br>=C2=A0 =C2=A0only be activated on authenticate=
d and encrypted sessions across PCEs<br>=C2=A0 =C2=A0and PCCs using Transpo=
rt Layer Security (TLS) [RFC8253], as per the <br>=C2=A0 =C2=A0recommendati=
ons and best current practices in RFC 9325 [BCP195] <br>=C2=A0 =C2=A0(unles=
s explicitly set aside in [RFC8253]).<br>````<br><br>## Nits<br><br>- s/tra=
ffic engineered/traffic-engineered/<br><br>- s/stateless Path Computation E=
lement Communication Protocol (PCEP)/stateless PCE Communication Protocol (=
PCEP) messages/<br><br>- s/with=C2=A0[RFC8231]=C2=A0as base/with=C2=A0[RFC8=
231]=C2=A0as the base/<br><br>- s/update attributes of an LSP/update the at=
tributes of an LSP/<br><br>- s/In addition, requirements and considerations=
/In addition, the requirements and considerations/<br><br>- s/The registrat=
ions procedures/The registration procedures/<br></div><div class=3D"gmail_d=
efault" style=3D"font-family:trebuchet ms,sans-serif;color:#073763"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:trebuchet ms,sans-seri=
f;color:#073763">Thanks!=C2=A0</div><div class=3D"gmail_default" style=3D"f=
ont-family:trebuchet ms,sans-serif;color:#073763">Dhruv</div></div>

--0000000000001425e50620bb256e--