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