Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Jonathan Hardwick]

I'm OK with downgrading the "must" to a "may" (in lowercase).
Cheers
Jon



From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: 19 November 2017 14:43
To: 'Julien Meuric' <julien.meu...@orange.com>; 'Dhruv Dhody' 
<dhruv.dh...@huawei.com>; Jonathan Hardwick <jonathan.hardw...@metaswitch.com>
Cc: draft-ietf-pce-pcep-exp-codepoi...@ietf.org; pce@ietf.org
Subject: RE: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

That works for me, although I would probably lower-case the "MAY".

A

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: 17 November 2017 17:30
To: Dhruv Dhody; Jonathan Hardwick
Cc: 
draft-ietf-pce-pcep-exp-codepoi...@ietf.org<mailto:draft-ietf-pce-pcep-exp-codepoi...@ietf.org>;
 pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

Hi,

IMHO, the correct wording lies in between. RFC 5440 set the default for PCEP 
("A PCEP-ERROR object is used to report a PCEP error"). Further specification 
(e.g. RFC 8231) MAY add message-specific behavior, but I think it is wrong to 
mandate a new behavior for each new message. I would thus suggest :
   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440]. Otherwise, the object is
   ignored. Message-specific behavior MAY be specified (e.g., [RFC8231]
   defines rules for a PCC to handle an unknown object in an Update
   (PCUpd) message).

My 2 cents,

Julien

Nov. 13, 2017 - dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>:



Section 5

The following paragraph does not tell the whole story.

   A PCE that does not recognize an experimental PCEP object, will
   reject the entire PCEP message and send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object" as described
   in [RFC5440].

If the P flag is clear in the object header, then the PCE MAY ignore the object 
instead of generating this error message. Also, you do not discuss what a PCC 
would do on receipt of a PCUdp or PCInitiate containing an unrecognised 
experimental object - it is inconsistent that you don't cover these cases.  
(FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. 
Section 6.2 says that a PCErr should be sent, but then it refers to section 
7.3.3, which says that a PCRpt should be sent. Hmmm.)

[[[Dhruv Dhody]]] Yes. How about I update to this -

   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440].  Otherwise the object is
   ignored.  In case of stateful PCE messages [RFC8231], the P flag is
   ignored and the unknown object handling is as per the stateful PCE
   extensions.

And let's try to handle the inconsistency in RFC 8231 with an errata perhaps? 
And handle PCE-initiated during AUTH48?

[Jon] I think this is OK, but if we are just going to point the reader at 
RFC8231, then we might as well do the same with RFC5440, rather than duplicate 
its text.  And we should write something that allows for the possibility that 
more message types may be relevant in future.  How about

   If a PCEP speaker does not understand or support an experimental object
   then the way it handles this situation depends on the message type.
   For example, a PCE handles an unknown object in the Path Computation Request
   (PCReq) message according to the rules of [RFC5440].  A PCC handles an
   unknown object in an Update (PCUpd) message according to the rules of 
[RFC8231]
   and, in an LSP Initiate Request (PCInitiate) message, according to the rules 
of
   [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PCEP message
   type must specify how to handle unknown objects on that message.

Note that this last sentence is not an RFC2119 MUST because it defines author 
behaviour, not device behaviour.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Adrian Farrel]

That works for me, although I would probably lower-case the "MAY".
 
A
 
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: 17 November 2017 17:30
To: Dhruv Dhody; Jonathan Hardwick
Cc: draft-ietf-pce-pcep-exp-codepoi...@ietf.org; pce@ietf.org
Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints
 
Hi,

IMHO, the correct wording lies in between. RFC 5440 set the default for PCEP ("A
PCEP-ERROR object is used to report a PCEP error"). Further specification (e.g.
RFC 8231) MAY add message-specific behavior, but I think it is wrong to mandate
a new behavior for each new message. I would thus suggest :
   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440]. Otherwise, the object is
   ignored. Message-specific behavior MAY be specified (e.g., [RFC8231]
   defines rules for a PCC to handle an unknown object in an Update
   (PCUpd) message).

My 2 cents,

Julien


Nov. 13, 2017 - dhruv.dh...@huawei.com:



 
Section 5
 
The following paragraph does not tell the whole story.
 
   A PCE that does not recognize an experimental PCEP object, will
   reject the entire PCEP message and send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object" as described
   in [RFC5440].
 
