A YANG Grouping for Geographic Locations
draft-ietf-netmod-geo-location-11

[[ questions ]]

[ section 2.1 ]

* Is WGS-84 still the default for geodetic-datum when
  astronomical-body != "earth"?

  I think I might find it surprising if it were (i.e. if
  astronomical-body="enceladus" and geodetic-datum still defaults to "wgs-84"
  as opposed to an unspecified value or something that might cause a useful
  error message to be generated).

  I don't know enough YANG to know if the "when" statement is usable in this
  case to constrain the applicability of this default or not.


[[ nits ]]

[ section 3 ]

* In the description of "leaf astronomical-body",
  '67p/churyumov-gerasimenko lacks a closing quotation mark.

Thank you to the authors for addressing my concerns, and thank you to the shepherd for a very well-written shepherd write up.

Francesca

Thanks for this concise and highly readable spec. The references to other astronomical bodies made it fun to read, although it did lead to my mind repeatedly wandering back to the question of what coordinate system to use on a body such as asteroid Kleopatra (https://en.wikipedia.org/wiki/216_Kleopatra). For example, I think the 2D heading and speed computation given in Section 2.3 probably only works properly on a spherical or near-spherical body. I mean, that’s ok, for practical purposes I think if the spec works on Earth we can live with it and save the rest for the bis. :-)

Comments:

Section 6.1:

I notice the first two entries in the registry don’t have references. Are these coordinate systems so obvious to one skilled in the art that they don’t need references? They don’t mean much to me, although I suppose since they’re coordinate systems for the moon and Mars respectively, probably it’s not a big deal by the same reasoning as given above. 

General:

It does seem like a pity the document wasn’t updated to take on board the suggestion from the document shepherd (in 2019!):

“[Shepherd] I wish that Section 2.4. (Nested Locations) prodided an example using nested alternate coordinate sysrtems.  For instance, a data center building has a "street address", it's composed of “floors” that contain “rooms” or “cages”, that contain “racks” to hold equipment in “bays”, etc.   The draft compares itself to related work, but it is unclear if any of those system support nesting alternate coordinate systems such as those described, or even if it would make sense to do so.”

Appendix B:

Speaking of the shepherd, I agree with Éric’s comment that it would’ve been nice to acknowledge him.

Nits:

I think this document has the fewest nits per page of any document I’ve ever reviewed (kudos!),  but there are still a few.

Section 5.1: 

   In order to verify portability while developing this module the
   following standards and standard APIs and were considered.

“and were” -> “were”

Section 5.1.1:

   all the location values.  As the URI is a string, all values are
   specifies as strings and so are capable of as much precision as

“specifies” -> “specified”

Section 5.1.3:

   position type "gml:pos" which is a sequence of "double" values.  This
   sequence of values represent coordinates in a given CRS.  The CRS is

“represent” -> “represents” (because “sequence” is singular)

   Earth based CRS as well as virtual CRS should also be representable
   by the GML CRS types as well.

Drop “as well” (redundant with “also”). 

Section 6.1:

   This registry allocates names for standard geodetic systems.  Often
   these values are referred to using multiple names (e.g., full names
   or multiple acronyms values).  The intent of this registry is to

“Multiple acronym values” or better still “multiple acronyms”. 

Appendix A:

         description "A of locatable item";

Lose the “of”.

I support Lars' and Francesca's DISCUSS positions.

The shepherd writeup says: "There are no known implementations known to the Shepherd.  No vendors have indicated their plan to implement the specification.  It was originally forwarded to support DT's Terra Stream project."  I'm tempted to ask why this is slotted for Standards Track publication.

Thank you to Stefan Santesson for the SECDIR review.

** Section 6.1.  Should the constraining pattern “[ -@\[-\^_-~]*” and associated text from leaf geodetic-datum be used to guide the acceptable values of the 'name' column?

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit.

Thank you to Ken Watsen for his shepherd's write-up (including the WG consensus). Nice to have acknowledged him.

Note: I loved the "any other astronomical object" in the abstract ;-) and, for a while, I have believed that I was read an April 1st RFC... 

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==


-- Section 1 --
As written above, I like that this document does not limit itself to the Earth. May I suggest to add the ISS to the list ? If ISS is not considered as an astronomical body, then I really question the usefulness of this document.

-- Section 2.2 --
Just wondering whether latitude/longitude exist for all 'astronomical bodies' (magnetic field ? rotation on a single axe) ? I guess that it depends on the datum (just curious -- no need to reply).

-- Section 2.6 --
In the tree view, longitude/latitude/height have the same cardinality but section 2.2 states that height is optional.

-- Section 3 --
Any reason why the 'astronomical-body' is restricted to ASCII and not UETF-8 ?

Should the latitude/longitude leaves have ranges ? I.e., -90 +90 for latitude ?

== NITS ==

-- Appendix B --
Unusual location for the acknowledgements and it would have been nice to also acknowledge the doc shepherd.

Thank you for addressing my Discuss point!
For reference, my original comments from the -08 appear unchanged below.


Why do we only define velocity in terms of north/east/up, when we could
be in x/y/z coordinates where there is no clear "north" or "east"?

It would have been helpful for the shepherd review to point to the
thread at
https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUEMJw/
that attempted to discuss the feedback from the yangdoctor review -- the
mail with the review itself got no direct replies.

Section 2.1

   In addition to the "geodetic-datum" value, we allow refining the
   coordinate and height accuracy using "coord-accuracy" and "height-

My understanding is that "refine" is a YANG keyword, and the current
module/tree structure does not seem consistent with this description
referring to use of the YANG keyword (since we can just set new values
directly without needing to "refine" the YANG structure itself).  A
different word here might be appropriate.

   Finally, we define an optional feature which allows for changing the
   system for which the above values are defined.  This optional feature
   adds an "alternate-system" value to the reference frame.  This value
   is normally not present which implies the natural universe is the
   system.  The use of this value is intended to allow for creating
   virtual realities or perhaps alternate coordinate systems.  The
   definition of alternate systems is outside the scope of this
   document.

This paragraph doesn't really convince me that we need to include the
"alternate-system" capability in the proposed-standard version of this
YANG module at this time.

Section 2.3

   meters per second.  The values "v-north" and "v-east" are relative to
   true north as defined by the reference frame for the astronomical
   body, "v-up" is perpendicular to the plane defined by "v-north" and
   "v-east", and is pointed away from the center of mass.

When I read this I wondered if the "plane defined by v-north and v-east"
was taken at the initial snapshot position, or continuously updated with
the effect of v-north and v-east drift.  Given the stated application,
it's unlikely that it actually would matter, though, so it's not clear
that we should change the text to cover it.

Section 3

                  and 91..126). The IANA registry further restricts the
                  value by converting all spaces (' ') to dashes ('-')";

