Subject: [netmod] ietf-system & GPS coordinates

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 9 Aug 2012 12:44:30 +0000

With more and more devices having built in GPS receivers, and the need for network administrators to map out the location of multiple devices, it would be nice if there was a standard way to set and retrieve the geographical location of a device.  I have created the following container that I think would fit nicely into the ietf-system data model. The verbiage was taken from RFC 1712

    container geographical-location {
      leaf latitude {
        type decimal64 {
          fraction-digits 16;
          range "-180 .. 180";
        }
        description
          "The latitude of the system expressed in degrees.
           Positive numbers indicate locations east of the
           prime meridian.";
      }
      leaf longitude {
        type decimal64 {
          fraction-digits 16;
          range "-90 .. 90";
        }
        description
          "The longitude of the system expressed in degrees.
           Positive numbers indicate locations north of the
           equator.";
      }
      leaf altitude {
        type decimal64 {
          fraction-digits 15;
        }
        description
          "The altitude of the system expressed in meters.";
      }
    }

Thoughts?

-Jeff

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 07:05:23 -0700

This may be OK if there was a YANG feature to make it optional.

Andy

On Thu, Aug 9, 2012 at 5:44 AM, Lange, Jeffrey K (GE Energy)
<[email-masked]> wrote:
> With more and more devices having built in GPS receivers, and the need for
> network administrators to map out the location of multiple devices, it would
> be nice if there was a standard way to set and retrieve the geographical
> location of a device.  I have created the following container that I think
> would fit nicely into the ietf-system data model. The verbiage was taken
> from RFC 1712
>
>
>

   if-feature geographic-location;

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 9 Aug 2012 14:15:01 +0000

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]]
> Sent: Thursday, August 09, 2012 10:05 AM
> To: Lange, Jeffrey K (GE Energy)
> Cc: [email-masked]
> Subject: Re: [netmod] ietf-system & GPS coordinates
> 

Doesn't the fact that it's not config=false implicitly make it optional?  Every deployed device in the world has a geographical location associated with it.  This just gives an administrator a place to put that location if they happen to know it.

-Jeff

> > With more and more devices having built in GPS receivers, and the need
> > for network administrators to map out the location of multiple
> > devices, it would be nice if there was a standard way to set and
> > retrieve the geographical location of a device.  I have created the
> > following container that I think would fit nicely into the ietf-system
> > data model. The verbiage was taken from RFC 1712
> >
> >
> >

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 08:15:10 -0700

> Doesn't the fact that it's not config=false implicitly make it optional?  Every deployed device in the world has a geographical location associated with it.  This just gives an administrator a plac…

None of the networking boxes in my house except my phone
has GPS. config=false is for the server to fill in, not the client.
You can use the /system/location string for this purpose if
you want.

I don't consider this to be part of the base conformance
for the module, so I would add a YANG feature to make that clear.

But I don't think we should add these objects because the location
string is available for what you want and most networking devices
to not report their GPS coordinates in monitoring information.
I think 'location' might be a separate module all by itself.
I doubt these 3 leafs will be sufficient for that.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Aug 2012 18:33:56 +0200

> for the module, so I would add a YANG feature to make that clear.

Some boxes might have GPS, but I assume this is the minority of the
network devices (since most of the network gear is typically located
inside buildings where GPS usually does not work). So for those boxes,
these are post-it objects. There has always been a debate how many
post-it objects are useful to have. On the other hand, logitude and
latitude carry more precise semantics than system/location, which
often refers to a name of a campus or something like that, not really
carrying coordinates. I do not really have a preference either way.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 09:46:05 -0700

The post-it notes are limited to 255 chars each.
(name, contact, location)

Can we raise this hard-wired arbitrary limit to 1023?
I think 1 location post-it is good enough for now.

Andy

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 9 Aug 2012 09:46:56 -0700

Well, that's a reasonable start... but it loses a huge part of the necessary metadata about a position.  Now, one might argue that RFC 1712 introduces that issue.

I guess when specifying this, you just add an 'expressed in WGS84 coordinates' and you get something more sensible.