If the P flag is clear in the object header, then the PCE MAY ignore the object
instead of generating this error message. Also, you do not discuss what a PCC
would do on receipt of a PCUdp or PCInitiate containing an unrecognised
experimental object - it is inconsistent that you don't cover these cases.
(FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd.
Section 6.2 says that a PCErr should be sent, but then it refers to section
7.3.3, which says that a PCRpt should be sent. Hmmm.)
 
[[[Dhruv Dhody]]] Yes. How about I update to this - 
 
   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440].  Otherwise the object is
   ignored.  In case of stateful PCE messages [RFC8231], the P flag is
   ignored and the unknown object handling is as per the stateful PCE
   extensions.
 
And let's try to handle the inconsistency in RFC 8231 with an errata perhaps?
And handle PCE-initiated during AUTH48? 
 
[Jon] I think this is OK, but if we are just going to point the reader at
RFC8231, then we might as well do the same with RFC5440, rather than duplicate
its text.  And we should write something that allows for the possibility that
more message types may be relevant in future.  How about
 
   If a PCEP speaker does not understand or support an experimental object
   then the way it handles this situation depends on the message type.
   For example, a PCE handles an unknown object in the Path Computation Request
   (PCReq) message according to the rules of [RFC5440].  A PCC handles an
   unknown object in an Update (PCUpd) message according to the rules of
[RFC8231]
   and, in an LSP Initiate Request (PCInitiate) message, according to the rules
of
   [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PCEP message
   type must specify how to handle unknown objects on that message.
 
Note that this last sentence is not an RFC2119 MUST because it defines author
behaviour, not device behaviour.
 
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Julien Meuric]

  
  
Hi,

IMHO, the correct wording lies in between. RFC 5440 set the default
for PCEP ("A PCEP-ERROR object is used to report a PCEP error").
Further specification (e.g. RFC 8231) MAY add message-specific
behavior, but I think it is wrong to mandate a new behavior for each
new message. I would thus suggest :

   If the PCE does not understand or support an
experimental object with
   the P flag set in the Object Header, in the Path
Computation Request
   message (PCReq), the entire PCEP message is
rejected and PCE responds
   with a PCErr message with Error-Type="Unknown
Object" or "Not
   supported object" as described in [RFC5440].
Otherwise, the object is
   ignored. Message-specific behavior MAY be
specified (e.g., [RFC8231]
   defines rules for a PCC to handle an unknown object in an Update
   (PCUpd) message).



My 2 cents,

Julien


Nov. 13, 2017 - dhruv.dh...@huawei.com:


  
  
   


  

  
 
Section 5
 
The following
paragraph does not tell the whole story.
 
   A
PCE that does not recognize an experimental PCEP object,
will
  
reject the entire PCEP message and send a PCE error
message with
  
Error- Type="Unknown Object" or "Not supported object"
as described
   in
[RFC5440].
 
If the P flag is
clear in the object header, then the PCE MAY ignore the
object instead of generating this error message. Also,
you do not discuss what a PCC would do on receipt of a
PCUdp or PCInitiate containing an unrecognised
experimental object – it is inconsistent that you don’t
cover these cases.  (FWIW, RFC 8231 is a bit ambiguous
about what a PCC should do about the PCUpd. Section 6.2
says that a PCErr should be sent, but then it refers to
section 7.3.3, which says that a PCRpt should be sent.
Hmmm.)
 
[[[Dhruv Dhody]]] Yes. How about I update
to this – 
 
   If the PCE does
not understand or support an experimental object with
   the P flag set
in the Object Header, in the Path Computation Request
   message
(PCReq), the entire PCEP message is rejected and PCE
responds
   with a PCErr
message with Error-Type="Unknown Object" or "Not
   supported
object" as described in [RFC5440].  Otherwise the object
is
   ignored.  In
case of stateful PCE messages [RFC8231], the P flag is
   ignored and the
unknown object handling is as per the stateful PCE
   extensions.
 
And let’s try to handle the inconsistency
in RFC 8231 with an errata perhaps? And handle
PCE-initiated during AUTH48? 
 
[Jon] I think this is OK, but if we are
just going to point the reader at RFC8231, then we might
as well do the same with RFC5440, rather than duplicate
its text.  And we should write something that allows for
the possibility that more message types may be relevant
in future.  How about
 
   If a PCEP
speaker does not understand or support an experimental
object
   then the way it
handles this situation depends on the message type.
   For example, a
PCE handles an unknown object in the Path Computation
Request
   (PCReq) message
according to the rules of [RFC5440].  A PCC handles an
   unknown object
in an Update (PCUpd) message according to the rules of
[RFC8231]
   and, in an LSP
Initiate Request (PCInitiate) message, according to the
rules of
 
 [I-D.ietf-pce-pce-initiated-lsp].  Any document that
