Hi Adrian Many thanks for these comments. I'm picking up this thread and replying as PCE working group chair, as the authors are unavailable. I apologise for the delay. Please see my proposed resolutions inline below, marked with "Jon>" Best regards Jon -----Original Message----- From: Adrian Farrel [mailto:adrian@xxxxxxxxxxxx] Sent: 16 February 2017 22:10 To: ietf@xxxxxxxx Cc: draft-ietf-pce-stateful-pce@xxxxxxxx; pce@xxxxxxxx; pce-chairs@xxxxxxxx Subject: RE: [Pce] Last Call: <draft-ietf-pce-stateful-pce-18.txt> (PCEP Extensions for Stateful PCE) to Proposed Standard IETF last call I have read and commented on this document during its production by the PCE working group. It constitutes a missing piece of the puzzle that we started with RFC 4655. The publication of this work as an RFC is long overdue to the point that implementers have become confused over the last couple of years about whether it would ever be published. However, on re-reading this final version, I notice a few points. Nothing major. Thanks for the work, Adrian --- The reference to [I-D.ietf-pce-stateful-pce-app] is for some terms that are fundamental to understanding this document. It needs to be a normative reference. Jon> ACK. Should be RFC 8051. --- 3.1.3 has... Note that existing configuration tools and protocols can be used to set LSP state. ...which is true, but is lacking references for the inquisitive mind. Just need some form of "(such as, ....)" Jon> "... , such as a Command Line Interface (CLI) tool." --- In the RBNF in section 6 there is some mismatch between hyphen and underscore. Not only is there a mixture of uses, but sometime the same construct is named in different ways (e.g., in 6.1 you have <actual_attribute_list> and <actual_attribute-list>) Jon> ACK, will tidy this up. --- In 6.2, would it help show consistency with 6.1 and remove potential confusion if <path>::= <intended_path><attribute-list> read <path>::= <intended_path><intended-attribute-list> Jon> ACK --- The use of TBD in the document to flag where IANA allocations need to be updated in the document is going to cause the RFC editor additional work and is error prone. What you should probably do is use TBD1, TBD2, etc. in the text and then include those flags in the IANA considerations sections. However (!) I note that early allocation has been done for most of the code points. So... - The IANA section should refer to this and ask IANA to confirm those allocations and update the registry to point to this document when it is an RFC - The actual numbers can be filled in in place of all the TBDs - It would help the reader/coder if you pointed forward to the new registries (for example, from 7.3.3 to 8.9) Jon> ACK although having me do it is equally error prone ;-) --- 7.3.2 Symbolic Path Name You need to give some clues! Is this supposed to be printable? Is this in a particular character set? Is it supposed to be null terminated (which would mean that if it was a multiple of 4 octets you'd need another four octets of pad) Jon> This was also raised by others - here is my proposed resolution. OLD Each LSP (path) MUST have a symbolic name that is unique in the PCC. This symbolic path name MUST remain constant throughout an LSP's lifetime, which may span across multiple consecutive PCEP sessions and/or PCC restarts. The symbolic path name MAY be specified by an operator in a PCC's configuration. If the operator does not specify a unique symbolic name for a path, the PCC MUST auto-generate one. The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the LSP State Report (PCRpt) message when during a given PCEP session an LSP is first reported to a PCE. A PCC sends to a PCE the first LSP State Report either during State Synchronization, or when a new LSP is configured at the PCC. The symbolic path name MAY be included in the LSP object in subsequent LSP State Reports for the LSP. <snip> Symbolic Path Name (variable): symbolic name for the LSP, unique in the PCC. NEW Each LSP MUST have a symbolic path name that is unique in the PCC. The symbolic path name is a human-readable string that identifies an LSP in the network. The symbolic path name MUST remain constant throughout an LSP's lifetime, which may span across multiple consecutive PCEP sessions and/or PCC restarts. The symbolic path name MAY be specified by an operator in a PCC's configuration. If the operator does not specify a unique symbolic name for an LSP, then the PCC MUST auto-generate one. The PCE uses the symbolic path name as a stable identifier for the LSP. If the PCEP session restarts, or the PCC restarts, or the PCC re-delegates the LSP to a different PCE, the symbolic path name for the LSP remains constant and can be used to correlate across the PCEP session instances. The other protocol identifiers for the LSP cannot reliably be used to identify the LSP across multiple PCEP sessions, for the following reasons. - The PLSP-ID is unique only within the scope of a single PCEP session. - The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs that are signalled with RSVP-TE. The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the LSP State Report (PCRpt) message when during a given PCEP session an LSP is first reported to a PCE. A PCC sends to a PCE the first LSP State Report either during State Synchronization, or when a new LSP is configured at the PCC. The initial PCRpt creates a binding between the symbolic path name and the PLSP-ID for the LSP which lasts for the duration of the PCEP session. The PCC MAY omit the symbolic path name from subsequent LSP State Reports for that LSP on that PCEP session, and just give the PLSP-ID. <snip> Symbolic Path Name (variable): symbolic name for the LSP, unique in the PCC. It SHOULD be a string of printable ASCII characters and SHOULD be NULL-terminated. The Symbolic Path Name (including its NULL terminator) MUST be padded to 4-bytes alignment; the padding itself MUST NOT be included in the Length field. END NEW --- 7.3.4 While 2205 is technically a good enough reference for the ERROR_SPEC object, I wonder if the reader will automatically be aware of the additional work on that object in 3471, 4201, and 4920. Jon> Did you mean 3473 instead of 3471? I don't think it's necessary to exhaustively list all RFCs that make use of ERROR_SPEC. None of these RFCs updates 2205. > -----Original Message----- > From: Pce [mailto:pce-bounces@xxxxxxxx] On Behalf Of The IESG > Sent: 14 February 2017 22:51 > To: IETF-Announce > Cc: draft-ietf-pce-stateful-pce@xxxxxxxx; pce@xxxxxxxx; > pce-chairs@xxxxxxxx > Subject: [Pce] Last Call: <draft-ietf-pce-stateful-pce-18.txt> (PCEP Extensions for > Stateful PCE) to Proposed Standard > > > The IESG has received a request from the Path Computation Element WG > (pce) to consider the following document: > - 'PCEP Extensions for Stateful PCE' > <draft-ietf-pce-stateful-pce-18.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2017-02-28. Exceptionally, comments may > be sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting.