[Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-ingress-protection-16: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-teas-rsvp-ingress-protection-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) As written, the expected result of the experiment is to select one
approach.  Clearly, the intent is for the mechanisms to be compared.  That's
good!  But what will the criteria be?  Are there benchmarks related to (for
example) packet loss or state...?  Maybe it is simply an experiment to figure
out which approach is implemented and deployed.  In any case, it would be nice
to add some text about the expectations.

(2) The IANA Considerations Section still needs some work.  I know that the
authors have been in conversations with IANA (IESG was cc'd) and that the
result is to add the "This document does not request any IANA actions" text.

However, to avoid confusion it would be better if the IANA Considerations
section only contained that text, and a new Section (maybe "Class Name and
Number") was added to include the current text.

(2.1) About the current text...  I find the text about the Class Number a
little confusing as in the end it doesn't matter which Private Use range is
used; and the use of Normative Language...  Suggestion:

OLD>
   The assignment of a new Class Name and corresponding 8-bit Class
   Number data object in an RSVP message is defined in ([RFC3936]) with
   ranges for Standards Action, Expert Review, and Reserved for Private
   Use. The Private Use ranges can be used for experimental use, they
   will not be registered with IANA and MUST NOT be mentioned by RFCs.

   It is suggested to use the following Private Use range:

     o  124-127 Reserved for Private Use

   It is for an experimental implementation to choose a value from the
   Private Use range, and to agree with cooperating implementations
   participating in the same experiments what values to use.

NEW>
   The IANA Registry for Class Numbers created by [rfc3936] didn't define a
   range to be used for Experimental Use [rfc8126]; instead several Private Use
   ranges exist.  It is suggested that a value from a Private Use range
   (124-127 for example) be chosen for experimentation.