adds a new PCEP message
   type must
specify how to handle unknown objects on that message.
 
Note that this last sentence is not an
RFC2119 MUST because it defines author behaviour, not
device behaviour.
  

  


  


___
Pce mailing list

Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Dhruv Dhody]

Hi Jon,

Thanks for the suggested texts, I have made the update -

https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-exp-codepoints-03

Thanks!
Dhruv

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 13 November 2017 08:08
To: Dhruv Dhody <dhruv.dh...@huawei.com>; 
draft-ietf-pce-pcep-exp-codepoi...@ietf.org
Cc: pce@ietf.org; pce-cha...@ietf.org; 'Dhruv Dhody' <dhruv.i...@gmail.com>
Subject: RE: Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

Hi Dhruv

Thanks for this.  Trimming to the open points:

Introduction

The second paragraph is superfluous - I suggest deleting:

   Further, in order to support use cases described in [RFC8051],

   [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to

   enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and

   teardown of PCE-initiated LSPs under the stateful PCE model.

[[[Dhruv Dhody]]] Because of the comment for handling the unknown experimental 
objects for the stateful PCE messages, I think it is better to continue to keep 
this text. What do you think?

[Jon] Right - OK to leave it.  But then I think these have to become normative 
references.

Section 5

The following paragraph does not tell the whole story.

   A PCE that does not recognize an experimental PCEP object, will
   reject the entire PCEP message and send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object" as described
   in [RFC5440].

If the P flag is clear in the object header, then the PCE MAY ignore the object 
instead of generating this error message. Also, you do not discuss what a PCC 
would do on receipt of a PCUdp or PCInitiate containing an unrecognised 
experimental object - it is inconsistent that you don't cover these cases.  
(FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. 
Section 6.2 says that a PCErr should be sent, but then it refers to section 
7.3.3, which says that a PCRpt should be sent. Hmmm.)

[[[Dhruv Dhody]]] Yes. How about I update to this -

   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440].  Otherwise the object is
   ignored.  In case of stateful PCE messages [RFC8231], the P flag is
   ignored and the unknown object handling is as per the stateful PCE
   extensions.

And let's try to handle the inconsistency in RFC 8231 with an errata perhaps? 
And handle PCE-initiated during AUTH48?

[Jon] I think this is OK, but if we are just going to point the reader at 
RFC8231, then we might as well do the same with RFC5440, rather than duplicate 
its text.  And we should write something that allows for the possibility that 
more message types may be relevant in future.  How about

   If a PCEP speaker does not understand or support an experimental object
   then the way it handles this situation depends on the message type.
   For example, a PCE handles an unknown object in the Path Computation Request
   (PCReq) message according to the rules of [RFC5440].  A PCC handles an
   unknown object in an Update (PCUpd) message according to the rules of 
[RFC8231]
   and, in an LSP Initiate Request (PCInitiate) message, according to the rules 
of
   [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PCEP message
   type must specify how to handle unknown objects on that message.

Note that this last sentence is not an RFC2119 MUST because it defines author 
behaviour, not device behaviour.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Jonathan Hardwick]

Hi Dhruv

Thanks for this.  Trimming to the open points:

Introduction

The second paragraph is superfluous - I suggest deleting:

   Further, in order to support use cases described in [RFC8051],

   [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to

   enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and

   teardown of PCE-initiated LSPs under the stateful PCE model.

[[[Dhruv Dhody]]] Because of the comment for handling the unknown experimental 
objects for the stateful PCE messages, I think it is better to continue to keep 
this text. What do you think?

[Jon] Right - OK to leave it.  But then I think these have to become normative 
references.

Section 5

The following paragraph does not tell the whole story.

   A PCE that does not recognize an experimental PCEP object, will
   reject the entire PCEP message and send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object" as described
   in [RFC5440].

If the P flag is clear in the object header, then the PCE MAY ignore the object 
instead of generating this error message. Also, you do not discuss what a PCC 
would do on receipt of a PCUdp or PCInitiate containing an unrecognised 
experimental object - it is inconsistent that you don't cover these cases.  
(FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. 
Section 6.2 says that a PCErr should be sent, but then it refers to section 
7.3.3, which says that a PCRpt should be sent. Hmmm.)

[[[Dhruv Dhody]]] Yes. How about I update to this -

   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440].  Otherwise the object is
   ignored.  In case of stateful PCE messages [RFC8231], the P flag is
   ignored and the unknown object handling is as per the stateful PCE
   extensions.

