Re: [babel] [netmod] NULL value for uint16

Mahesh Jethanandani <> Tue, 14 September 2021 22:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 110F13A3495; Tue, 14 Sep 2021 15:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XvLXbO7h4fba; Tue, 14 Sep 2021 15:51:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E2013A34C1; Tue, 14 Sep 2021 15:51:01 -0700 (PDT)
Received: by with SMTP id w8so737136pgf.5; Tue, 14 Sep 2021 15:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Qi288jpIEntwg6YFTY3A6n48C/qAkL4edjtpSYTtoDI=; b=Jp50YlGXggx8juHGLQTRpt6B2CHIhh70WoQOe4wGJ//eTzNNOyaqHjDdWi+OLZ/4PP 4bzeqklt+nim4sX0BrGuHfFFsCOLO4sfaBB5d9QEDntnFJxXhC+1wC2+Plpmy+4vBOq9 gwivtdTtW27SOiZksXWse22UdHbXe2A777ANhH118wNWQjKtYilI6/bz3MbtXKX4F4WS 3JQql09cpcfAUAC93xKVZKKZehUy5r/woHb5WT6EucieaVoFj8TprvQiBMMATqoSUhW0 QtrXGXwBfYSKU6+eSCEgMgUMF0c8R+hVL3euKWufjg4K45Ks2J0PgeHqUxQI2Pe8xfOD Cjag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Qi288jpIEntwg6YFTY3A6n48C/qAkL4edjtpSYTtoDI=; b=OutHTp55xYpZD9kFmresjRm2hUdmRjHBMn/hK2SY6MWXo2BeCgiPrAg4YROkNDPFTD 31k/WFGnMcigXn1zEyPSnhjuR6GgkoI8thU0Wxa6GUW0ZADH5n2IRxa3CfzJp0ecJTFN mJVkzMMsr0CVJ7Ib0n95+Io12TtIfckKS3sSt0Hw1vhA6tx4fk446nb1M97eYuKm789e hpfiSRHf90yTHipRf04GLApTPH9yNisFOqZAV/19xQmbGY/9IXiPbA1EIMwspqg6DLy8 eOsAL8B0hblWWCpSh7Tf9mosPaNPBUs3xzUJFt0pKIbVqjWUPiqxfNSakbek0/Eli0Rv sXhA==
X-Gm-Message-State: AOAM5309XEqpjk1Ku3gKi0W9TaxNGIH/CvKtCECBXN1XORdOfoxm7DDq 586vcD61z2NPS9H089cEFmQ=
X-Google-Smtp-Source: ABdhPJyW1FftbbAv1tKA8hN9PJqC4fpA8yP/dIjAWkaGsDKzZGUlZcv3/sBMDNe6b7cReHGNKVSE2w==
X-Received: by 2002:a63:798c:: with SMTP id u134mr17725084pgc.479.1631659859928; Tue, 14 Sep 2021 15:50:59 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a71sm11666550pfd.86.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Sep 2021 15:50:59 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_83D425F1-5AEF-4183-8B9A-989202EE4F35"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 14 Sep 2021 15:50:58 -0700
In-Reply-To: <>
Cc: Juergen Schoenwaelder <>, Babel at IETF <>, "STARK, BARBARA H" <>,
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [babel] [netmod] NULL value for uint16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Sep 2021 22:51:08 -0000

A related question.

> On Sep 14, 2021, at 12:31 PM, Mahesh Jethanandani <> wrote:
> Hi Martin,
>> On Sep 14, 2021, at 11:17 AM, Martin Björklund < <>> wrote:
>> Mahesh Jethanandani < <>> wrote:
>>> Hi Juergen,
>>>> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder < <>> 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?

RFC 7950 says that the empty type cannot have a default value. The model had the value 0, which represented NULL as the default value for some of the attributes. With the suggested change, is there a way in the union for the empty type to be the default?

If not, I will have to use Martin’s suggestion above of using a null enumeration.


>> 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         < <>>
>>> Mahesh Jethanandani
>>> <>
> Mahesh Jethanandani
> <>
Mahesh Jethanandani