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.
---
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, ....)"
---
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>)
---
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>
---
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)
---
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)
---
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.
> -----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.