Re: [babel] [netmod] NULL value for uint16
Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 14 September 2021 19:31 UTC
Return-Path: <mjethanandani@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988043A2A5C; Tue, 14 Sep 2021 12:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 HGpKvXUPIyKJ; Tue, 14 Sep 2021 12:31:04 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 3E6663A2A35; Tue, 14 Sep 2021 12:31:04 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id w8so205564pgf.5; Tue, 14 Sep 2021 12:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2H9iVeYorso48oz1oRDG7DLZo1rgUqFS74sha0oGxxU=; b=QFbEHzrm9lBXApDHK/XimTm4JTUn676MZWw4DC3McrE8GrAjyVNpxHCSf4nr7QpEtF X76ntyZPYlguDgA0FSLUsihW9izGmVUFztxzeGbJQY1aN1XNeSv1o0sTrf2gNu97CozH vc3lQn/FnyVt66WynEFLfDYK8XYn5zfQEpV1wtBVQcsIekMFfBOwmssR2j6CgARrXLa0 m75wB7W8c/ktiKMUs8bHzCMS4S1RFi/i+hd/R5lTPRNTQUO9Xr7iaZtRbscSB4zbYTs/ LP6XNpKNHSLENjs0BJ4UeGndReZ3JC5Qf030N273F2AkzG8isPANtrA4sY3IslegjYE3 b5wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2H9iVeYorso48oz1oRDG7DLZo1rgUqFS74sha0oGxxU=; b=V9h7CxOZ5dhKCbedefoUgHrU86O7qpYi6qkJZqQeGYS+QmUjUTkmDeIqL5sqZ45OSH DaaJMs8Vo0BNrJW4D5373qKcpWXbtA3upE9Iem5LnrsYukHD2AhmgL4Xj+Zb0DzyS72V u3yvHkRikiphVc5ePbQ8DQsAhXndtlRUH7aIdXzH0suhH2jDcEuEINXSiOQV4xWfG33J uT/kTg42KX4enras2gTjRTzm7YT4wkhHfNvUA+MiWqZnNzyreHwSfoMUF7PCa7jg2JnI ARg2uTsSIL67KvA50/uLF7zdQrwavWIVHD9VIPqZ8LZtX85QQtlTSl/YfND2AyYHVwlJ adFQ==
X-Gm-Message-State: AOAM532zyhXpdQTDnvC+Q8F1q33SHziFJAXdd1As4NFLLwhdZyJNMof5 XgJp9Hciin/XSjIMqOjqcLg=
X-Google-Smtp-Source: ABdhPJzYOAYV9XNnTvxt4ZpeSCV5LB+EN9nB1Ey53Q5PYyNLo1fvQ3L/9oKBLE8qkn2/oqOrRz3kmg==
X-Received: by 2002:a63:e413:: with SMTP id a19mr16895596pgi.408.1631647862322; Tue, 14 Sep 2021 12:31:02 -0700 (PDT)
Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id e2sm11272886pfn.141.2021.09.14.12.31.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Sep 2021 12:31:01 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <3CCE870C-9D69-450F-A795-84B791DDAA8E@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_46357380-FC98-4E5C-89E1-7D50FDD1BB2F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Tue, 14 Sep 2021 12:31:00 -0700
In-Reply-To: <20210914.201758.1827806402442755510.id@4668.se>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Babel at IETF <babel@ietf.org>, "STARK, BARBARA H" <bs7652@att.com>, netmod@ietf.org
To: Martin Björklund <mbj+ietf@4668.se>
References: <DM6PR02MB692446F49506791E90B0D23EC3DA9@DM6PR02MB6924.namprd02.prod.outlook.com> <20210914171729.ph5q77zm46z3zvxi@anna.jacobs.jacobs-university.de> <5F6A0BF9-06F9-41E9-8B9A-701608875934@gmail.com> <20210914.201758.1827806402442755510.id@4668.se>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/rmjdXkvPftIQnusd_Geo5DIYVHk>
Subject: Re: [babel] [netmod] NULL value for uint16
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Sep 2021 19:31:21 -0000
Hi Martin, > On Sep 14, 2021, at 11:17 AM, Martin Björklund <mbj+ietf@4668.se> wrote: > > Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote: >> Hi Juergen, >> >>> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> wrote: >>> >>> On Tue, Sep 14, 2021 at 01:51:36PM +0000, STARK, BARBARA H wrote: >>> >>>> As I mentioned, BBF TR-181 uses int with range -1:65535 with -1 meaning NULL. So I certainly have no issue with that approach. The language in RFC9046 was intended to make sure this approach was allowed, since this is how it's done in TR-181. >>>> I guess I am a bit surprised to learn that YANG doesn't seem to have a preferred way to handle this. Unfortunately, given my considerable lack of YANG expertise, I can't recommend the "right" way to model this in YANG. I can only insist that the model be able to express a value in the range 0 to 2^16 and NULL value for these parameters. >>>> Independent of the fact that the words in RFC9046 don't seem to have expressed this perfectly clearly, that is absolutely the intent of those words. I apologize that the RFC9046 words don't seem to be sufficiently clear. >>>> >>>> Since you do mention the possibility of using -1 for NULL, I'd like to understand who might find this approach unacceptable? The language in the information model was definitely intended to express the acceptability of using this approach from a Babel WG perspective (because I knew that's how it would be done in TR-181). Would this be unacceptable to people with YANG expertise? I think my preference would be to use this approach, since it would provide additional consistency between the TR-181 and YANG models. >>> >>> If other data models use an extended integer range and -1 to indicate >>> a special case, then this may be a strong reason to do the same in the >>> IETF YANG data model. Consistency across data models is a value, in >>> particular for systems that may have to support multiple. While the >>> conversion of different notations no hard, its one more thing to >>> potentially get wrong. >>> >>> If you were starting with a blank sheet of paper, then the YANG idiom >>> would likely be to use a union of a 16-bit integer and a special >>> (string) value, which might even be of type empty. >> >> I hear two suggestions on what the “other” construct should be in the union statement. Use ‘empty’ as you suggest, or use ‘boolean’. Are there any pros/cons for either of the approaches? > > 'boolean' doesn't seem right, since that would mean that you could see > the values 'true' | 'false' | <uint16>. > > If you want a union I suggest a union with one enum, perhaps: > > type union { > type enumeration { > enum null; > } > type uint16; > } > > But Jürgens point about using a solution that other data models use > makes sense. That would mean something like this: type union { type empty; type uint16; } Right? > > Yet another alternative could be to not instantiate this leaf when the > value in the information model is null. I have never been very clear on what happens when the leaf goes from a defined value to null. In other words, how do you “un-instantiate” a leaf? Do you delete it? Cheers. > > > > /martin > > > > > >> >>> >>> One of the reasons to have no common approach to these kind of >>> questions is to provide the flexibility needed to do the right thing >>> in different contexts. Of course, you may want to stay consistent in a >>> data model or a collection of related data model. >>> >>> I skimmed RFC 8407 and it seems we do not have text discussion this >>> specific situation. Perhaps we should have text, perhaps I have >>> overlooked it. ;-) I think there are different patterns to choose from >>> to handle this situation with their various pros and cons. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >> >> Mahesh Jethanandani >> mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com
- Re: [babel] [netmod] NULL value for uint16 Mahesh Jethanandani
- Re: [babel] [netmod] NULL value for uint16 Jürgen Schönwälder
- Re: [babel] [netmod] NULL value for uint16 STARK, BARBARA H
- Re: [babel] [netmod] NULL value for uint16 tom petch
- Re: [babel] [netmod] NULL value for uint16 Juliusz Chroboczek
- Re: [babel] [netmod] NULL value for uint16 STARK, BARBARA H
- Re: [babel] [netmod] NULL value for uint16 tom petch
- Re: [babel] [netmod] NULL value for uint16 Jürgen Schönwälder
- Re: [babel] [netmod] NULL value for uint16 Mahesh Jethanandani
- Re: [babel] [netmod] NULL value for uint16 Acee Lindem (acee)
- Re: [babel] [netmod] NULL value for uint16 Carsten Bormann
- Re: [babel] [netmod] NULL value for uint16 Jürgen Schönwälder
- Re: [babel] [netmod] NULL value for uint16 Mahesh Jethanandani
- Re: [babel] [netmod] NULL value for uint16 Mahesh Jethanandani
- Re: [babel] [netmod] NULL value for uint16 Carsten Bormann
- Re: [babel] [netmod] NULL value for uint16 Jürgen Schönwälder
- Re: [babel] [netmod] NULL value for uint16 tom petch
- Re: [babel] [netmod] NULL value for ip-address tom petch
- Re: [babel] [netmod] NULL value for ip-address STARK, BARBARA H
- Re: [babel] [netmod] NULL value for ip-address tom petch
- Re: [babel] [netmod] NULL value for ip-address Qin Wu
- Re: [babel] [netmod] NULL value for uint16 Sterne, Jason (Nokia - CA/Ottawa)
- Re: [babel] [netmod] NULL value for uint16 Andy Bierman