IETF Logo Mail Archive

Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)

Christian Hopps <chopps@chopps.org> Tue, 08 October 2019 10:13 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D58120227; Tue, 8 Oct 2019 03:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 D4nWEApYvcGq; Tue, 8 Oct 2019 03:13:27 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 565A61200B8; Tue, 8 Oct 2019 03:13:27 -0700 (PDT)
Received: from stubbs.int.chopps.org (unknown [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 59A176016F; Tue, 8 Oct 2019 06:13:26 -0400 (EDT)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <6C1E5E4D-5681-4C9A-AD7B-72FB65A4F59B@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_176EEA1B-767D-4A81-BEEF-48A9C70EA839"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 08 Oct 2019 06:13:23 -0400
In-Reply-To: <1685E504-3537-4A88-8E79-74601F717BA0@chopps.org>
Cc: Christian Hopps <chopps@chopps.org>, Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-isis-yang-isis-cfg@ietf.org" <draft-ietf-isis-yang-isis-cfg@ietf.org>, Yingzhen Qu <yingzhen.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
References: <157005547716.8852.9437110159615855482.idtracker@ietfa.amsl.com> <D52B6B66-3601-4E35-805F-164635009754@cisco.com> <1685E504-3537-4A88-8E79-74601F717BA0@chopps.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/RtjIILzd7DGcZdbtNKR3krGmudo>
Subject: Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2019 10:13:29 -0000

should have read "or it supports more than 32"

> On Oct 8, 2019, at 5:53 AM, Christian Hopps <chopps@chopps.org> wrote:
> 
> This strikes me as one of these artificial limits that gains us almost nothing (what if the platform supports less than 32 or it supports 32?), and creates these backward incompatible YANG issues (ranges that have to change) that are part of what is driving the complexity in the YANG versioning stuff. Why don't we just have a no range u16 or a 1..max range?
> Thanks,
> Chris.
> 
>> On Oct 7, 2019, at 12:44 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
>> 
>>>  grouping spf-parameters {
>>>    container spf-control {
>>>        leaf paths {
>>>          if-feature max-ecmp;
>>>          type uint16 {
>>>            range "1..32";
>>>          }
>> 
>>   Why is this a uint16 rather than a uint8?
>> 
>> It definitely could be uint8.
>

v2.23.0 | Report a Bug | By Email