Re: [netmod] YANG identities and identityref's

Martin Bjorklund <mbj@tail-f.com> Thu, 03 May 2018 20:23 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE9A12EA90 for <netmod@ietfa.amsl.com>; Thu, 3 May 2018 13:23:12 -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, SPF_PASS=-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 MAUWAUMS1Twj for <netmod@ietfa.amsl.com>; Thu, 3 May 2018 13:23:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 22A7F12DA11 for <netmod@ietf.org>; Thu, 3 May 2018 13:23:10 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id C85431AE030D; Thu, 3 May 2018 22:23:07 +0200 (CEST)
Date: Thu, 03 May 2018 22:23:07 +0200 (CEST)
Message-Id: <20180503.222307.1318677205860676080.mbj@tail-f.com>
To: acee@cisco.com
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <04CFDAC7-F364-49F0-97D0-64A88986FE26@cisco.com>
References: <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com> <92458ec3b02ba207239df397d4c8fe9cdbdfd244.camel@nic.cz> <04CFDAC7-F364-49F0-97D0-64A88986FE26@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SeKRo3eHfbSxL7SjJwhq2JUlcEE>
Subject: Re: [netmod] YANG identities and identityref's
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 May 2018 20:23:12 -0000

"Acee Lindem (acee)" <acee@cisco.com> wrote:
> 
> 
> On 5/3/18, 2:40 PM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
> 
>     On Thu, 2018-05-03 at 18:00 +0000, Acee Lindem (acee) wrote:
>     > Hi Lada, 
>     > 
>     > So you have a base identify of foo-type and subordinates of
>     > foo-type-1, foo-
>     > type-2, ... foo-type-9. You have a data leaf that type identityref
>     > foo-type
>     > but the actual instantiation is not one of the known foo-types. Should
>     > a foo-
>     > type-unknown be defined to return for this case or should one just
>     > return foo-
>     > type? 
>     
>     Hmm, the actual instantiation looks like invalid data. If the leaf is
>     an
>     identityref with "foo-type" as its base, then permitted values are
>     exactly those
>     "foo-type-[1-9]".
> 
> The whole reason to use identities rather than enums is to allow for
> incremental extension.

Yes.

> With routing protocols, it is possible if not
> likely to have an instantiation of a data leaf that is unknown. So, we
> absolutely need to handle this case.

But the instrumentation code that fills in the value (assuming it is
config false) knows what it is, right?  Then it might be better to
have the vendor define a proprietaty identity that is derived from
foo-type, and let the instrumentation code use that identity.


/martin

> Acee 
>     
>     If the server supports a particular type, then I would expect it to
>     implement a
>     module where the identity corresponding to that type is defined.
>     
>     Lada 
>     
>     >  
>     > 
>     > Thanks,
>     > Acee
>     > 
>     > On 5/3/18, 1:49 PM, "netmod on behalf of Ladislav Lhotka"
>     > <netmod-bounces@iet
>     > f.org on behalf of lhotka@nic.cz> wrote:
>     > 
>     >     Hi Acee,
>     >     
>     >     I am not sure what you mean by unknown identities. In general, the
>     > identity used
>     >     as the base of an identityref (or in Xpath functions
>     >     derived-from/derived-
>     > from-
>     >     or-self) should be the most general identity that can match at the
>     >     given
>     > place.
>     >     
>     >     Do you have any example illustrating your case?
>     >     
>     >     Lada
>     >     
>     >     
>     >     On Thu, 2018-05-03 at 17:30 +0000, Acee Lindem (acee) wrote:
>     >     > Let’s say one define a base identity with a hierarchy of
>     >     > identifyref’s
>     > using
>     >     > it. This will allow for augmentation in future models. Should one
>     >     > also
>     > define
>     >     > an identityref for the class of unknown identities? Or, should one
>     > simply
>     >     > return the lowest parent in the hierarchy matching the value? Many
>     > times, this
>     >     > would be the base identity.
>     >     >  
>     >     > Thanks,
>     >     > Acee
>     >     > _______________________________________________
>     >     > netmod mailing list
>     >     > netmod@ietf.org
>     >     > https://www.ietf.org/mailman/listinfo/netmod
>     >     -- 
>     >     Ladislav Lhotka
>     >     Head, CZ.NIC Labs
>     >     PGP Key ID: 0xB8F92B08A9F76C67
>     >     
>     >     _______________________________________________
>     >     netmod mailing list
>     >     netmod@ietf.org
>     >     https://www.ietf.org/mailman/listinfo/netmod
>     >     
>     > 
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>     
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod