Francesca Palombini via Datatracker <[email protected]> writes:
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.
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?
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?
I removed the URLs -- obviously they are not stable. So we can proceed with the normal document title, author, and publication date.
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.
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.
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
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.
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
