Subject: [netmod] Lars Eggert's Abstain on draft-ietf-netmod-geo-location-10: (with COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Tue, 22 Jun 2021 04:02:19 -0700

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.

---

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.)

-------------------------------------------------------------------------------
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

---

From: Christian Hopps <[email-masked]>
Date: Tue, 22 Jun 2021 08:02:02 -0400

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

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.

> 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.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 22 Jun 2021 15:25:48 +0300

Hi,

this ballot position does not block this document from moving forward.

Thanks,
Lars

> On 2021-6-22, at 15:02, Christian Hopps <[email-masked]> wrote:
> 
>