From nobody Tue Sep 14 10:37:46 2021 Return-Path: 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 958C13A26C4; Tue, 14 Sep 2021 10:37:43 -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 EO1_v4Wy_H7l; Tue, 14 Sep 2021 10:37:39 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 D4BBA3A26C5; Tue, 14 Sep 2021 10:37:38 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id w19so8627539pfn.12; Tue, 14 Sep 2021 10:37:38 -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=xWzc/MOMP2Tq1HhTFxSn9rusQWkJ6OQQ6oUl+zfsn0c=; b=SrSHI9OvHcJ2Piw4zESePWQxkhoEGCcFS8Z8mWr/JN494PqgIbNWxWJ8N7xVukc9Ii ZQaWoZpwoZeWVzs0IYfbb2OMRPAkW5hivRvPU5Upq5ENbL0VPP178dyeDy/PWW/eyPl1 R1oLzUDZl2wXAjYZmjd31oH8MhG/mYTA1IEUMGqVO/4l7AH/0SCtQ/SNoXmGAYzREh2P biZa39+PD5MPuU5ZJJ8+VCsKm8jzMPxV65Mwy/gnAg9Pp0cyDmk5syoSntQc41ulfAd9 kXIc+TQWRA42SwOsHqDGg/1uiAcMh1hVuX9Fj7GhFPNkrkdpmppgqdKfvzUmk3s+g5IT Hqzg== 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=xWzc/MOMP2Tq1HhTFxSn9rusQWkJ6OQQ6oUl+zfsn0c=; b=xleVrXBBbNNoua9uRPu+bgsYunKBQnUM2Wf5IKeicEHz37nqzhS5zcvxzwc9ADuSQl RtpvOPckEtdn23GYXer4srsMUNGUMfX1hRJCQ6kzqkjNHX0FKTsw0+ak9FliaGhMB3Jv jfQSdfHmla1WPvcvNwcmn0SZJXbw9E5sax8kk5YmeEf74VzlzSAyhgTDGYPHKwZKSWVV 5DCD+o6gwuJ077hbhLWg1FT/aRMz29am2RfqaWqyljE7qxM7YE8lDYjNNrxbbQSe1Y6G JTH9NNn2/gZ1X1LsLpV+n9TNYOyv5vuA9ArW7Khemxo0/jTzO4keAC5EnFVXJuOGusii rb9w== X-Gm-Message-State: AOAM532vn6BJBxxssJl+X+XYoxuFQ098HeimuNKO/3tpnzOI+BYynTKx edNo2IOZJh68lOgXGqk7LmY= X-Google-Smtp-Source: ABdhPJyZGGz8JMJKzB0HGkvwn5o464FnJFPee0iqkwTfTkfDcSILggVdCmAyC47MZlytSujbWREPZg== X-Received: by 2002:a63:cf0c:: with SMTP id j12mr16660325pgg.411.1631641056968; Tue, 14 Sep 2021 10:37:36 -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 b1sm2150897pjl.4.2021.09.14.10.37.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Sep 2021 10:37:36 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <5F6A0BF9-06F9-41E9-8B9A-701608875934@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_02468BF9-3886-4684-AC7F-09CBD6556AC0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 14 Sep 2021 10:37:35 -0700 In-Reply-To: <20210914171729.ph5q77zm46z3zvxi@anna.jacobs.jacobs-university.de> Cc: "STARK, BARBARA H" , tom petch , "netmod@ietf.org" , Babel at IETF To: Juergen Schoenwaelder References: <20210910121430.kofyvd2q3ludm2pk@anna.jacobs.jacobs-university.de> <20210910200902.bic4rhyhp75bgsjz@anna.jacobs.jacobs-university.de> <20210913200455.xot7lihpmqiemm5c@anna.jacobs.jacobs-university.de> <20210914171729.ph5q77zm46z3zvxi@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 17:37:44 -0000 --Apple-Mail=_02468BF9-3886-4684-AC7F-09CBD6556AC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Juergen, > On Sep 14, 2021, at 10:17 AM, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = wrote: >=20 > On Tue, Sep 14, 2021 at 01:51:36PM +0000, STARK, BARBARA H wrote: >=20 >> 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.=20 >> 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.=20 >>=20 >> 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. >=20 > 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. >=20 > 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 =E2=80=9Cother=E2=80=9D construct = should be in the union statement. Use =E2=80=98empty=E2=80=99 as you = suggest, or use =E2=80=98boolean=E2=80=99. Are there any pros/cons for = either of the approaches? >=20 > 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. >=20 > 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. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_02468BF9-3886-4684-AC7F-09CBD6556AC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Juergen,

On Sep 14, 2021, at 10:17 AM, J=C3=BCrgen = Sch=C3=B6nw=C3=A4lder <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 =E2=80=9Cother=E2=80=9D construct = should be in the union statement. Use =E2=80=98empty=E2=80=99 as you = suggest, or use =E2=80=98boolean=E2=80=99. Are there any pros/cons for = either of the approaches?


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





= --Apple-Mail=_02468BF9-3886-4684-AC7F-09CBD6556AC0--