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

From: Jan Kundrát <[email-masked]>
Date: Mon, 01 Jul 2019 19:34:01 +0200

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/[email-masked]
+++ 
b/experimental/ietf-extracted-YANG-modules/[email-masked]
@@ -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 <[email-masked]>";
   description "Example use of geo-location";

The -00 version was correct in this, BTW.

With kind regards,
Jan

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Jul 2019 12:44:43 +0200

Jan Kundrát <[email-masked]> 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. 
> 
> ....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
 
> I can do the augmentation with one more container (a presence 
> one) like  this: 
> 
>       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 --- 
> -  import geo-location { prefix geo; } +  import 
> ietf-geo-location { prefix geo; } 
>    organization "Empty Org"; contact "Example Author 
>    <[email-masked]>"; description "Example use of 
>    geo-location"; 
> 
> With kind regards, Jan 
> _______________________________________________ netmod mailing 
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/netmod 

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

---

From: Jan Kundrát <[email-masked]>
Date: Thu, 11 Jul 2019 15:54:50 +0200

> 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 

Thanks for explaining this. I'll leave it to the draft authors to evaluate 
whether an optional geolocation makes more sense than a hard-coded one.

Diky
Honza K.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 19 Jul 2019 07:08:10 -0400

The intention was for a location node to be required if the <geo-location> container was present. Apparently this will only work if "container geo-lcoation" is a presence container. I'm not even sure that's all that smart of a requirement (e.g., maybe someone just wants to indicate the reference-frame for an object). I'll remove the mandatory from location.

Thanks,
Chris.

> On Jul 11, 2019, at 9:54 AM, Jan Kundrát <[email-masked]> wrote:
> 
>> 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:
> 
> Thanks for explaining this. I'll leave it to the draft authors to evaluate whether an optional geolocation makes more sense than a hard-coded one.
> 
> Diky
> Honza K.
> 
> _______________________________________________
> netmod mailing list
> [email-masked]