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

Alvaro Retana <aretana.ietf@gmail.com> Wed, 07 March 2018 22:07 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AF412D86D; Wed, 7 Mar 2018 14:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hPp-vXEEWmP; Wed, 7 Mar 2018 14:07:02 -0800 (PST)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AE012D7EF; Wed, 7 Mar 2018 14:07:02 -0800 (PST)
Received: by mail-ot0-x22a.google.com with SMTP id h8so3569141oti.6; Wed, 07 Mar 2018 14:07:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=wr3+ljLzNzhKv9NahlA18fDBsmu+cOGxiY/jArOMbI8=; b=OlQPofTuZzY8BE+vXp0FyEbbrHKqhiSNfhwu8G5y2Ah7huA0cOrDjoSexf5IiFg4tM jjL/VI1FtbSd/8DbGqsVq3fYRhGJKnn1muWDTnZhH3h+Fdip3si1JLbn0l99fZnka/uA 1JmoXQ04Z/b42Ou3FucFyVK5mgqD8Uv4reeD4YKEpKyMExExKiFXTerVYcdrTtSfDJOA 1R1ADmSekwTrktFMXzjfF2WlgK32ITmsabBVfkjJKms/SzxElZ+c5Rvc6mUXV3T0UMKI IQxFRx3wxQuNi8wx/puPwXFwznG/HWZQtDqts5GZwKSpT5W8abofjXwV8CtOKm0HjmhL DC1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=wr3+ljLzNzhKv9NahlA18fDBsmu+cOGxiY/jArOMbI8=; b=uFkT48cTujMp4DJK5OuSmoKhwoBW/iRAP9J4CoTjyvQFtcTXuSaFzyCGX+6zZ8BXEg r8BJTUltCZsFU4l1BO4apAHQbJ/rsXEkPQ6L8hDcSZ0Hk8U8xhv+ubl8PZ0SQWM5OwFC tDfb4geROM5zPlXtcXPvkDaA9Cri8Xvtjfegzsmt32P11k2ApZm31WwyFktIxRjjbYgc JozkzVAzftndszSZPsoEHiyUzVB5iGKbBSjlLbB0SMNM0fdZiIaLUQbFEa4O5yvDgB3w YjMI9R8xvXdstR2hv4swzWh93uKOtA/R7x0a4jC89rnxAwPS9EIf9JebM6Xcg8xdg4fP aFtA==
X-Gm-Message-State: AElRT7EDDFNKdlU6VpTwc/MLFk06tCeHadSE3YRFWvQOUHzuerNIw0ra 5vYeRHfEhahVctpjQyaw1UR8jQv2yovnWNKR7K4=
X-Google-Smtp-Source: AG47ELvvNcMRnsKDgNxMNvRRYq82QB2ezYKKKxRIua7TP61zxXvBAtuJMqq+oUjD6dxPexDnyL6YxDDNlFfR9a5WTJw=
X-Received: by 10.157.97.130 with SMTP id g2mr17185735otk.82.1520460421344; Wed, 07 Mar 2018 14:07:01 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Mar 2018 14:07:00 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CA+YzgTtf-Kca766ttgCEnGhRUNVHiToGivZbnwLvKH0GicTo4g@mail.gmail.com>
References: <152037120319.28250.13326911149440960090.idtracker@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D463A57F2A@sjceml521-mbs.china.huawei.com> <CA+YzgTtf-Kca766ttgCEnGhRUNVHiToGivZbnwLvKH0GicTo4g@mail.gmail.com>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Wed, 07 Mar 2018 14:07:00 -0800
Message-ID: <CAMMESsy85F0J68MbtsjKDGbVvZZ35+hv7XjOGzzMvCr8fbsZOQ@mail.gmail.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>, Huaimo Chen <huaimo.chen@huawei.com>
Cc: "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>, Vishnu Beeram <vbeeram@juniper.net>, The IESG <iesg@ietf.org>, "draft-ietf-teas-rsvp-ingress-protection@ietf.org" <draft-ietf-teas-rsvp-ingress-protection@ietf.org>
Content-Type: multipart/alternative; boundary="f4f5e80c89f04f377c0566d9c783"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/YwSXsqXJFsJJ2R3Ks1B_KdIzbEA>
Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-ingress-protection-16: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2018 22:07:04 -0000

On March 7, 2018 at 3:48:03 PM, Vishnu Pavan Beeram (vishnupavan@gmail.com)
wrote:

Pavan:

Hi!

...


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

**

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.