And let's try to handle the inconsistency in RFC 8231 with an errata perhaps? 
And handle PCE-initiated during AUTH48?

[Jon] I think this is OK, but if we are just going to point the reader at 
RFC8231, then we might as well do the same with RFC5440, rather than duplicate 
its text.  And we should write something that allows for the possibility that 
more message types may be relevant in future.  How about

   If a PCEP speaker does not understand or support an experimental object
   then the way it handles this situation depends on the message type.
   For example, a PCE handles an unknown object in the Path Computation Request
   (PCReq) message according to the rules of [RFC5440].  A PCC handles an
   unknown object in an Update (PCUpd) message according to the rules of 
[RFC8231]
   and, in an LSP Initiate Request (PCInitiate) message, according to the rules 
of
   [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PCEP message
   type must specify how to handle unknown objects on that message.

Note that this last sentence is not an RFC2119 MUST because it defines author 
behaviour, not device behaviour.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Dhruv Dhody]

Hi Jon,

Thanks for your review. See inline...

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 12 November 2017 12:04
To: draft-ietf-pce-pcep-exp-codepoi...@ietf.org
Cc: pce@ietf.org; pce-cha...@ietf.org
Subject: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

Re-sending to the correct DL :)

From: Jonathan Hardwick
Sent: 12 November 2017 12:02
To: 'draft-ietf-pce-exp-codepoi...@ietf.org' 
<draft-ietf-pce-exp-codepoi...@ietf.org<mailto:draft-ietf-pce-exp-codepoi...@ietf.org>>
Cc: 'pce@ietf.org' <pce@ietf.org<mailto:pce@ietf.org>>; 
pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
Subject: Shepherd's review of draft-ietf-pce-exp-codepoints

Hi there

I am the document shepherd for this draft.  Please find my review of the draft 
below.

Many thanks for writing this draft.  It looks in good shape overall.  There are 
just a few clarifications I would like to make before we forward it to the IESG 
for publication.

Cheers
Jon

Abstract

This sentence about new sub-registries is misleading - the allocation policy 
for new sub-registries is decided by the drafts that create the sub-registries 
and does not have to be IETF Review.  I propose:
OLD

   IANA established a new top-level registry to contain all PCEP

   codepoints and sub-registries.  The allocation policy for each new

   registry is by IETF Review.
NEW

   IANA established a top-level registry to contain all PCEP

   codepoints and sub-registries.   This top-level registry contains

   sub-registries for PCEP message, object and TLV types.  The

   allocation policy for each of these sub-registries is IETF Review.
END

[[[Dhruv Dhody]]] Ack.

Introduction

OLD

   The Path Computation Element communication Protocol (PCEP) provides

   mechanisms for Path Computation Elements (PCEs) to perform path

   computations in response to Path Computation Clients (PCCs) requests.
NEW

   The Path Computation Element communication Protocol (PCEP) [RFC5440] provides

   mechanisms for Path Computation Elements (PCEs) to perform path

   computations in response to Path Computation Clients (PCCs) requests.
END
i.e. add reference to RFC 5440.

[[[Dhruv Dhody]]] Ack.

The second paragraph is superfluous - I suggest deleting:

   Further, in order to support use cases described in [RFC8051],

   [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to

   enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and

   teardown of PCE-initiated LSPs under the stateful PCE model.

[[[Dhruv Dhody]]] Because of the comment for handling the unknown experimental 
objects for the stateful PCE messages, I think it is better to continue to keep 
this text. What do you think?

Please apply the same comments I made for the abstract to the following text:
OLD

   IANA established a new top-

   level registry to contain all PCEP codepoints and sub-registries.

   The allocation policy for each new registry is by IETF Review as

   described in [RFC8126].
NEW

   IANA established a top-

   level registry to contain all PCEP codepoints and sub-registries.

   This top-level registry contains sub-registries for PCEP message,

   object and TLV types.  The allocation policy for each of these

   sub-registries is IETF Review.
END

[[[Dhruv Dhody]]] Ack.

Suggested change for clarity:
OLD

   With some recent advancement, there is an enhanced need to experiment

   with PCEP.
NEW

   Recently, there have been rapid advancements in PCE technology, which

   has created an enhanced need to experiment with PCEP.
END

[[[Dhruv Dhody]]] Ack.

Section 5

The following paragraph does not tell the whole story.

   A PCE that does not recognize an experimental PCEP object, will
   reject the entire PCEP message and send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object" as described
   in [RFC5440].

If the P flag is clear in the object header, then the PCE MAY ignore the object 
instead of generating this error message. Also, you do not discuss what a PCC 
would do on receipt of a PCUdp or PCInitiate containing an unrecognised 
experimental object - it is inconsistent that you don't cover these cases.  
(FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. 
Section 6.2 says that a PCErr should be sent, but then it refers to section 
7.3.3, which says that a PCRpt should be sent. Hmmm.)

[[[Dhruv Dhody]]] Yes. How about I update to this -

   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440].  Otherwise the object is
   ignored.  In case of stateful PCE messag

[Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Jonathan Hardwick]

Re-sending to the correct DL :)

From: Jonathan Hardwick
Sent: 12 November 2017 12:02
To: 'draft-ietf-pce-exp-codepoi...@ietf.org' 

Cc: 'pce@ietf.org' ; pce-cha...@ietf.org
Subject: Shepherd's review of draft-ietf-pce-exp-codepoints

Hi there

I am the document shepherd for this draft.  Please find my review of the draft 
below.

Many thanks for writing this draft.  It looks in good shape overall.  There are 
just a few clarifications I would like to make before we forward it to the IESG 
for publication.

Cheers
Jon

Abstract

This sentence about new sub-registries is misleading - the allocation policy 
for new sub-registries is decided by the drafts that create the sub-registries 
and does not have to be IETF Review.  I propose:
OLD

   IANA established a new top-level registry to contain all PCEP

   codepoints and sub-registries.  The allocation policy for each new

   registry is by IETF Review.
NEW

   IANA established a top-level registry to contain all PCEP

   codepoints and sub-registries.   This top-level registry contains

   sub-registries for PCEP message, object and TLV types.  The

   allocation policy for each of these sub-registries is IETF Review.
END

Introduction

OLD

   The Path Computation Element communication Protocol (PCEP) provides

   mechanisms for Path Computation Elements (PCEs) to perform path

   computations in response to Path Computation Clients (PCCs) requests.
NEW

   The Path Computation Element communication Protocol (PCEP) [RFC5440] provides

   mechanisms for Path Computation Elements (PCEs) to perform path

   computations in response to Path Computation Clients (PCCs) requests.
END
i.e. add reference to RFC 5440.

The second paragraph is superfluous - I suggest deleting:

   Further, in order to support use cases described in [RFC8051],

   [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to

   enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and

   teardown of PCE-initiated LSPs under the stateful PCE model.

Please apply the same comments I made for the abstract to the following text:
OLD

   IANA established a new top-

   level registry to contain all PCEP codepoints and sub-registries.

   The allocation policy for each new registry is by IETF Review as

   described in [RFC8126].
NEW

   IANA established a top-

   level registry to contain all PCEP codepoints and sub-registries.

   This top-level registry contains sub-registries for PCEP message,

   object and TLV types.  The allocation policy for each of these

   sub-registries is IETF Review.
END

Suggested change for clarity:
OLD

   With some recent advancement, there is an enhanced need to experiment

   with PCEP.
NEW

   Recently, there have been rapid advancements in PCE technology, which

   has created an enhanced need to experiment with PCEP.
END

Section 5

The following paragraph does not tell the whole story.

   A PCE that does not recognize an experimental PCEP object, will
   reject the entire PCEP message and send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object" as described
   in [RFC5440].

If the P flag is clear in the object header, then the PCE MAY ignore the object 
instead of generating this error message. Also, you do not discuss what a PCC 
would do on receipt of a PCUdp or PCInitiate containing an unrecognised 
experimental object - it is inconsistent that you don't cover these cases.  
(FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. 
Section 6.2 says that a PCErr should be sent, but then it refers to section 
7.3.3, which says that a PCRpt should be sent. Hmmm.)

Also: s/PCE error message/PCErr message/

Section 7
Nit: add comma after "accidentally"

Appendix A
I think the text in this Appendix could be clearer.  Here is my suggestion.
OLD

   Based on the feedback from the WG, it was decided to focus only on

   the essentials in the scope of this documents.  For others,

   Experiments can use a new experimental TLV/Object instead.
NEW

   Based on feedback from the PCE WG, it was decided to allocate an

   Experimental code point range only in the message, object and TLV

   sub-registries.  The justification for this decision is that, if

   an experiment finds that it wants to use a new code point in

   another PCEP sub-registry, it can implement the same function using

   a new experimental object or TLV instead.
END

Other
Please update reference draft-ietf-pce-stateful-pce -> RFC 8231
Please update reference draft-ietf-pce-pce-initiated-lsp-10 -> 
draft-ietf-pce-pce-initiated-lsp-11

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce