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

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 16 Jul 2021 10:53:51 +0000

Hi Ben, Chris,

I wanted to check whether this discussion has progressed at all.  This is the only remaining discuss after Roman has cleared his based on the IESG telechat discussion yesterday (thanks Roman).

Regards,
Rob

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Christian Hopps
> Sent: 26 May 2021 23:05
> To: Benjamin Kaduk <[email-masked]>
> Cc: [email-masked]; The IESG <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-
> location-08: (with DISCUSS and COMMENT)
> 
> 
> Benjamin Kaduk via Datatracker <[email-masked]> writes:
> 
> > 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?
> 
> 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.
> 
> > ----------------------------------------------------------------------
> > 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/dA9olZfEVa3clGdfvNYEFXUE
> MJw/
> > that attempted to discuss the feedback from the yangdoctor review -- the
> > mail with the review itself got no direct replies.
> 
> 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.
> 
> > 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.
> 
> Ok changed to "overriding".
> 
> 
> >    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.
> 
> 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.
> 
> > 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)?
> 
> The thinking is to allow users to do more than what we IANA is limited to.
> 
> > 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.)
> 
> I've removed the links as they are not stable. Just going with standard title,
> author pub date now.
> 
> > 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".
> 
> Removed "object"
> 
> > 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.
> 
> This has to do with working with limitations in the tools. The minimal
> encoding does not work unfortunately.
> 
> >                 '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.)
> 
> 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.";
> 
> >                   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.)
> 
> Done.
> 
> >
> >            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.
> 
> 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.
> 
> > Section 4
> >
> > We probably should expand CRS at/before first usage.
> 
> Done, just under the table.
> 
> > 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".
> 
> Done.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 17 Jul 2021 10:33:21 -0700

Hi Christian,

Sorry for the very delayed reply (and thanks to Rob for the nudge).

On Wed, May 26, 2021 at 06:04:58PM -0400, Christian Hopps wrote:
> 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.

Unfortunately, even your description here still doesn't help me understand
what the intended semantics of these values are.

To help illustrate my confusion, here are a few possible things that could
be what is intended to be conveyed:

- the geodetic-datum description of the object has been measured to be
  within a known delta of the actual object being described, at all points
  on the object that the coordinate system can describe

- the geodetic-datum description of the object is capable of determining
  relative differences between points on the object to within a particular
  delta of precision, but those individual coordinate values may be farther
  than that delta from the actual point on the object that was referred to

- the values that are reported in this YANG module reflect measurements
  that were made and are known to be within some delta of the coordinate
  system's value that they are reported as

- the values that are reported in this YANG module reflect measurements
  thare are known to be distinguishable from other measurements to within
  some delta of other measurements relative to that coordinate system, even
  though the actual position being indicated may diverge from the reported
  value by more than that delta

- the values that are reported in this YANG module reflect measurements
  that were made and are known to be within some delta of the actual point
  on the object that the coordinates refer to

- the values that are reported in this YANG module reflect measurements
  that were and are known to be distinguishable from other measurements of
  points on that object within some delta, but the actual distance from the
  measured point to the point on the object indicated by the reported
  coordinates may be larger than that delta

In short, there are at least three classes of things at play here: the
actual object itself, the coordinate system used to model the object, and
values reported in the YANG module (which are assumed to ultimately derive
from some form of measurement).  To talk about accuracy or precision
implies a relationship between elements of two of those classes, and I
don't even know which of those classes you're trying to talk about.

> > https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUEMJw/
> 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.

Sure, that's most of why this is in the non-blocking COMMENT section.

The rest of this (including the follow-up) all looks fine; thanks for the
replies and updates!

-Ben

> 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.
> 
> > Section 2.3
> >
> I've removed the links as they are not stable. Just going with standard title, author pub date now.
> 
> > Section 9
> >
> This has to do with working with limitations in the tools. The minimal encoding does not work unfortunately.
> 
> "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.";
> 
> 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.
> 
> > Section 4
> >

---

From: Christian Hopps <[email-masked]>
Date: Sat, 17 Jul 2021 14:38:55 -0400

Benjamin Kaduk <[email-masked]> writes:

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

Let's start with a simple baseline, if you want to dig any deeper than the well understood Lat+Long; do you know what a geodetic datum is? This is required knowledge if you want to get into anything more than the obvious Lat+Long use of this grouping. It defines the coordinates and also the accuracy of measurements.

