[Pce] Re: Shepherd review of draft-ietf-pce-stateful-pce-vendor-06

["Samuel Sidor (ssidor)" <[e-mail]>]

Thanks a lot, Dhruv for review and new proposed statements.

Please check updated draft in enclosures.

For this part:

“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?”

It was added before I joined the draft,  so I’m not sure about history but it really seems to be really copy & paste from RFC8741 and I don’t see any connection to this draft, so I dropped it.

Thanks,
Samuel

From: Dhruv Dhody <[e-mail]>
Sent: Wednesday, August 28, 2024 11:40 AM
To: [e-mail]
Cc: [e-mail]; pce-chairs <[e-mail]>
Subject: Shepherd review of draft-ietf-pce-stateful-pce-vendor-06

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