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:[email protected]] On Behalf Of Adrian Farrel > Sent: 18 July 2017 20:50 > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
