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

[Huaimo Chen <[e-mail]>]

Hi Pavan,

Thank you very much for your email and suggestions.
After the discussions among the TEAS chairs, routing ADs, IANA and authors, the section “IANA Considerations” should be in a good shape. We will submit the updated document after submissions are unlocked.

Best Regards,
Huaimo
From: Vishnu Pavan Beeram [mailto:[e-mail]]
Sent: Wednesday, March 07, 2018 3:48 PM
To: Huaimo Chen <[e-mail]>
Cc: Alvaro Retana <[e-mail]>; The IESG <[e-mail]>; [e-mail]; Vishnu Beeram <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Alvaro Retana's No Objection on draft-ietf-teas-rsvp-ingress-protection-16: (with COMMENT)

Alvaro, Hi!
Please see inline (prefixed VPB).
Regards,
-Pavan

On Wed, Mar 7, 2018 at 10:52 AM, Huaimo Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alvaro,

    Thank you very much for your comments.
    Answers to them are inline below with prefix [HC].

Best Regards,
Huaimo
-----Original Message-----
From: Alvaro Retana [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, March 06, 2018 4:20 PM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Vishnu Beeram <[e-mail]<mailto:[e-mail]>>; Vishnu Beeram <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Alvaro Retana's No Objection on draft-ietf-teas-rsvp-ingress-protection-16: (with COMMENT)

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.
[HC] We will add some text about the expectations accordingly.


(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.

[VPB] RFC3936 does specify three "Expert Review" ranges for Class Numbers which can be used for experimental use. However, upon reviewing this document, the experts (teas-chairs, in this case) decided that a value from the "Private Use" range is more apt for this experiment. There are three "Private Use" ranges specified in RFC3936 -- the compatibility rules associated with the object (RFC2205, Section 3.10) determine which specific range to use. As per the compatibility aspects specified in Section 7 of this document, a value from the range 124-127 should get used.
Please see if the following text addresses your concerns with regards to the IANA section.
**
This document does not request any IANA actions.

This document defines one new object to indicate ingress protection.
-  INGRESS_PROTECTION

The assignment of a new Class Name and corresponding 8-bit Class
Number for an object in an RSVP message is defined in [RFC3936] with
ranges for Standards Action, Expert Review, and Private Use. Values
chosen from the Private Use range are not registered with IANA.
Since, the Class Number for this object must be of the form 0bbbbbbb
(refer to Section 7 on compatibility aspects), it is suggested that a value
from the Private range [RFC3936] for this form (124-127) be chosen
for experimentation.

**

[HC] We will update the IANA Considerations section according to your suggestion and it will contains only one sentence below:
This document does not request any IANA actions.

A new section "Class Number for Experiments" will use the text you suggested.