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
