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

[Dhruv Dhody <[e-mail]>]

Hi WG, 

After discussion, the conclusion is to keep the following "numbers of code points for experimental use" - 

* 4 messages (252-255)
* 8 objects  (248-255) 
* 32 tlvs    (65504-65535) 

These numbers are derived based on the past experience of running experiments. 

All the other comments from Adrian are accepted, and Adrian has joined as co-author. Thanks Adrian! 

I will post an update to the draft shortly. Please let us know if there are any further comments. 

Regards,
Dhruv

> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 18 July 2017 20:50
> To: [e-mail]
> Subject: [Pce] Comments on draft-ietf-pce-pcep-exp-codepoints
> 
> 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"?
> 
> ---
> 
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce