Hi Chris, Thank you, I cleared my discuss.
Francesca On 17/06/2021, 09:52, "Christian Hopps" <[email protected]> wrote: Francesca Palombini <[email protected]> writes: > Hi Chris, > > Inline. I've posted a new version with the updated IANA registry changes. https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/10/ Thanks, Chris. > > Thanks, > Francesca > > On 27/05/2021, 00:04, "Christian Hopps" <[email protected]> wrote: > > > Francesca Palombini via Datatracker <[email protected]> writes: > > > Francesca Palombini has entered the following ballot position for > > draft-ietf-netmod-geo-location-08: Discuss > > > > > > > ---------------------------------------------------------------------- > > 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? > > FP: For the value you register in this document, I think it would make sense to have the reference to this document. For change controller, it is quite common to have IESG. That would mean two changes: > - add 2 columns: "Reference" and "Change control" to table 3, where Reference is > [This document] and Change control is IESG, for all rows. (You don't need to add > one column for contact person, I have noticed it is quite common for IANA > registry to use that same Reference column to point either to a standard or to a > contact person) > - add a sentence stating that "Reference" can point to the document doing the registration or the contact person, as defined by RFC 8126. > > > 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. > > > > FP: This was discussed during the telechat and is resolved, so as soon as we agree on point 1. I will remove my DISCUSS. > > > > > ---------------------------------------------------------------------- > > 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://protect2.fireeye.com/v1/url?k=8c4dc9b7-d3d6f09a-8c4d892c-8692dc8284cb-c0df19b629553d9e&q=1&e=7e44c916-ff47-4dae-b193-a89283c49472&u=https%3A%2F%2Fgis-lab.info%2Fdocs%2Fnima-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. > > FP: I see that there was discussion with Lars about it, so I will leave it up to you and Rob to decide the best way forward. However I do agree with Lars (and quoting him) that: > ".. since you'd want those references to be easily and unambiguously findable by readers/implementers, including them is usually very helpful, especially for normative references, which are basically required reading." So my preference would be to keep the URI to the most stable possible link. > > > 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. > > FP: No I don't feel strongly about this, and as you say that is defined in the YANG grouping. It's fine keeping it this way, thanks for the answer. > > > 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://protect2.fireeye.com/v1/url?k=815a5923-dec1600e-815a19b8-8692dc8284cb-37bc0f18508bb22e&q=1&e=7e44c916-ff47-4dae-b193-a89283c49472&u=https%3A%2F%2Fwww.iau.org%2Fpublic%2Fthemes%2Fnaming_stars%2F . 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. > > FP: I see that Roman has the same comment as me in his DISCUSS, I'll let you and Rob solve with him. The point is that without a clear reference, the description of "An astronomical body as named by the International Astronomical Union (IAU) " becomes hard to enforce. > > Thanks, > Chris. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
