[Pce] Comments on draft-ietf-pce-pcep-exp-codepoints

["Adrian Farrel" <[e-mail]>]

Hi,

Per the chairs' request today, I had another look at the experimental
codepoints draft, draft-ietf-pce-pcep-exp-codepoints-01/. Sorry to
entirely rewrite your draft ;-)

My meta point that I have raised before is that I think you are
assigning way too many experimental code points. I do not want to be
blocking on WG process on this point and will accept that I am in the
rough *if* the chairs believe that that is the case. The background to
my thought is BCP 82 that says:
   In many, if not most cases, reserving a single value for experimental
   use will suffice.  While it may be tempting to reserve more in order
   to make it easy to test many things at once, reserving many may also
   increase the temptation for someone using a particular value to
   assume that a specific experimental value can be used for a given
   purpose exclusively.
I agree that one code point is probably limiting, but I also think that
* 4 messages
* 8 objects
* 8 TLVs
would be at the high end of what is needed.

The other points are below.

Thanks,
Adrian

---
Metadata

I think you are changing an existing registry definition. This is 
different from making an allocation from a registry, so you are
updating the RFC that created the registry.  You need to add the
"Updates: RFC 5440" text.

---

Title

s/for/for the/

---

Abstract

s/IETF Consensus/IETF Review/

---

Abstract

OLD
   This document seeks to mark some codepoints for experimental usage of
   PCEP.
NEW
   This document updates RFC 5440 by changing the allocation policies 
   for these three registries to mark some of the code points as assigned
   for Experimental Use.
END                                              

---

Requirements Language

I don't think you need 2119 language in this document. See my comments 
on Section 5.

---

1.  Introduction

   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.

This is a somewhat old definition of PCEP that doesn't account for
delegation and PCE-initiated LSPs.

---

1.  Introduction

   In section 9 of [RFC5440], IANA assigns values to the PCEP protocol
   parameters (messages, objects, TLVs).  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 Consensus as
   described in [RFC8126].  Specifically, new assignments are made via
   RFCs approved by the IESG.  Typically, the IESG will seek input on
   prospective assignments from appropriate persons (e.g., a relevant
   Working Group if one exists).  Early allocation [RFC7120] provides
   some latitude for allocation of these code points, but is reserved
   for features that are considered appropriately stable.

I'm not sure you should seek to redefine "IETF Consensus". The citation
of 8126 should be enough and you can cut the paragraph there.

Anyway
s/IETF Consensus/IETF Review/

---

1.  Introduction

   With some recent advancement, there is an enhanced need to experiment
   with PCEP.  It is often necessary to use some sort of number or
   constant in order to actually test or experiment with the new
   function, even when testing in a closed environment.  In order to run
   experiment, it is important that the value won't collide not only
   with existing codepoints but any future allocation.

s/run experiment/run experiments/

---

1.  Introduction

OLD
   This document thus set apart some codepoints in PCEP registry and
   subregistries for experimental usage.
NEW
   This document updates [RFC5440] by changing the allocation policies 
   for these three registries to mark some of the code points as 
   assigned for Experimental Use.  See [RFC3692] for further discussion
   of the use of experimental codepoints.
END

---

2.  PCEP Messages

OLD
   Some codepoints are requested to be set aside for experimentation
   with new PCEP messages.  The suggested range is 246-255.
NEW
   PCEP message types are in the range 0 to 255.  This document sets
   aside message types 246-255 for experimentation as described in
   Section 6.1.
END

---

3.  PCEP Objects

OLD
   Some codepoints are requested to be set aside for experimentation
   with new PCEP objects.  The suggested range is 224-255.
NEW
   PCEP objects are identified by values in the range 0 to 255.  This
   document sets aside object identifiers 224-255 for experimentation as
   described in Section 6.2.
END

---

4.  PCEP TLVs

OLD
   Some codepoints are requested to be set aside for experimentation
   with new PCEP TLVs.  The suggested range is 65280-65535.
NEW
   PCEP TLV type codes are in the range 0 to 65535.  This document sets 
   aside object identifiers 65280-65535 for experimentation as described
   in Section 6.3.
END

---

OLD
5.  Handling of unknown experimentation
NEW
5.  Handling of Unknown Experimentation
END

---

5.  Handling of unknown experimentation

OLD
   A PCE that does not recognize an experimental PCEP object, MUST
   reject the entire PCEP message and MUST send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object", defined as
   per [RFC5440].
NEW
   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].
END

---

6.1.  New PCEP Messages

OLD
   Upon approval of this document, IANA is requested to make the
   following allocations:

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               | 246-255 | Unassigned  | Experimental Use  |
               +---------+-------------+-------------------+
NEW
   IANA is requested to change the registration procedure for this
   registry to read as follows:

   0-245   IETF Review
   246-255 Experimental Use

   IANA is also requested to mark the values 246-255 in the registry
   accordingly.
END

---

6.2.  New PCEP Objects

OLD
   Upon approval of this document, IANA is requested to make the
   following allocations:

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               | 224-255 | Unassigned  | Experimental Use  |
               +---------+-------------+-------------------+
NEW
   IANA is requested to change the registration procedure for this
   registry to read as follows:

   0-245   IETF Review
   224-255 Experimental Use

   IANA is also requested to mark the values 224-255 in the registry
   accordingly.
END

---

6.3.  New PCEP TLVs

OLD
   Upon approval of this document, IANA is requested to make the
   following allocations:

             +------------+-------------+-------------------+
             |      Type  | Description | Allocation Policy |
             +------------+-------------+-------------------+
             |65280-65535 | Unassigned  | Experimental Use  |
             +------------+-------------+-------------------+
NEW
   IANA is requested to change the registration procedure for this
   registry to read as follows:

   0-65279     IETF Review
   65280-65535 Experimental Use

   IANA is also requested to mark the values 65280-65535 in the registry
   accordingly.
END

---

DELETE
7.  Allocation Policy

   The allocation policy for the IANA request in Section 6 is
   "Experimental".  As per [RFC8126], IANA does not record specific
   assignments for any particular use for this policy.

   As the experiment/standard progress and an early IANA allocation or
   RFC publication happens, the IANA defined codepoints are used and
   experimental code points are freed up.
END

NOTE
   The meaning of the first paragraph is now achieved in Section 6.
   The second paragraph is ambiguous as experimental codepoints are
   not "freed up" in any sense that the IETF can be aware of.
END

---

8.  Security Considerations

ADD   
   [RFC3692] asserts that the existence of experimental code points 
   introduce no new security considerations.  However, implementations
   accepting experimental codepoints need to take care in how they parse
   and process the messages, objects, and TLVs in case they come,
   accidentally from another experiment.
END

---

10.1.  Normative References

DELETE
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.
END

---

10.2.  Informative References

Add RFC 3692

---

Appendix A.  Other Codepoints

Was this intended to be "Other PCEP Registries"?

---