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

[Vishnu Pavan Beeram <[e-mail]>]

Alvaro, Hi!

Please see inline (prefixed VPB).

Regards,
-Pavan

On Wed, Mar 7, 2018 at 10:52 AM, Huaimo Chen <[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]]
> Sent: Tuesday, March 06, 2018 4:20 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Vishnu Beeram <
> [e-mail]>; Vishnu Beeram <[e-mail]>;
> [e-mail]; [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.
>
>