Re: [netmod] YANG identities and identityref's

"Acee Lindem (acee)" <acee@cisco.com> Thu, 03 May 2018 20:31 UTC

Return-Path: <acee@cisco.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 CDC3712EABF for <netmod@ietfa.amsl.com>; Thu, 3 May 2018 13:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1Q-uliLYZSIZ for <netmod@ietfa.amsl.com>; Thu, 3 May 2018 13:31:02 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35B2126CC7 for <netmod@ietf.org>; Thu, 3 May 2018 13:31:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6410; q=dns/txt; s=iport; t=1525379461; x=1526589061; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wwuGjUV7DulaJn6t+ZF8M8ctCNcfq9Zs2EIGVfmHfuw=; b=gjefpZeZBRJ+YnrYPdjBZ0LUV2WvM2OGJo7h+fELCuKQQXKJC0e2htV+ HUpBk8xO6+OeaSIz/+6jLp3H09l0tQw0/i4pq0Wi+lqMAqOtap40dM198 lwGNp7XEq5wMcPJddzoexwKM5FbxaBJWw8cTMsKD6RtzR8QnfuUxFASSQ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDtcOta/4cNJK1SAQkZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBg0NheigKg2OIAoxvgT07gQ+TG4F4CxgLhANGAhqCFiE?= =?us-ascii?q?0GAECAQEBAQEBAmwcDIUoAQEBAQIBAQEhEToLEAIBCA4KAgImAgICJQsVEAI?= =?us-ascii?q?EDgWFBwgPqSyCHIRYg22CQoEJhxyCE4EygmiDEQEBgTUBFBaDADCCJAKQeoc?= =?us-ascii?q?gCAKOSoxZil6FPQIREwGBJAEcOECBEnAVOyoBghgJiweFPm+PYYEYAQE?=
X-IronPort-AV: E=Sophos;i="5.49,359,1520899200"; d="scan'208";a="109036593"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 20:31:00 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w43KUxNG028513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 May 2018 20:31:00 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 3 May 2018 16:30:59 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 3 May 2018 16:30:59 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "lhotka@nic.cz" <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] YANG identities and identityref's
Thread-Index: AQHT4wcmcoN4Fa9nLE+0HGK7LDbJoKQeSw0AgABOfID//8A2AIAAXFiA//+/JAA=
Date: Thu, 3 May 2018 20:30:59 +0000
Message-ID: <1B80C265-E8CE-4A14-9DC2-F96B58A1E0AF@cisco.com>
References: <3B5F31C4-1504-4F0D-875D-A9B559B01A82@cisco.com> <92458ec3b02ba207239df397d4c8fe9cdbdfd244.camel@nic.cz> <04CFDAC7-F364-49F0-97D0-64A88986FE26@cisco.com> <20180503.222307.1318677205860676080.mbj@tail-f.com>
In-Reply-To: <20180503.222307.1318677205860676080.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E6EFDB9A950E954D858A501FA48095A1@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CMmQhYGs2b-XkBf4JRtzqGTOxzc>
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:31:05 -0000


On 5/3/18, 4:23 PM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

    "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?

No - there are multiple devices in the network and they could have different level of support. For example, OSPF will accept OSPF Link State Advertisement (LSA) TLV types that it doesn't yet understand. The OSPF Link State Database can be retrieved via a YANG model. This seems like a pretty basic use case to me. 

  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.

Or define the foo-type-unknown in the model since this is such a common case.  

Thanks,
Acee 
    
    
    /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