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

[Benjamin Kaduk <[e-mail]>]

On Mon, Jul 19, 2021 at 12:12:09PM -0400, Christian Hopps wrote:
> 
> 
> > On Jul 17, 2021, at 7:24 PM, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > On Sat, Jul 17, 2021 at 07:17:09PM -0400, Christian Hopps wrote:
> >> 
> >> 
> >>> On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk <[e-mail]> wrote:
> >>> 
> >>> So, when we refine the coord-accuracy and height-accuracy for an
> >>> instantiation of the grouping, what does that mean?
> >> 
> >> 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?
> > 
> > The accuracy of the measurement with respect to what?  The coordinate
> > system, or the actual physical object?
> 
> 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.

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.

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

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