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
- [netmod] draft-ietf-netmod-geo-location-01: an op… Jan Kundrát
- Re: [netmod] draft-ietf-netmod-geo-location-01: a… Ladislav Lhotka
- Re: [netmod] draft-ietf-netmod-geo-location-01: a… Jan Kundrát
- Re: [netmod] draft-ietf-netmod-geo-location-01: a… Christian Hopps