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 09:53 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 93496120144; Tue, 8 Oct 2019 02:53:10 -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 T8xBfE6BcjAS; Tue, 8 Oct 2019 02:53:09 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5821012006B; Tue, 8 Oct 2019 02:53:09 -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 53DDE6016F; Tue, 8 Oct 2019 05:53:08 -0400 (EDT)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <1685E504-3537-4A88-8E79-74601F717BA0@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_F2531B70-2F2F-4400-9298-B9C22C5A37EB"; 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 05:53:07 -0400
In-Reply-To: <D52B6B66-3601-4E35-805F-164635009754@cisco.com>
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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/mHceasihN0Wnb-dGUyO4d8zZOAI>
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 09:53:11 -0000

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