It is out way out of scope for this YANG grouping to try and explain the huge field of geographic locations and geodetic datum and systems.

Thanks,
Chris.

>> 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.
>>
>> > Section 4
>> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 17 Jul 2021 15:14:18 -0700

> Let's start with a simple baseline, if you want to dig any deeper than the well understood Lat+Long; do you know what a geodetic datum is? This is required knowledge if you want to get into anythin…

Well, I thought I did, but the fact that you are asking me makes me less
sure that I actually do.

Limiting just to the Earth for simplicity of discussion, it is "well known"
that the earth is not a perfect sphere; it's not even a regular ellipsoid.
Even discounting local topography on the surface, "mean sea level" varies
due to the differing internal density, angular momentum, and myriad other
factors.  So if we want to talk about coordinates of a point on the earth,
we have to build a model of the earth in which we define what our
coordinates mean.  We'll have to anchor our coordinate system to actual
points on the earth in some way, whether by defining an arbitrary origin at
a physical object, using the center of mass (which can at least in theory
be measured to very high precision), or some combination thereof.  But the
coordinate system remains a model of the actual earth, and there will be
some skew between them for points that in an ideal coordinate system would
match up exactly with the physical object.

The coordinate system will have inherent accuracy limits based on how much
skew there is between the idealized points in the coordinate system and the
actual points on earth they're supposed to represent.  When one makes a
measurement with respect to a given coordinate system there may also be
inherent limits to the precision of measurement that can be made with
respect to the coordinate system, e.g., if the coordinate system is defined
with respect to GPS points, the limits of GPS resolution are a bound on how
precisely one can make a measurement.

That's all well and good, but what I describe above is a property of the
coordinate system itself, not a property of individual measurements made
with reference to that coordinate system.  The YANG grouping we define here
allows overriding the coord-accuracy and height-accuracy on a
per-grouping-instantiation basis, i.e., for a single list of coordinates.
But those coordinates in the instantiation are certainly sometimes going to
be derived from measurements, and I expect that measurements will be the
overwhelming majority of usage.  Measurements, however, *also* have
accuracy and precision, but this time with respect to the coordinate system
they are being measured in.  Instrumental error and other factors can
introduce a systemtic bias in the measured values, leading to bad accuracy,
even if the precision of the group of measurements remains quite good, so
that relative comparisons within the dataset are reliable even if the
absolute numers are not reliable with respect to the coordinate system.

So, when we refine the coord-accuracy and height-accuracy for an
instantiation of the grouping, what does that mean?

> It is out way out of scope for this YANG grouping to try and explain the huge field of geographic locations and geodetic datum and systems.

Of course.  But we should have enough of a reference so that people can
have a way to read up and understand what the fields we are defining
actually mean.

-Ben

---

From: Christian Hopps <[email-masked]>
Date: Sat, 17 Jul 2021 19:17:09 -0400

> On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

It’s supposed to mean the accuracy of the measurement that is recorded in the grouping. So if the coord-accuracy is .1 and the measurement is lat/long then the accuracy is within 1/10 of a decimal degree. if the measurement is in cart coordinates the accuracy would be 100cm. I don’t think we need to make this anymore complex than that. Is there some text you would like to see to make that clearer?

Thanks,
Chris.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 17 Jul 2021 16:24:56 -0700

> It’s supposed to mean the accuracy of the measurement that is recorded in the grouping. So if the coord-accuracy is .1 and the measurement is lat/long then the accuracy is within 1/10 of a decimal…

The accuracy of the measurement with respect to what?  The coordinate
system, or the actual physical object?

