Hi Samuel, Please check inline below.
On Wed, Mar 4, 2026 at 5:00 PM Samuel Sidor (ssidor) <[email protected]> wrote: > Hi Mahesh, > > Please find responses inline <S>. > > Thanks, > Samuel > > *From: *Mahesh Jethanandani via Datatracker <[email protected]> > *Date: *Tuesday, 3 March 2026 at 22:42 > *To: *The IESG <[email protected]> > *Cc: *[email protected] <[email protected]>, > [email protected] < > [email protected]>, > [email protected] <[email protected]>, [email protected] <[email protected]> > *Subject: *Mahesh Jethanandani's No Objection on > draft-ietf-pce-circuit-style-pcep-extensions-14: (with COMMENT) > > Mahesh Jethanandani has entered the following ballot position for > draft-ietf-pce-circuit-style-pcep-extensions-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-pce-circuit-style-pcep-extensions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 4.1, paragraph 4 > > If the O flag is set to 1 (either in the LSP-EXTENDED-FLAG TLV for > > stateful messages or in the RP object for stateless messages) for SR > > paths introduced in [RFC8664], the PCE MUST use only Segment > > Identifiers (SIDs) that explicitly specify adjacencies for packet > > forwarding. Adjacency SIDs should be used, but Prefix SIDs must not > > be used (even if there is only one adjacency). > > Please use BCP14 keywords: > > s/Adjacency SIDs should be used, but Prefix SIDs must not be used/Adjacency > SIDs SHOULD be used, but Prefix SIDs MUST NOT be used/ > > <S> This was changed recently (diff between version 12 and version 13) > since original text was: > > For example, Adjacency SIDs SHOULD be used, but Prefix SIDs MUST NOT be > used (even if there is only one adjacency). > > And we received comment that it is not ideal to specify it as an example, > but still use normative language. Since we are not describing behavior for > all SIDs types and that statement was really supposed to just provide > additional details on previous statement (which is normative already), then > I can change it back to “For example, …” and keep lowercase should/must > not. > > Would that work for you? > > Ketan - I hope that would still be acceptable for you as well. > KT> I am ok with Mahesh's proposal. The original issue that I raised was the use of both "for example" and BCP14 words. Then both were removed. It is OK to use the BCP14 keywords as long as "for example" is not used. Also, this statement does not preclude the use of other types of SIDs so there is no issue. Thanks, Ketan > > The IANA review of this document seems to not have concluded yet. > > > ------------------------------------------------------------------------------- > NIT > > ------------------------------------------------------------------------------- > > All comments below are about very minor potential issues that you may > choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so > there > will likely be some false positives. There is no need to let me know what > you > did with these suggestions. > > Section 8.4, paragraph 6 > > EPS: Usage of TLS to Provide a Secure Transport for the Path Computation > Ele > > ^^^^^^^^^^^^^^^^^^ > Uncountable nouns are usually not used with an indefinite article. Use > simply > "Secure Transport”. > > <S> I guess that this is just false positive as even title of RFC8253 is > “Usage of TLS to Provide a Secure Transport ..." > >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
