Subject: [netmod] John Scudder's No Objection on draft-ietf-netmod-geo-location-08: (with COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 08:31:09 -0700

John Scudder has entered the following ballot position for
draft-ietf-netmod-geo-location-08: No Objection

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/

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

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

---

From: Christian Hopps <[email-masked]>
Date: Wed, 26 May 2021 17:44:43 -0400

> reviewed (kudos!),  but there are still a few.

I believe I have benefited by being an early tester for Rob Wilton's automated grammar checker. :)

I've fixed the remaining nits.

Thanks,
Chris.