Subject: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 19 May 2021 16:33:52 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-geo-location-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think we lack sufficient precision (forgive the pun) in how we talk
about "accuracy" and "precision".  Are the leafs that claim to specify
"accuracy" specifying a precision?  If so, the precision of a specific
measurement, the precision of the measurements that led to the creation
of the coordinate frame, or something else?  Are they doing so in
relative terms (e.g., percentage) or absolute terms (e.g., degrees and
meters)?  (There are "units" directives only for "height-accuracy" and
not the others.)  How can we we say that we'll have 16 fraction-digits of
precision for lat/long when the maximum accuracy we can say that a
geodetic-system has only gives us 6 fraction-digits for coord-accuracy?
When we say that the "precision of this measurement is indicated by the
reference-frame" is that the same thing as the relevant "-accuracy"
nodes, or something else?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(I support Roman's Discuss.)

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".

---

From: Christian Hopps <[email-masked]>
Date: Wed, 26 May 2021 18:04:58 -0400

> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/

Yes, the geodesic-datum is what defines the values and their accuracy. For the precision in the value we choose the fractional digits based on what might be needed, but not to prescribe anything. For decimal degrees e.g., we only need 100s values the rest can be left to the fractional portion.

This is a very edge case of this grouping meant really to handle something like continental drift with long stored values. One can keep drilling down on this particular velocity value seemingly forever, but then we aren't getting our work done. I think it's enough to say that if the usable values don't work for a use case at this point, then they don't work.

> different word here might be appropriate.

Ok changed to "overriding".

> YANG module at this time.

It doesn't hurt anything to include it and it was asked for by the person who came up with the shape of this grouping (Peter L.). Unless there's a strong objection I'd prefer to leave it in deference to the person who asked for it.

> obviate the need for special processing at IANA)?

The thinking is to allow users to do more than what we IANA is limited to.

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

I've removed the links as they are not stable. Just going with standard title, author pub date now.

> "geographical location grouping".

Removed "object"

> rather-reader-unfriendly regex formulation can't even be justified as

This has to do with working with limitations in the tools. The minimal encoding does not work unfortunately.

>                 including control characters (i.e., values 32..64, and

Changed to:

"The ASCII value SHOULD have upper case converted to lower case characters and not include control characters (i.e., values 32..64, and 91..126). Any preceding 'the' in the name SHOULD NOT be included.";

> "height-accuracy" is not.)

Done.

> astronomical-body of the reference-frame.

In this case the value is not relevant. Again, this isn't a big part of this specification, it's meant to track things like continental drift. If it's not useful as defined then it's simply not useful for that use.

> We probably should expand CRS at/before first usage.

Done, just under the table.

> 2 coordinate values, and to define height if height is required".

Done.

---

From: Christian Hopps <[email-masked]>
Date: Wed, 26 May 2021 18:56:29 -0400

Sorry missed a couple in previous reply.

>> W3C structure/API, but I don't see one listed in Figure 1.

Yes, there was even a blank line where it originally was, na errant D or something in vi. :)

I've put it back.

>> definition" even for the two coordinate values latitude/longitude.

I've included a reference for 'me', and removed mola-vik-1 b/c it was simply too hard to find a good reference for it.

>> paragraph/sentence about RPCs.

Updated.