John, You nailed it. With the suggest NEW text, I think that the PCE charter will be clearer
-éric From: John Scudder <[email protected]> Date: Thursday, 14 December 2023 at 15:52 To: Eric Vyncke (evyncke) <[email protected]> Cc: The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [Pce] Éric Vyncke's No Objection on charter-ietf-pce-07-04: (with COMMENT) In line. Chairs and working group, please speak up quickly if you object to any of the changes proposed below. > On Dec 14, 2023, at 5:19 AM, Éric Vyncke via Datatracker <[email protected]> > wrote: > > > Éric Vyncke has entered the following ballot position for > charter-ietf-pce-07-04: 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.) > > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/charter-ietf-pce/__;!!NEt6yMaO-gk!CAIavEX72YXvVwmh8J-0C0sbHmW9lfDb9qmxJz1gdBk0Vs4nMYBhhmF5LqUbWmgw9CrYES30gLk8$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/charter-ietf-pce/__;!!NEt6yMaO-gk!CAIavEX72YXvVwmh8J-0C0sbHmW9lfDb9qmxJz1gdBk0Vs4nMYBhhmF5LqUbWmgw9CrYES30gLk8$> > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > After re-reading the proposed charter for the n+1 time, some more comments: > > 1) the first paragraph would benefit by directly stating that it is about > MPLS, > SR, BIER, Detnet... rather than adding a 2nd sentence "Further, the PCE WG > ...." Something like this? OLD: The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. Further, the PCE WG also handles protocol extensions for new path setup types of Segment Routing (SR), BIER, and Detnet. NEW: The PCE Working Group is chartered to specify the required protocols to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs, as well as new path setup types of Segment Routing (SR), BIER, and Detnet. > 2) in the same vein, the 2nd paragraph is only about (G)MPLS with terms like > LSR and LSP. As in, OLD: In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may not be physically located on each head-end LSR. The TEAS Working Group is responsible for defining and extending architectures for Traffic Engineering (TE) and it is expected that the PCE and TEAS WGs will work closely together on elements of TE architectures that utilize PCE. NEW: In this architecture path computation does not necessarily occur on the head-end (ingress) router, but on some other path computation entity that may not be physically located on each head-end router. The TEAS Working Group is responsible for defining and extending architectures for Traffic Engineering (TE) and it is expected that the PCE and TEAS WGs will work closely together on elements of TE architectures that utilize PCE. > 3) in the last two bullets: what is the difference between "in cooperation" > and > "in *close* cooperation" ? One is closer than the other? ;-) I think we can strike “close”. > 4) as written in my previous review, it would be clearer if the work items are > directly qualified with 'standard tracks' or if 'specification' was used > rather > than 'definition' Essentially, s/Definition/Specification/ (4x), right? My bad on missing this. Thanks for the additional review and helpful comments, --John
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
