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

Jan Kundrát <jan.kundrat@cesnet.cz> Mon, 01 July 2019 17:34 UTC

Return-Path: <jan.kundrat@cesnet.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 D02FE120164 for <netmod@ietfa.amsl.com>; Mon, 1 Jul 2019 10:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
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 hjGcr1LlmMMb for <netmod@ietfa.amsl.com>; Mon, 1 Jul 2019 10:34:17 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F5D120672 for <netmod@ietf.org>; Mon, 1 Jul 2019 10:34:16 -0700 (PDT)
Received: from localhost (unknown [IPv6:2001:718:1:2c:b88f:a570:7aec:4192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 819AD40006A; Mon, 1 Jul 2019 19:34:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1562002450; bh=G6LJxix20e9FuBJ72EQp0z40xYFDm/6JDtmmM8QWqO4=; h=From:To:Cc:Subject:Date; b=VqjcmVnoBidpFzZEbKnWNb5jv/mkr44Hd7av85iKmdjd+m7XSBO4uHAXmhTkt4UNB Brl3rRliWasTemjmW53kYRSGAXwV/+dW5coN0OY9thiYxBpl1XxmblJoaBZARqZvkK RggRMgVUs6wOg4Ngtb1SOQOK3ubIpei4hs+MgqPo=
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jan.kundrat@cesnet.cz>
To: <netmod@ietf.org>
Date: Mon, 01 Jul 2019 19:34:01 +0200
MIME-Version: 1.0
Message-ID: <8bcdad12-cec1-47b2-b8ad-bb8ab6d6783e@cesnet.cz>
Organization: CESNET
User-Agent: Trojita/v0.7-402-g68ee77c9; Qt/5.13.0; xcb; Linux; Gentoo Base System release 2.4.1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zzifkHscHRraJYJZacGYgr6nDp0>
Subject: [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: Mon, 01 Jul 2019 17:34:20 -0000

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:

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