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

"STARK, BARBARA H" <bs7652@att.com> Tue, 14 September 2021 13:51 UTC

Return-Path: <bs7652@att.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 B508A3A1F7A; Tue, 14 Sep 2021 06:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=att.onmicrosoft.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 pzCLZoJT5Jqt; Tue, 14 Sep 2021 06:51:51 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8039C3A1F72; Tue, 14 Sep 2021 06:51:51 -0700 (PDT)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 18EDiKl8032139; Tue, 14 Sep 2021 09:51:46 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 3b2fe22f9e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Sep 2021 09:51:46 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 18EDpi2A001104; Tue, 14 Sep 2021 09:51:45 -0400
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 18EDpcSs001008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Sep 2021 09:51:39 -0400
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 8330F4005955; Tue, 14 Sep 2021 13:51:38 +0000 (GMT)
Received: from MISOUT7MSGEX2CF.ITServices.sbc.com (unknown [135.66.184.212]) by zlp27126.vci.att.com (Service) with ESMTP id 5E1524005953; Tue, 14 Sep 2021 13:51:38 +0000 (GMT)
Received: from MISOUT7MSGEX2DE.ITServices.sbc.com (135.66.184.219) by MISOUT7MSGEX2CF.ITServices.sbc.com (135.66.184.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Tue, 14 Sep 2021 09:51:37 -0400
Received: from MISOUT7MSGETA03.tmg.ad.att.com (144.160.12.222) by MISOUT7MSGEX2DE.ITServices.sbc.com (135.66.184.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Tue, 14 Sep 2021 09:51:37 -0400
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by edgeso3.exch.att.com (144.160.12.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Tue, 14 Sep 2021 09:51:37 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R2iwiXqV7Nrqvh2kUBNZsDN2nuOnZgczuW0Jr8ar5R8ydg+DnDJlRXL95P17PUJ3eFuwWwko11W/m7pAJOTgAQ5EV2SOWxBeSAcHjkAey62dSvZo3+qnf2lfFz11OoZNn2covFxCtDaPCytPP6nb+208+x22JiHYI6XrzHtBPnov9RVFydPSNSQkvt9W9ziXPJP0uehTaXSnjhtjaWnoafeN47YVBuDQU6HcQOkQooPso+ivjMKcrvcyu8Nye13DliqxV5XgGEIUEoLLNNHAkqrPr/R7jxyB2qgQHCn7oq9GrrQDq7o0gE3yxvSUt0FdWva5LM0ie2V3YZRvhIhO7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L+HKycR/sOkvoodpjR+aa5gJGw+gn3h3nYgLO0jE65A=; b=DjEMwV/nOHeUPdXUf9RdMXBivtmJ9mc+N/2p4kRnc4KznEoOcYO0BnP3ftLiTe11tN1iUwg+rl/HJM8jXnGaFfeycN/C5rEUtHtRpz93BlFeNhDOUlJ3Dkn83AtwSolkzRvMwYllTTPRTlXPgLjJcUwX9LpmHlp1hCEWwvtBkk8191jOq6NNeWOAoxIP97uLoLLk3V6HVXCezx2QaVRCzkrVRcUbN+NsnsA8Mak+VLwtzG19JwKEojQLOXfwleuOoIQ3gNz91Oaxo9IPGlU0q6HVmtDwdGdlJR9vnH/DxiSejZNrghIX1czcnCp0hhmOwdTy7ilQsnCy2bwEde6N9w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L+HKycR/sOkvoodpjR+aa5gJGw+gn3h3nYgLO0jE65A=; b=hyHYn8AG5oCd9ALc2hJ+r2Io4fS5yr+NgmFTpewJxdDUe6FtIxdjt2V2kXttD0XTAPL1tG7z75Yryl1w75uqidFUd4oNRliu8Q57Wk/7Ql+qbJPBIANUTnC2xtlSRzATVdWOj39/C8F43dT/oRagV//uJlRbHleqLGP3yS8aag8=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6155.namprd02.prod.outlook.com (2603:10b6:5:1fb::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Tue, 14 Sep 2021 13:51:36 +0000
Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::ddec:9436:4971:5d1e]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::ddec:9436:4971:5d1e%4]) with mapi id 15.20.4523.014; Tue, 14 Sep 2021 13:51:36 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'tom petch' <ietfc@btconnect.com>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>, 'Mahesh Jethanandani' <mjethanandani@gmail.com>
CC: "'netmod@ietf.org'" <netmod@ietf.org>, 'Babel at IETF' <babel@ietf.org>
Thread-Topic: [netmod] [babel] NULL value for uint16
Thread-Index: AQHXqUiEDT1SO2+3HkGPUisDdYR4/6ujfOXQ
Date: Tue, 14 Sep 2021 13:51:36 +0000
Message-ID: <DM6PR02MB692446F49506791E90B0D23EC3DA9@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <AM7PR07MB624802516EFB174B6912C5DAA0D69@AM7PR07MB6248.eurprd07.prod.outlook.com> <20210910121430.kofyvd2q3ludm2pk@anna.jacobs.jacobs-university.de> <AM7PR07MB62482A4271AF1CA5013EB136A0D69@AM7PR07MB6248.eurprd07.prod.outlook.com> <b1b1cd18-537f-561f-dcb1-9aca41b7d3c9@labn.net> <20210910200902.bic4rhyhp75bgsjz@anna.jacobs.jacobs-university.de> <BBC6AA9F-86C1-4A9C-86FD-AD77668CA9D9@gmail.com> <20210913200455.xot7lihpmqiemm5c@anna.jacobs.jacobs-university.de> <DM6PR02MB69248D2780D5C880CC647783C3D99@DM6PR02MB6924.namprd02.prod.outlook.com> <AM7PR07MB6248BBB558136D1E6F8C1549A0DA9@AM7PR07MB6248.eurprd07.prod.outlook.com>
In-Reply-To: <AM7PR07MB6248BBB558136D1E6F8C1549A0DA9@AM7PR07MB6248.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=att.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7337d7b5-ea08-41dc-a8c7-08d97786c500
x-ms-traffictypediagnostic: DM6PR02MB6155:
x-microsoft-antispam-prvs: <DM6PR02MB615573DABE87010942A5F7D6C3DA9@DM6PR02MB6155.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 15bo2qMaPXgPqqY7ot48EKhkvNmYQNPqLjhCJ7pKsrwWErNj7RuXeexzze6qkNY8bQM/v3Ku2Sog/fmKuPjHPmSElZlXTjvMVVjszVL09adcOUcQ0oe0D9+wacDr+fOhi2VzF+g2t3OYajQQTk9r1yi5cuILgtIjc0cpNy0xaNlQ7Ako5jONYRv06+p08srAouma5eMqaQVab22B+rGg7i3w71e/ZhHoxI9F+ty/9gG4glzoIICNjFhuphaAL3jPs+lX6+66H3jm69oQpmxdORfUtlBzBhUv6QQFs0i+Wr7WK+SZOe7psrJVzijhYYSomerboDgfve4vryx219Tyy2h+1pfJY6YkuMYBM6BckAEmC9HNhrAw5ITGACgqccTdlg9hflLHlLLKk7qnfyD0/YYOqycOVNTpzzkGVaUNZFn0062nGi/svCxlWyHgM5e2HotGS2lADocbNRQZlm75u1BQy3+GCiGqSw4yPycGGRQsU8kdPh6q9bviyzjBcSbPQO7BmdvaOF4L1ZmOnUHBhA+cRIfNps/1U7rMDjTm2L7V7vU9aImKdhxzYXRadwS5LP7yhMu5UyWtl5VbLKdDMJQmLwlV4xHQ9SJa1juqlLEdzMw7Bp8xguDDRKcwAWDE1H384nLZYzeJzucbJaPahy6+RXO0zOVxLbQw8GwWi1vE1SEdO8kYhE4xHlMaBW9KUS3RxER8TRoA5BcgwhHbqfX1u7tNfw00CkmMoRvPZ2ZlazVbrut10k9cbBYJH8QTJ5eH1ZYnOepnqNg5i0MALFV++SGc8qZCy6JWAi8DfgYVA5H/H+nr9IjZhUEjIMR0WOBAAXKuFC7R8LDQJRTZxQX0+fyPVqZO4zc1GJyZOaU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(346002)(366004)(376002)(110136005)(966005)(7696005)(33656002)(478600001)(6506007)(83380400001)(5660300002)(82202003)(4326008)(53546011)(8676002)(52536014)(38070700005)(54906003)(71200400001)(66446008)(122000001)(64756008)(66946007)(8936002)(66574015)(2906002)(26005)(38100700002)(66556008)(186003)(66476007)(9686003)(86362001)(76116006)(316002)(296002)(55016002)(309714004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 2fe7rLdvT+eqbXM0taxnXaMfiYH9a1JTiLI3P5umksym05j+BbyGEKfRvA/Jz2bv+p+XnauhfACOt3KKGSsvbyL12z5DvcU3Hgisauin4fXABICY+mcuGddAjlEh1yx/5Q/G9EGfanRHrKZzVUcZb7klbq3OnPBo+NOOooXYb+l5An4yKQXYDkAnOsxiOHZbJ0B4KKungI3UWgSruJ8FAPVb3Y2SHZ8qZrfUnq0B7eOMrs+dtUX1hUA6N1be0GnvSr6Te/WEn++wVyr+g33y6SLroRrkpxiMBt4+YWI62999J9RROYidY4IqGdgog99MMLGKaS6+FASqSu+YhzoLPakQ03/KgEbn4NucZZ9BKl76tUUaeJbQFoDJ65ucVobCJONVpqP4yUqyLyjSZZyfRxHOAzfKz6Y9Jfx+zgoqF2bNuHf1qjLoSByQXkoQE3D2wOAoxuMEexPO0RL2oXr+vdvFnWz2H+BgtoDzhHn43om1KHs56xghufADEedFRfpcwf3pNXVy4aO20r3t0d47UHbu07SLbejqPnJH2Gkuavof5wYctxwfY262BGF3BFNHuKCgVDMp/ft8Vk1gRmUQHJMJIjlj9NmBSQU1mpV2ydryf3B15CZvn6Go08fq96sp2qHKitoO2ZFOYP4FqGWyTWjylOrPI8EAVY7I7LH51F8WdHtqJsIO92kGBlOWCBYpduJ2BoaJ0rTWUAGP58A0sXVJiihi5z56EKTcAC1w1CKkQrNkhr+He+pECkO0QwcD46Y242nTRb4RawrM3B2c2Y2lVT+LkrJdzXvp2TVkY67vJiWWMRaxJi1dRPn8P81LEzpBKSaucn/l0idFSR0U7zrQJ/xvgtKljd5aDbA3t0ITXvw6dN4OAS7GONFuglojKKnc3UtTs+mKhbFF8u43GQFvNBK6UvSHnlJK3Aq8Kag2XNv77bxhUNIBHQQxky4samhWfNXkuz5hVkulM5dQ8Bv2DEn8GIUYotl9Gmkj3l9tGpTNQTtFkzTWgaa4cHx3TUQkFC3K0SZXJfheDEWJw/QTkEn1tnFBr2IIeFrN50j02tD10RBz9S4IZ8tc0o8hGPQcc2thwt4puA54ztldOMz3iULiAsni40j8wlHrfOKO4cz2eOw76YdFGGQ63moTp1F6TNRGFD/y6WrbFHoF0XY+xltnJfH9RDhr/0kukOh7E3UwdHJYgZ5Mk6+UTJvUBu0q9ZFN4g4Mt6nILXCUYSKnCQnk+GPjZTNmMLmjwyhZPtzArxYYW5qFJJ39uhHswxNsKjyZWVvAqSwRYC3vGn2IexZ5QD9NJ5Rxn1WopWc=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7337d7b5-ea08-41dc-a8c7-08d97786c500
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2021 13:51:36.2590 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Av4dFpwwdzDXE0rOUwG73QPor4IE//DR0BVt+TzqmOxf7nO3H+Zr7Q8yU47UqmZw
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6155
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 59B7EEB38A6A39729CC3A634E11AAE88DB32EB7C5405701FFF958F7FCCFD30392
X-Proofpoint-ORIG-GUID: BjB-UtKKwGJW9YON_aM5FXpec2e5FJ8c
X-Proofpoint-GUID: BjB-UtKKwGJW9YON_aM5FXpec2e5FJ8c
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-14_03:2021-09-14, 2021-09-14 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 impostorscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 suspectscore=0 adultscore=0 mlxlogscore=999 phishscore=0 lowpriorityscore=0 clxscore=1011 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001 definitions=main-2109140085
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/up2NLx87Fep6i4T5DzZRI5RfZIs>
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 13:51:57 -0000


> I seem to be coming into this discussion in the middle, so I hope I'm
> understanding where things are. Comments in-line.
> 
> > Hi Mahesh,
> >
> > management interface usually do not change protocol semantics (for the
> > simple reason that protocol engines do not necessarily know which
> > management interfaces control them and their peers).
> >
> > Does the Babel RFC reserve the special sequence number 0? If not, does
> > this document formally update the Babel RFC to reserve the sequence
> > number 0? And will implementations and deployments follow on or will
> > we see "old" and "updated" implementations in the wild causing
> > operational trouble?
> 
> Yes, the Babel RFC makes it clear that 0 is a valid value that must not be
> confused with NULL.
> I have no idea what conventions exist for a YANG model to distinguish between
> 0 and NULL in such cases, but merely expressed that the distinction must exist.
> Whatever conventions exist within YANG to make this distinction can be used. It
> sounded from Tom's email that several conventions exist for handling this.
> Under no circumstances should this YANG model allow the valid value of zero to
> be repurposed to mean NULL.
> 
> <tp>
> Barbara,
> 
> Apologies for making a mess of raising this issue; I am struggling with webmail
> and a PC that has a mind of its own such that I cannot send e-mails where I want
> to or even when I want to:-(
> 
> Anyhow, I agree that the Information model makes it clear the NULL and zero
> are different.  YANG has no concept of NULL; some languages do, YANG does
> not.  This raises  number of possibilities.
> 
> One is to deviate from the Information Model and treat zero as NULL but I
> would not expect that to be acceptable.
> 
> Another it to modify the range by making uint16 into int16 and making a
> negative value represent NULL in this model.  Again, I would not expect that to
> be acceptable but you could make it a int32 or uint32 with a range restriction
> such that one value means NULL..
> 
> Another is to make the objects a YANG union of uint16 and something else.
> YANG has a built-in type 'empty' which has no value(!) and so a union of uint16
> and empty is probably the closest YANG gets.  A similar approach is a union of
> uint16 and boolean.  My YANG is not up to the merits of the two approaches.  I
> have never been comfortable with 'empty' but there is plenty of it about in the
> IETF. By the same token, almost all models have a union in the shape of an ip
> address which is a union of ipv4 address and ipv6 address; a union is something I
> am comfortable with.
> 
> I do not know of an exact parallel to what you want to do.  I do see 'null' as one
> value of the text string in an enumeration which is fine for enumerations!  I also
> see the choice/case construct used with one case having a YANG type 'empty'
> which is perhaps the closest if you do not want to use a union.
> 
> HTH
> 
> Tom Petch

Hi Tom,
Thanks for making this an issue! I think it's important that we get it right.
This is something Mahesh and I have discussed several times (and we still apparently didn't get it right).
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.

Thanks again for raising this issue.
Barbara

> > /js
> >
> > On Mon, Sep 13, 2021 at 12:49:33PM -0700, Mahesh Jethanandani wrote:
> > > [Bringing in babel WG, instead of maintaining two threads]
> > >
> > >
> > > Hi Juergen,
> > >
> > >
> > > > On Sep 10, 2021, at 1:09 PM, Jürgen Schönwälder
> > <j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > On Fri, Sep 10, 2021 at 01:40:03PM -0400, Lou Berger wrote:
> > > >
> > > >> and it references an RFC that says:
> > > >>
> > > >>      This is a 16-bit unsigned integer;
> > > >>      if the data model uses zero (0) to represent NULL values for
> > > >>      unsigned integers, the data model MAY use a different data type
> > > >>      that allows differentiation between zero (0) and NULL.
> > > >
> > > > We are talking about RFC 9046? RFC 9046 repeats this sentence several
> > > > times but I find it difficult to infer the intended meaning. If 0 is a
> > > > legal value, you can't have it represent "NULL" at the same time.
> > >
> > > There are five definitions in the Babel YANG model
> > <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-
> > babel-yang-model-
> >
> 11.html__;!!BhdT!w6VP0VXwBo8HQB7xl29xPqAxO7zHbtal44Pwbxrh6lIs8a04rPj
> > 0rzZ_DACdBQ$ > that use NULL to represent a special meaning.
> > >
> > > With 'babel-route-received-metric', and 'babel-route-calculated-metric'
> > values use NULL or 0 to represent that a route was NOT received. A non-zero
> > value indicates that a route was received and subsequently advertised.
> > >
> > > With 'babel-expo-mcast-hello-seqno', and 'babel-exp-ucast-hello-seqno' a
> > value of NULL or 0 is used to represent that a multicast, or unicast hello
> packets
> > respectively are NOT expected or processing of multicast/unicast packets is
> not
> > enabled. Although not explicit stated, it also means that the sequence number
> > cannot be a 0.
> > >
> > > Finally, with 'babel-ucast-hello-seqno' a value of NULL or 0 is used to
> > represent a unicast hello is not being sent. A non-zero value reflects the
> current
> > sequence number in use for unicast hellos. Again, although not explicit, it also
> > means that the sequence number cannot be a 0.
> > >
> > > >
> > > > In YANG, we tend to not instantiate leafs that do not have a value.
> > > > Anyway, if a YANG author wants to report a special value to indicate
> > > > that there is no value, then you have design for it and reserve and
> > > > set aside a special value from the number space or use a union.
> > >
> > > This YANG model reserves the value of 0 to indicate that these leafs are not
> > set or the particular attribute is not enabled.
> > >
> > > Thanks.
> > >
> > > >
> > > > RFC 9046 uses the same text for things like sequence numbers. Skimming
> > > > RFC 8966, it seems sequence numbers are 16-bit integers:
> > > >
> > > >   Sequence numbers (seqnos) appear in a number of Babel data
> > > >   structures, and they are interpreted as integers modulo 2^(16).
> > > >
> > > > The text in the context makes me believe they are an unsigned 16-bit
> > > > integers. If so, there simply is no way to use 0 to indicate that a
> > > > sequence number is absent. The problem really might be the text in RFC
> > > > 9046.
> 
> RFC9046 text is intended to allow and encourage data models to do whatever
> they need to do to ensure they can distinguish between a value of 0 and a NULL
> value. For example, in BBF TR-181 data model, we use a signed integer for these
> parameters, where "-1" means "null value" and 0 to 2^16 represent actual
> values. This use of -1 and a signed integer to convey NULL for an unsigned
> integer is a convention that has long been defined in TR-181 data modeling
> rules. OTOH, Babel implementations written in languages like C *are* able to
> distinguish between a zero-length variable and a zero-value variable -- so their
> GUIs have no difficulty with this distinction and can simply use an unsigned
> integer.
> 
> Different data modeling languages are likely to each have their own mechanisms
> for handling this -- which means it would have been improper for RFC9046 to be
> proscriptive about *how* a data model should distinguish between null and 0.
> Therefore, the text in RFC9046 merely states that although the native variable is
> a 16-bit unsigned integer, it must be possible to indicate null as something
> distinct from 0. RFC9046 does not dictate how that should be accomplished. The
> data model needs to ensure this distinction exists using whatever method makes
> sense or whatever convention exists for that data modeling language.
> Barbara
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;
> !!BhdT!z9HMtl5ev04-D11rq22Qye-5_sscMd1C-
> sWwIDBqeMrQ2tPPXauYRZI_wB2KAA$