Is there a reason why we shouldn't disallow spaces via the regex (and
obviate the need for special processing at IANA)?

Section 5.1.2

The following subsection suggests that there is a "heading" field in the
W3C structure/API, but I don't see one listed in Figure 1.

Section 6.1

What are suitable references for the "me" and "mola-vik-1" geoedtic
systems?  I do not see how just the listed descriptions provide a "clear
definition" even for the two coordinate values latitude/longitude.

Section 7

Thanks for using the template for security considerations for YANG
models!  I think that since some of the portions of the template do not
apply, they can safely be removed.  In particular, the "these are the
subtrees and data nodes and their sensitivity/vulnerability" lines can
go, and the clause about "can have a negative effect on network
operations" may be worth tweaking (network operations may not be the
most likely thing to be impacted).  I think it's also okay to drop the
paragraph/sentence about RPCs.

Section 8

The [WGS84] and [EGM08] links don't work for me.  ([EGM96] does.)

Section 9

It seems like RFC 7950 is more properly classified as normative, since
you can't really make sense of YANG without ... knowing YANG.  I think
8340 is sometimes listed as normative as well, but the case is not quite
as clear, here.

NITS

Abstract

   This document defines a generic geographical location object YANG
   grouping.  [...]

I'm having a hard time seeing what role the word "object" is playing
here, especially since in the next sentence we just refer to the
"geographical location grouping".

Section 3

         description
           "A location on an astronomical body (e.g., 'earth')
            somewhere in a universe.";

I guess in some alternate-systems the "astronomical body" bit may not
really be accurate.  (And possibly in some cartesian coordinate frames,
too, but that's less clear.)

             type string {
               pattern '[ -@\[-\^_-~]*';

If I'm reading my table correctly, '^' and '_' are adjacent, so this
rather-reader-unfriendly regex formulation can't even be justified as
the minimal encoding.

                '67p/churyumov-gerasimenko (a comet). The value should
                be comprised of all lower case ASCII characters not
                including control characters (i.e., values 32..64, and
                91..126).  [...]

"all lower case ASCII characters" inherently excludes control
characters, so "all lower case ASCII characters not including control
characters" is redundant.
Also, that doesn't match up the listed range of values (or the regex).
(Also^2, that doesn't match the given comet name, which has numbers and
punctuation.)

                  for Cartesian coordinates. When coord-accuracy is
                  specified, it overrides the geodetic-datum implied
                  accuracy.";
                  [...]
                 "The accuracy of height value for ellipsoidal
                  coordinates, this value is not used with Cartesian
                  coordinates. When specified, it overrides the
                  geodetic-datum implied default.";

I suggest using parallel language for "when specified, overrides implied
default".  (That is, "coord-accuracy" is currently explicitly named but
"height-accuracy" is not.)

           leaf v-up {
             type decimal64 {
               fraction-digits 12;
             }
             units "meters per second";
             description
               "v-up is the rate of change (i.e., speed) away from the
                center of mass.";

"center of mass" may not be universally applicable, e.g., to cartesian
coordinates, binary systems, extremely massive objects that are not the
astronomical-body of the reference-frame.

Section 4

We probably should expand CRS at/before first usage.

Section 6.1

   Each entry should be sufficient to define the 3 coordinate values (2
   if height is not required).  So for example the "wgs-84" is defined

I'd suggest flipping the order, for "should be sufficient to define the
2 coordinate values, and to define height if height is required".

(2.2) "For the standard location choice latitude and longitude are specified as fractions of decimal degrees, and the height value is in fractions of meters."

What are "fractions of decimal degrees"? Is it not better to just say "decimal degrees" and "decimal meters"?