Re: [netmod] draft-ietf-netmod-geo-location-01: an optional location info

Ladislav Lhotka <lhotka@nic.cz> Thu, 11 July 2019 10:45 UTC

Return-Path: <lhotka@nic.cz>
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 421B112017D for <netmod@ietfa.amsl.com>; Thu, 11 Jul 2019 03:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 GyolRY4M-vzF for <netmod@ietfa.amsl.com>; Thu, 11 Jul 2019 03:45:08 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 588A81200E3 for <netmod@ietf.org>; Thu, 11 Jul 2019 03:45:07 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 15DA11820420; Thu, 11 Jul 2019 12:44:45 +0200 (CEST)
Received: from localhost (nat-1.nic.cz [217.31.205.1]) by trail.lhotka.name (Postfix) with ESMTPSA id A569C182004A; Thu, 11 Jul 2019 12:44:23 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Jan Kundrát <jan.kundrat@cesnet.cz>, netmod@ietf.org
In-Reply-To: <8bcdad12-cec1-47b2-b8ad-bb8ab6d6783e@cesnet.cz>
References: <8bcdad12-cec1-47b2-b8ad-bb8ab6d6783e@cesnet.cz>
Mail-Followup-To: Jan Kundrát <jan.kundrat@cesnet.cz>, netmod@ietf.org
Date: Thu, 11 Jul 2019 12:44:43 +0200
Message-ID: <87lfx4df50.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EhbbQwL3yxktgHxtu1nTdYu4BSQ>
Subject: Re: [netmod] draft-ietf-netmod-geo-location-01: an optional location info
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Jul 2019 10:45:12 -0000

Jan Kundrát <jan.kundrat@cesnet.cz> writes:

> Hi, I'm augmenting the ietf-network and ietf-network-topology 
> from RFC 8345,  trying to add geolocation information to the 
> network nodes. I found your  draft (thanks for it!), 
> draft-ietf-netmod-geo-location-01. What I am  struggling with is 
> adding the geolocation as an *optional* element. 
> 
> When I try this YANG construct: 
> 
>   augment "/nw:networks/nw:network/nw:node" { 
>     when "../nw:network-types/my-topo:topology-type"; 
>     description "Optical elements within a network"; 
> 
>     uses geo:geo-location; 
>   } 
> 
> ....then my YANG instance data validator, libyang, complains 
> when the  location is missing:

The "location" choice is defined as mandatory, so an instance of 
one of the cases must be present. I don't know whether it is 
necessary or not, but you can avoid it easily by overriding the 
definition:

      uses geo:geo-location {
          refine geo-location/location {
              mandatory false;
          }
      }

Ahoj, Lada
 
> 
> err : Mandatory choice "location" missing a case branch. 
> (/ietf-network:networks/network[network-id='...']/node[node-id='...']/my-topo:location/geo-location) 
> 
> I can do the augmentation with one more container (a presence 
> one) like  this: 
> 
>   augment "/nw:networks/nw:network/nw:node" { 
>     when "../nw:network-types/my-topo:topology-type"; 
>     description "Optical elements within a network"; 
> 
>     container location { 
>       presence true; uses geo:geo-location; 
>     }     
>   } 
> 
> The resulting data then contain an extra level of nesting. I 
> think that  this is suboptimal. 
> 
> I have two questions: 
> 
> - Is that perhaps a bug in libyang?  - If libyang is correct, is 
> there a way of making the location info  optional without that 
> one more level of nesting? 
> 
> Also, the example does not work as-is because it's importing the 
> module  using a wrong name. Here's a tiny patch: 
> 
> index 7bd8622c..088621a1 100644 --- 
> a/experimental/ietf-extracted-YANG-modules/ietf-uses-geo-location@2019-02-02.yang 
> +++ 
> b/experimental/ietf-extracted-YANG-modules/ietf-uses-geo-location@2019-02-02.yang 
> @@ -2,7 +2,7 @@ module ietf-uses-geo-location { 
>    namespace 
>      "urn:ietf:params:xml:ns:yang:ietf-uses-geo-location"; 
>    prefix ugeo; 
> -  import geo-location { prefix geo; } +  import 
> ietf-geo-location { prefix geo; } 
>    organization "Empty Org"; contact "Example Author 
>    <eauthor@example.com>"; description "Example use of 
>    geo-location"; 
> 
> The -00 version was correct in this, BTW. 
> 
> With kind regards, Jan 
> 
> _______________________________________________ netmod mailing 
> list netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 

-- 
Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67