And, if the concept here is that "I made a measurement, and my measurement
device reported a value to 1/10 of a decimal degree", that would typically
correspond to a "precision" rather than an "accuracy"
(https://en.wikipedia.org/wiki/Accuracy_and_precision).

In either case, I think that "accuracy of the measurement recorded in the
grouping" is a qualitatively different concept of "accuracy" than the
listed accuracy of the geodetic-datum, which (AIUI) relates to the maximum
deviation between the model of the object used by the coordinate system and
the actual physical object.  So it's not really clear that we should be
talking the one "overriding" the other.

-Ben

---

From: Christian Hopps <[email-masked]>
Date: Mon, 19 Jul 2021 12:12:09 -0400

> On Jul 17, 2021, at 7:24 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

I really don’t see how this could be so confusing.

This grouping is a location, the accuracy applies to the contained location data. Consider asking this question about some other field like the lat/long — it doesn’t make sense.

I can’t say for sure, but I think you’ve discarded the obvious here and are getting pedantic about something that’s not actually confusing.

Finally, as we (the IETF) are not geo location experts, we had this grouping reviewed by actual industry experts (thanked in the acknowledgment section) and they had no issue with these fields. I would be very hesitant to change what they reviewed as correct at this point based on pedantic musings.

Thanks,
Chris.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Jul 2021 09:46:32 -0700

> This grouping is a location, the accuracy applies to the contained location data. Consider asking this question about some other field like the lat/long — it doesn’t make sense.

It's confusing because there's a type mismatch between what the actual
words on the page say and what you're describing in the email thread.

> Finally, as we (the IETF) are not geo location experts, we had this grouping reviewed by actual industry experts (thanked in the acknowledgment section) and they had no issue with these fields. I w…

I'm confident that the actual fields in the model can provide the needed
information.  We just need to clearly describe what information they are
conveying.

So, if we look at the

OLD:

             leaf geodetic-datum {
               type string {
                 pattern '[ -@\[-\^_-~]*';
               }
               description
                 "A geodetic-datum defining the meaning of latitude,
                  longitude and height. The default when the
                  astronomical body is 'earth' is 'wgs-84' which is
                  used by the Global Positioning System (GPS). The
                  ASCII value SHOULD have upper case converted to lower
                  case and not include control characters (i.e., values
                  32..64, and 91..126). The IANA registry further
                  restricts the value by converting all spaces (' ') to
                  dashes ('-')";
   [...]
             leaf coord-accuracy {
               type decimal64 {
                 fraction-digits 6;
               }
               description
                 "The accuracy of the latitude longitude pair for
                  ellipsoidal coordinates, or the X, Y and Z components
                  for Cartesian coordinates. When coord-accuracy is
                  specified, it overrides the geodetic-datum implied
                  accuracy.";
             }

this is indicating that the geodetic datum has some intrinsic default for
accuracy of latitude/longitude (not quoted, there is also some default for
height accuracy intrinsic to the geodetic datum).

If I were holding the pen, I might consider things like the following

NEW1:
             leaf geodetic-datum {
               type string {
                 pattern '[ -@\[-\^_-~]*';
               }
               description
                 "A geodetic-datum defining the meaning of latitude,
                  longitude and height. The default when the
                  astronomical body is 'earth' is 'wgs-84' which is
                  used by the Global Positioning System (GPS). The
                  ASCII value SHOULD have upper case converted to lower
                  case and not include control characters (i.e., values
                  32..64, and 91..126). The IANA registry further
                  restricts the value by converting all spaces (' ') to
                  dashes ('-')";
                  The specification for the geodetic-datum indicates
		  how accurately it models the astronomical body in
		  question, both for the "horizontal" latitude/longitude
		  coordinates and for height coordinates, typically as a
		  maximum deviation across the entire astronomical object.

NEW2:
             leaf coord-accuracy {
               type decimal64 {
                 fraction-digits 6;
               }
               description
                 "The accuracy of the latitude longitude pair for
                  ellipsoidal coordinates, or the X, Y and Z components
                  for Cartesian coordinates. When coord-accuracy is
                  specified, it overrides the geodetic-datum implied
                  accuracy.  This might be used, for example, when the
		  particular coordinates in the sibling list of locations
		  are all located in a region of the astronomical object
		  where the model used by the geodetic-datum is a
		  particularly good representation of the actual
		  astronomical object";
             }

NEW3:
             leaf coord-accuracy {
               type decimal64 {
                 fraction-digits 6;
               }
               description
                 "The accuracy of the latitude longitude pair for
                  ellipsoidal coordinates, or the X, Y and Z components
                  for Cartesian coordinates. When coord-accuracy is
                  specified, it indiates how precisely the coordinates in
		  the associated list of locations have been determined
		  with respect to the coordinate system defined by the
		  geodetic-datum.  For example, this might be uncertainty
		  due to measurement error if an experimental measurement
		  was made to determine each location.";
             }

In particular, what the actual words on the page are currently telling me
is what I think NEW2 says -- to "override" (or "refine") a given value
inherently must be of the same type as that value.  What you've told me in
this email thread is more like NEW3, and if the NEW3 sense is intended,
then we shouldn't use the word "override".

-Ben