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”. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