Geodata is complicated... there are hundreds of projections and datum systems that might be used, so you really need to specify one or the interpretation is impossible.  WGS84 is a good default, as that is geographical lat/lon/altitude using the GPS coordinate system, and everyone can convert to/from that as required.

Andrew

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Aug 2012 19:57:35 +0200

> Can we raise this hard-wired arbitrary limit to 1023?

You probably want to start a separate thread as this has nothing to do
with GPS coordinates. I assume the 255 is inherited from MIB
world. That said, if we consider changing this limit, then we should
remote it rather than replacing it by another arbitrary limit, perhaps
adding text similar to .../interface/name.

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 9 Aug 2012 18:19:51 +0000

It would seem there is a place for both a "location" name (that is administratively assigned) and a "geo-location".  The location is the post it; someone might include geo location in it.  Geo-location would be system provided, for the minority of systems that support it (yup, most systems would be deployed inside, but there are certainly scenarios where it is valid and would presumably be important, such as equipment on pole tops in a smart grid).

--- Alex  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, August 09, 2012 10:58 AM
To: Andy Bierman
Cc: [email-masked]
Subject: Re: [netmod] ietf-system & GPS coordinates

/js

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Thu, 9 Aug 2012 18:27:04 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alexander Clemm (alex)
> Sent: Thursday, August 09, 2012 2:20 PM
> To: Juergen Schoenwaelder; Andy Bierman
> Cc: [email-masked]
> It would seem there is a place for both a "location" name (that is
> administratively assigned) and a "geo-location".  The location is the post it;
> someone might include geo location in it.  Geo-location would be system
> provided, for the minority of systems that support it (yup, most systems would
> be deployed inside, but there are certainly scenarios where it is valid and
> would presumably be important, such as equipment on pole tops in a smart
> grid).
> 

I agree.  Sure everyone could stick it into the location field, but this defeats the purpose of having a standard way of doing things.  I think it makes sense to have a config=true geo-location that can be administratively set, and a config=false current-location that is gated on a GPS capability.  We have products that are statically installed on towers, yet the customer wants to keep track of where they are on a map, but we also have products that are installed into the back of vehicles that have an active GPS connection.

-Jeff

> You probably want to start a separate thread as this has nothing to do with GPS
> coordinates. I assume the 255 is inherited from MIB world. That said, if we
> consider changing this limit, then we should remote it rather than replacing it
> by another arbitrary limit, perhaps adding text similar to .../interface/name.
> 
> /js
> 
> --

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Aug 2012 11:33:56 -0700

> I agree.  Sure everyone could stick it into the location field, but this defeats the purpose of having a standard way of doing things.  I think it makes sense to have a config=true geo-location tha…

This seems like overkill for most NETCONF deployments.
Good thing YANG has the augment-stmt.
Otherwise we would never finish any standard YANG module!

I think "geoloc" is out of scope for this module.

Andy

>> Behalf Of Juergen Schoenwaelder

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Aug 2012 12:13:39 -0700

Hi -

> From: "Alexander Clemm (alex)" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>; "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, August 09, 2012 11:19 AM
> administratively assigned) and a "geo-location".  The location is the
> post it; someone might include geo location in it.  Geo-location
> would be system provided, for the minority of systems that support
> it (yup, most systems would be deployed inside, but there are
> certainly scenarios where it is valid and would presumably be
> important, such as equipment on pole tops in a smart grid).

This whole discussion begs another question.  This is something
that comes up with surprising frequency when objects originally
conceived as "post-its" are implemented in more capable systems.
Specifically, what does a writeable location field (whether name or
coordinates) mean in a system capable of autonomously changing
its location?  If I change an autonomously mobile router's location
from Fresno to Bakersfield, should I have an expectation that
it will be on the road anytime soon?

How would we expect it to behave if implemented on a Mars rover?

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Aug 2012 21:36:58 +0200

> it will be on the road anytime soon?

Sure, if the device is backed by a robot, it will start to move.
 
> How would we expect it to behave if implemented on a Mars rover?

I assume the object won't be instantiated. Did you check yet but just
out of curiosity. ;-)

/js