Hi, this ballot position does not block this document from moving forward.
Thanks, Lars > On 2021-6-22, at 15:02, Christian Hopps <[email protected]> wrote: > > > Lars Eggert via Datatracker <[email protected]> writes: > >> Lars Eggert has entered the following ballot position for >> draft-ietf-netmod-geo-location-10: Abstain >> >> 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: >> ---------------------------------------------------------------------- >> >> I disagree with the approach taken to deal with unstable URLs used in -08 >> for various normative references (e.g., [EGM08] , [EGM96]), which was to >> remove the URLs and leave future implementers hoping they can track down >> the correct spec manually. > > So you really think someone who cares to the detail level of a > sub-specifications of the WGS-84 geodesic standard only has a "hope" of > finding said sub-specification? This YANG grouping isn't supposed to be > teaching people about geodesic data, they are expected to know that. > > Keeping that in mind, I think inserting best-guess URLs that have already > been shown to be ephemeral, may be inferior to the expected readers own > knowledge, in a standards document reference, seems a rather poor choice. > > If there is no give here, I of course will give up and put some reference > back in, so the thing can progress. > >> --- >> >> Section 2.3, paragraph 2, comment: >>> 3-dimensional vector value. The components of the vector are >>> "v-north", "v-east" and "v-up" which are all given in fractional >> >> In the formulas in the text rendering of the document, these components are >> called "v_{north}", etc. It would be good to use a single variant in both the >> text and any formulas. >> >> This document uses RFC2119 keywords, but does not contain the recommended >> RFC8174 boilerplate. (It contains some text with a similar beginning.) > > Document text: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119] [RFC8174] when, and only when, they appear in all capitals, > as shown here. > > > Boilerplate from RFC8174: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP 14 > [RFC2119] [RFC8174] when, and only when, they appear in all capitals, > as shown here. > > "It contains some text with a similar beginning" might be the worst one can > make the above difference sound w/o actually being un-factual. I will add the > missing 2 words. > > Thanks, > Chris. > >> >> ------------------------------------------------------------------------------- >> All comments below are about very minor potential issues that you may choose >> to >> address in some way - or ignore - as you see fit. Some were flagged by >> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there >> will likely be some false positives. There is no need to let me know what you >> did with these suggestions. >> >> Section 1, paragraph 2, nit: >> - might be the location of data center, a rack in an internet exchange >> - ^ >> + might be the location of data center, a rack in an Internet exchange >> + ^ >> >> Section 2.5, paragraph 1, nit: >>> development of this module, the question of whether it would support data su >>> ^^^^^^^^^^^^^^^^^^^^^^^ >> Wordiness: Consider shortening this phrase. >> >> Section 3, paragraph 17, nit: >>> describes this motion at the the time given by the timestamp. For a >>> ^^^^^^^ >> Maybe you need to remove one determiner so that only "the" or "the" is left. >> >> Section 4, paragraph 4, nit: >>> lts For test "A.1.2.1" the YANG geo location object either includes a CRS >>> ("r >>> ^^^^^^^^^^^^ >> This word is normally spelled as one. >> >> Section 5.1.4, paragraph 4, nit: >>> value, the YANG grouping supports the ignore case but not the relative case. >>> ^^^^^^^^^^ >> After 'the', do not use a verb. Make sure that the spelling of 'ignore' is >> correct. If 'ignore' is the first word in a compound adjective, use a hyphen >> between the two words. Note: This error message can occur if you use a verb >> as >> a noun, and the word is not a noun in standard English. >> >> Section 7, paragraph 6, nit: >>> e than standard configuration. Some of the readable data nodes in this YANG >>> m >>> ^^^^^^^^^^^ >> If the text is a generality, 'of the' is not necessary. >> >> "Appendix A.", paragraph 3, nit: >>> ure 2: Example YANG module using geo location. Below is the YANG tree for >>> the >>> ^^^^^^^^^^^^ >> This word is normally spelled as one. >> >> "Appendix A.", paragraph 7, nit: >>> Figure 3: Example XML data of geo location use. Appendix B. Acknowledgments >>> ^^^^^^^^^^^^ >> This word is normally spelled as one. >> >> These URLs in the document did not return content: >> * http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html >> * http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf >> * https://www.rfc-editor.org/info/rfcXXXX >> >> These URLs in the document can probably be converted to HTTPS: >> * http://www.iau.org >> * http://docs.opengeospatial.org/is/12-007r2/12-007r2.html >> * http://portal.opengeospatial.org/files/?artifact_id=27810
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
