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

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Wed, 19 May 2021 05:13:33 -0700

Francesca Palombini 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:
----------------------------------------------------------------------

Thank you for the work on this document, and thank you to the shepherd for a
very well-written shepherd write up.

I have a couple of DISCUSS points related to the IANA section, and some non
blocking question.

Francesca

1. -----

   The allocation policy for this registry is First Come, First Served,
   [RFC8126] as the intent is simply to avoid duplicate values.

FP: RFC 8126 specifies:

   When creating a new registry with First Come First Served as the
   registration policy, in addition to the contact person field or
   reference, the registry should contain a field for change controller.
   Having a change controller for each entry for these types of
   registrations makes authorization of future modifications more clear.
   See Section 2.3.

The current registry dos not contain contact person, nor reference, nor change
controller fields.

2. -----

   It should be noted that [RFC5870] also creates a registry for
   Geodetic Systems (it calls CRS); however, this registry has a very
   strict modification policy.  The authors of [RFC5870] have the stated
   goal of making CRS registration hard to avoid proliferation of CRS
   values.  As our module defines alternate systems and has a broader
   (beyond Earth) scope, the registry defined below is meant to be more
   easily modified.

FP: Thanks for bringing this up - I want to confirm that we need this registry,
and that we are not creating a way to bypass the CRS registration policies by
providing a different registry with a more lenient policy.

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

3. -----

   [WGS84]    National Imagery and Mapping Agency., "National Imagery
              and Mapping Agency Technical Report 8350.2, Third
              Edition.", 3 January 2000, <http://earth-
              info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>.

FP: I support Lars DISCUSS, and add the following normative reference to the
list - link is broken. A quick google search found this:
https://gis-lab.info/docs/nima-tr8350.2-wgs84fin.pdf , which I assume is the
wanted reference... but I don't think that we should be relying on informal
communities to maintain normative references to our documents, can we do better?

4. -----

   choice "latitude" and "longitude" are specified as fractions of
   decimal degrees, and the "height" value is in fractions of meters.
   For the Cartesian choice "x", "y" and "z" are in fractions of meters.

FP: I have the feeling that the document is specifying both numeric data
expected and unit at the same time "fraction of _insert unit_". For the sake of
clarity, I think it would be best to split this up, so change the "fraction of
meters" to "meters, expressed in floating point". TODO: check that format is
defined.

5. -----

FP: After looking for a while: does a stable reference exist for the list of
astronomical bodies and their name (rather than just saying it is maintained by
IAU)? I only found the following for stars:
https://www.iau.org/public/themes/naming_stars/ . I also found the page for the
corresponding WG, which defined the guidelines for naming stars. I was
wondering if there is a reference to these guidelines for all astronomical
bodies. What I am especially concerned about is that I was not able to verify
that we will not incur on encoding problems, if IAU changes their naming
conventions, given the following text in the document:

                '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). Any preceding 'the' in the name should not be

---

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

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

I honestly have no idea what to put in that field for the referenced standards. Certainly we can't just point people at the defining standards or people who wrote them as they have no reason to pay attention to our YANG groupings IANA registry. Should I put myself, or the NETMOD working group perhaps?

> providing a different registry with a more lenient policy.

I removed the URLs -- obviously they are not stable. So we can proceed with the normal document title, author, and publication date.

> meters" to "meters, expressed in floating point". TODO: check that format is

It is specifying units and their format, I felt this was simply concise, but not confusing. Do you feel strongly about this? FWIW we use YANG decimal64 not floating point in the YANG grouping.

>                 91..126). Any preceding 'the' in the name should not be

No I don't have a stable reference. It was very hard to track all of what I have, down. The best I could do was just point at the IAU.

Thanks,
Chris.