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

From: Alvaro Retana <[email-masked]>
Date: Tue, 06 Mar 2018 13:20:03 -0800

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.

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 7 Mar 2018 15:52:49 +0000

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:[email-masked]] 
Sent: Tuesday, March 06, 2018 4:20 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Vishnu Beeram <[email-masked]>; Vishnu Beeram <[email-masked]>; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-teas-rsvp-ingress-protection-16: (with COMMENT)

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

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

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 7 Mar 2018 15:48:02 -0500

Alvaro, Hi!

Please see inline (prefixed VPB).

Regards,
-Pavan

On Wed, Mar 7, 2018 at 10:52 AM, Huaimo Chen <[email-masked]> wrote:

> Cc: [email-masked]; Vishnu Beeram <
> [email-masked]>; Vishnu Beeram <[email-masked]>;
> [email-masked]; [email-masked]
> 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.
>

[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:

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 7 Mar 2018 21:13:46 +0000

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:[email-masked]]
Sent: Wednesday, March 07, 2018 3:48 PM
To: Huaimo Chen <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; The IESG <[email-masked]>; [email-masked]; Vishnu Beeram <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Alvaro Retana's No Objection on draft-ietf-teas-rsvp-ingress-protection-16: (with COMMENT)

Alvaro, Hi!

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

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

OLD>

NEW>

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

**

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 7 Mar 2018 14:07:00 -0800

On March 7, 2018 at 3:48:03 PM, Vishnu Pavan Beeram ([email-masked])
wrote:

Pavan:

Hi!

...

**

Yes, I overlooked the 0bbbbbbb part in S7.

I don’t think the first part of your suggested text is needed (mentioning
the different registration procedures) because it may cause confusion.  The
rest is fine with me.

I still would like to see two separate sections.

Thanks!

Alvaro.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 8 Mar 2018 10:47:25 -0500

Alvaro, Hi!

Please see inline..

Regards,
-Pavan

> I still would like to see two separate sections.
[Pavan] I missed your comment on having separate sections. I'm in total
agreement with you on the suggested changes. The authors have been asked to
keep the IANA section simple (just one statement saying that no specific
IANA action is required) and make relevant consequent changes (listed
below) to the document.

**
(1). In Section 4.1, remove the following line at the top of Page 9:

  Class-Num = TBD      C-Type = 1 for INGRESS_PROTECTION_IP

--
(2). Insert a new Sub-Section under 4.1:

4.1.1.  Class Number and Class Type

The Class Number for this object MUST be of the form 0bbbbbbb to
enable implementations that do not recognize the object to reject the
entire message and return an "Unknown Object Class" error [RFC2205].
It is suggested that a Class Number value from the Private Use range
(124-127) [RFC3936] specified for the 0bbbbbbb octet be chosen
for this experiment.  It is also suggested that a Class Type value of 1
be used for this object in this experiment.

--

(3) Replace all occurrences of "sub object" with “subobject” in the document

--

(4). There is some weirdness surrounding how CTYPE and Subobject Type are
mentioned interchangeably in this document. We would need to fix all of
that. You need just one CTYPE and multiple Subobject types. Please make the
following change in the sub-section "Subobject: Backup Ingress IPv4 Address”

OLD:
The Type of the sub object is TBD1 (the exact number to be assigned by
IANA), and
   the body of the sub object is given below:

NEW:
The Type of the subobject is 1, and the body of the subobject is as given
below:

--

(5). Make the following change in the sub-section "Subobject: Backup
Ingress IPv6 Address”

OLD:
The Type of the sub object is TBD2, the body of the subobject is given
below:

NEW:
The Type of the subobject is 2, the body of the subobject is as given below:

--

(5). Make the following change in the sub-section "Subobject: Ingress IPv4
Address”

OLD:
The Type of the sub object is TBD3.

NEW:
The Type of the subobject is 3.

—

(6) Make the following change in the sub-section “Subobject: Ingress IPv6
Address”

OLD:
The Type of the sub object is TBD4.

NEW:
The Type of the subobject is 4.

—

(7). Make the following change in the sub-section “Subobject: Traffic
Descriptor”

OLD:
The Type of the sub object is TBD5, TBD6, TBD7 or TBD8 for Interface, IPv4
   Prefix, IPv6 Prefix or Application Identifier respectively.

NEW:
The subobject types for Interface, IPv4 Prefix, IPv6 Prefix and Application
Identifier are 5, 6, 7 and 8 respectively.

—

(8) Remove all other uses of (Type TBD) in the sub-section “Subject:
Traffic Descriptor”

—

(9) Make the following change in the sub-section “Subject: Label-Routes"

OLD:
The Type of the sub object is TBD9.

NEW:
The Type of the subobject is 9.

—

(10) Make the following change in the “Compatibility” Section:

OLD:
One new object is defined to indicate ingress protection with class numbers
in the form 0bbbbbbb.

NEW:
The new object defined to indicate ingress protection has a class number of
the form 0bbbbbbb.

—

(11) Make the following change to the IANA section (just one statement as
per Alvaro’s suggestion):

IANA Considerations

--