A YANG Grouping for Geographic Locations
draft-ietf-netmod-geo-location-11

[Ballot comment]
Thank you for addressing my Discuss point!
For reference, my original comments from the -08 appear unchanged below.


Why do we only define velocity in terms of north/east/up, when we could
be in x/y/z coordinates where there is no clear "north" or "east"?

It would have been helpful for the shepherd review to point to the
thread at
https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUEMJw/
that attempted to discuss the feedback from the yangdoctor review -- the
mail with the review itself got no direct replies.

Section 2.1

  In addition to the "geodetic-datum" value, we allow refining the
  coordinate and height accuracy using "coord-accuracy" and "height-

My understanding is that "refine" is a YANG keyword, and the current
module/tree structure does not seem consistent with this description
referring to use of the YANG keyword (since we can just set new values
directly without needing to "refine" the YANG structure itself).  A
different word here might be appropriate.

  Finally, we define an optional feature which allows for changing the
  system for which the above values are defined.  This optional feature
  adds an "alternate-system" value to the reference frame.  This value
  is normally not present which implies the natural universe is the
  system.  The use of this value is intended to allow for creating
  virtual realities or perhaps alternate coordinate systems.  The
  definition of alternate systems is outside the scope of this
  document.

This paragraph doesn't really convince me that we need to include the
"alternate-system" capability in the proposed-standard version of this
YANG module at this time.

Section 2.3

  meters per second.  The values "v-north" and "v-east" are relative to
  true north as defined by the reference frame for the astronomical
  body, "v-up" is perpendicular to the plane defined by "v-north" and
  "v-east", and is pointed away from the center of mass.

When I read this I wondered if the "plane defined by v-north and v-east"
was taken at the initial snapshot position, or continuously updated with
the effect of v-north and v-east drift.  Given the stated application,
it's unlikely that it actually would matter, though, so it's not clear
that we should change the text to cover it.

Section 3

                  and 91..126). The IANA registry further restricts the
                  value by converting all spaces (' ') to dashes ('-')";

Is there a reason why we shouldn't disallow spaces via the regex (and
obviate the need for special processing at IANA)?

Section 5.1.2

The following subsection suggests that there is a "heading" field in the
W3C structure/API, but I don't see one listed in Figure 1.

Section 6.1

What are suitable references for the "me" and "mola-vik-1" geoedtic
systems?  I do not see how just the listed descriptions provide a "clear
definition" even for the two coordinate values latitude/longitude.

Section 7

Thanks for using the template for security considerations for YANG
models!  I think that since some of the portions of the template do not
apply, they can safely be removed.  In particular, the "these are the
subtrees and data nodes and their sensitivity/vulnerability" lines can
go, and the clause about "can have a negative effect on network
operations" may be worth tweaking (network operations may not be the
most likely thing to be impacted).  I think it's also okay to drop the
paragraph/sentence about RPCs.

Section 8

The [WGS84] and [EGM08] links don't work for me.  ([EGM96] does.)

Section 9

It seems like RFC 7950 is more properly classified as normative, since
you can't really make sense of YANG without ... knowing YANG.  I think
8340 is sometimes listed as normative as well, but the case is not quite
as clear, here.

NITS

Abstract

  This document defines a generic geographical location object YANG
  grouping.  [...]

I'm having a hard time seeing what role the word "object" is playing
here, especially since in the next sentence we just refer to the
"geographical location grouping".

Section 3

        description
          "A location on an astronomical body (e.g., 'earth')
            somewhere in a universe.";

I guess in some alternate-systems the "astronomical body" bit may not
really be accurate.  (And possibly in some cartesian coordinate frames,
too, but that's less clear.)

            type string {
              pattern '[ -@\[-\^_-~]*';

If I'm reading my table correctly, '^' and '_' are adjacent, so this
rather-reader-unfriendly regex formulation can't even be justified as
the minimal encoding.

                '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).  [...]

"all lower case ASCII characters" inherently excludes control
characters, so "all lower case ASCII characters not including control
characters" is redundant.
Also, that doesn't match up the listed range of values (or the regex).
(Also^2, that doesn't match the given comet name, which has numbers and
punctuation.)

                  for Cartesian coordinates. When coord-accuracy is
                  specified, it overrides the geodetic-datum implied
                  accuracy.";
                  [...]
                "The accuracy of height value for ellipsoidal
                  coordinates, this value is not used with Cartesian
                  coordinates. When specified, it overrides the
                  geodetic-datum implied default.";

I suggest using parallel language for "when specified, overrides implied
default".  (That is, "coord-accuracy" is currently explicitly named but
"height-accuracy" is not.)

          leaf v-up {
            type decimal64 {
              fraction-digits 12;
            }
            units "meters per second";
            description
              "v-up is the rate of change (i.e., speed) away from the
                center of mass.";

"center of mass" may not be universally applicable, e.g., to cartesian
coordinates, binary systems, extremely massive objects that are not the
astronomical-body of the reference-frame.

Section 4

We probably should expand CRS at/before first usage.

Section 6.1

  Each entry should be sufficient to define the 3 coordinate values (2
  if height is not required).  So for example the "wgs-84" is defined

I'd suggest flipping the order, for "should be sufficient to define the
2 coordinate values, and to define height if height is required".

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

[Ballot comment]
I support Lars' and Francesca's DISCUSS positions.

The shepherd writeup says: "There are no known implementations known to the Shepherd.  No vendors have indicated their plan to implement the specification.  It was originally forwarded to support DT's Terra Stream project."  I'm tempted to ask why this is slotted for Standards Track publication.

[Ballot discuss]
I think we lack sufficient precision (forgive the pun) in how we talk
about "accuracy" and "precision".  Are the leafs that claim to specify
"accuracy" specifying a precision?  If so, the precision of a specific
measurement, the precision of the measurements that led to the creation
of the coordinate frame, or something else?  Are they doing so in
relative terms (e.g., percentage) or absolute terms (e.g., degrees and
meters)?  (There are "units" directives only for "height-accuracy" and
not the others.)  How can we we say that we'll have 16 fraction-digits of
precision for lat/long when the maximum accuracy we can say that a
geodetic-system has only gives us 6 fraction-digits for coord-accuracy?
When we say that the "precision of this measurement is indicated by the
reference-frame" is that the same thing as the relevant "-accuracy"
nodes, or something else?

[Ballot comment]
(I support Roman's Discuss.)

Why do we only define velocity in terms of north/east/up, when we could
be in x/y/z coordinates where there is no clear "north" or "east"?

It would have been helpful for the shepherd review to point to the
thread at
https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUEMJw/
that attempted to discuss the feedback from the yangdoctor review -- the
mail with the review itself got no direct replies.

Section 2.1

  In addition to the "geodetic-datum" value, we allow refining the
  coordinate and height accuracy using "coord-accuracy" and "height-

My understanding is that "refine" is a YANG keyword, and the current
module/tree structure does not seem consistent with this description
referring to use of the YANG keyword (since we can just set new values
directly without needing to "refine" the YANG structure itself).  A
different word here might be appropriate.

  Finally, we define an optional feature which allows for changing the
  system for which the above values are defined.  This optional feature
  adds an "alternate-system" value to the reference frame.  This value
  is normally not present which implies the natural universe is the
  system.  The use of this value is intended to allow for creating
  virtual realities or perhaps alternate coordinate systems.  The
  definition of alternate systems is outside the scope of this
  document.

This paragraph doesn't really convince me that we need to include the
"alternate-system" capability in the proposed-standard version of this
YANG module at this time.

Section 2.3

  meters per second.  The values "v-north" and "v-east" are relative to
  true north as defined by the reference frame for the astronomical
  body, "v-up" is perpendicular to the plane defined by "v-north" and
  "v-east", and is pointed away from the center of mass.

When I read this I wondered if the "plane defined by v-north and v-east"
was taken at the initial snapshot position, or continuously updated with
the effect of v-north and v-east drift.  Given the stated application,
it's unlikely that it actually would matter, though, so it's not clear
that we should change the text to cover it.

Section 3

                  and 91..126). The IANA registry further restricts the
                  value by converting all spaces (' ') to dashes ('-')";

Is there a reason why we shouldn't disallow spaces via the regex (and
obviate the need for special processing at IANA)?

Section 5.1.2

The following subsection suggests that there is a "heading" field in the
W3C structure/API, but I don't see one listed in Figure 1.

Section 6.1

What are suitable references for the "me" and "mola-vik-1" geoedtic
systems?  I do not see how just the listed descriptions provide a "clear
definition" even for the two coordinate values latitude/longitude.

Section 7

Thanks for using the template for security considerations for YANG
models!  I think that since some of the portions of the template do not
apply, they can safely be removed.  In particular, the "these are the
subtrees and data nodes and their sensitivity/vulnerability" lines can
go, and the clause about "can have a negative effect on network
operations" may be worth tweaking (network operations may not be the
most likely thing to be impacted).  I think it's also okay to drop the
paragraph/sentence about RPCs.

Section 8

The [WGS84] and [EGM08] links don't work for me.  ([EGM96] does.)

Section 9

It seems like RFC 7950 is more properly classified as normative, since
you can't really make sense of YANG without ... knowing YANG.  I think
8340 is sometimes listed as normative as well, but the case is not quite
as clear, here.

NITS

Abstract

  This document defines a generic geographical location object YANG
  grouping.  [...]

I'm having a hard time seeing what role the word "object" is playing
here, especially since in the next sentence we just refer to the
"geographical location grouping".

Section 3

        description
          "A location on an astronomical body (e.g., 'earth')
            somewhere in a universe.";

I guess in some alternate-systems the "astronomical body" bit may not
really be accurate.  (And possibly in some cartesian coordinate frames,
too, but that's less clear.)

            type string {
              pattern '[ -@\[-\^_-~]*';

If I'm reading my table correctly, '^' and '_' are adjacent, so this
rather-reader-unfriendly regex formulation can't even be justified as
the minimal encoding.

                '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).  [...]

"all lower case ASCII characters" inherently excludes control
characters, so "all lower case ASCII characters not including control
characters" is redundant.
Also, that doesn't match up the listed range of values (or the regex).
(Also^2, that doesn't match the given comet name, which has numbers and
punctuation.)

                  for Cartesian coordinates. When coord-accuracy is
                  specified, it overrides the geodetic-datum implied
                  accuracy.";
                  [...]
                "The accuracy of height value for ellipsoidal
                  coordinates, this value is not used with Cartesian
                  coordinates. When specified, it overrides the
                  geodetic-datum implied default.";

I suggest using parallel language for "when specified, overrides implied
default".  (That is, "coord-accuracy" is currently explicitly named but
"height-accuracy" is not.)

          leaf v-up {
            type decimal64 {
              fraction-digits 12;
            }
            units "meters per second";
            description
              "v-up is the rate of change (i.e., speed) away from the
                center of mass.";

"center of mass" may not be universally applicable, e.g., to cartesian
coordinates, binary systems, extremely massive objects that are not the
astronomical-body of the reference-frame.

Section 4

We probably should expand CRS at/before first usage.

Section 6.1

  Each entry should be sufficient to define the 3 coordinate values (2
  if height is not required).  So for example the "wgs-84" is defined

I'd suggest flipping the order, for "should be sufficient to define the
2 coordinate values, and to define height if height is required".

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

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.

[Ballot comment]

3. -----

  [WGS84]    National Imagery and Mapping Agency., "National Imagery
              and Mapping Agency Technical Report 8350.2, Third
              Edition.", 3 January 2000, .

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?

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.

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

[Ballot discuss]
** Section 3.  leaf astronomical-body.  The content of this field appears to be "An astronomical body as named by the International Astronomical Union (IAU) or according to the alternate                system if specified."  What’s the normative reference to the IAU’s list of astronomical bodies.  Listed here is “https://www.iau.org” which is an unstable reference to a website with changing content.

[Ballot comment]
Thank you to Stefan Santesson for the SECDIR review.

** Section 6.1.  Should the constraining pattern “[ -@\[-\^_-~]*” and associated text from leaf geodetic-datum be used to guide the acceptable values of the 'name' column?

[Ballot comment]
(2.2) "For the standard location choice latitude and longitude are specified as fractions of decimal degrees, and the height value is in fractions of meters."

What are "fractions of decimal degrees"? Is it not better to just say "decimal degrees" and "decimal meters"?

[Ballot 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”.

[Ballot 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”.

[Ballot 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,  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”.

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit.

Thank you to Ken Watsen for his shepherd's write-up (including the WG consensus). Nice to have acknowledged him.

Note: I loved the "any other astronomical object" in the abstract ;-) and, for a while, I have believed that I was read an April 1st RFC...

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==


-- Section 1 --
As written above, I like that this document does not limit itself to the Earth. May I suggest to add the ISS to the list ? If ISS is not considered as an astronomical body, then I really question the usefulness of this document.

-- Section 2.2 --
Just wondering whether latitude/longitude exist for all 'astronomical bodies' (magnetic field ? rotation on a single axe) ? I guess that it depends on the datum (just curious -- no need to reply).

-- Section 2.6 --
In the tree view, longitude/latitude/height have the same cardinality but section 2.2 states that height is optional.

-- Section 3 --
Any reason why the 'astronomical-body' is restricted to ASCII and not UETF-8 ?

Should the latitude/longitude leaves have ranges ? I.e., -90 +90 for latitude ?

== NITS ==

-- Appendix B --
Unusual location for the acknowledgements and it would have been nice to also acknowledge the doc shepherd.

[Ballot discuss]
Section 8, paragraph 2, discuss:
>    [EGM08]    Pavlis, N.K., Holmes, S.A., Kenyon, S.C., and J.K. Factor,
>              "An Earth Gravitational Model to Degree 2160: EGM08.",
>              Presented at the 2008 General Assembly of the European
>              Geosciences Union, Vienna, Arpil13-18, 2008, 2008,
>                              egm08_wgs84.html>.
>
>    [EGM96]    Lemoine, F.G., Kenyon, S.C., Factor, J.K., Trimmer, R.G.,
>              Pavlis, N.K., Chinn, D.S., Cox, C.M., Klosko, S.M.,
>              Luthcke, S.B., Torrence, M.H., Wang, Y.M., Williamson,
>              R.G., Pavlis, E.C., Rapp, R.H., and T.R. Olson, "The
>              Development of the Joint NASA GSFC and the National
>              Imagery and Mapping Agency (NIMA) Geopotential Model
>              EGM96.", Technical Report NASA/TP-1998-206861, NASA,
>              Greenbelt., 1998,
>              .

I question whether these two can be normatively referenced without an explicit
DOWNREF check. First, the URLs of both are broken. Second, the cached versions
on archive.org seem to be web pages that link to a lot of other material, with
no indication that anything on these pages is standards material. Are better
references available here?

[Ballot comment]
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

[Ballot comment]
[[ questions ]]

[ section 2.1 ]

* Is WGS-84 still the default for geodetic-datum when
  astronomical-body != "earth"?

  I think I might find it surprising if it were (i.e. if
  astronomical-body="enceladus" and geodetic-datum still defaults to "wgs-84"
  as opposed to an unspecified value or something that might cause a useful
  error message to be generated).

  I don't know enough YANG to know if the "when" statement is usable in this
  case to constrain the applicability of this default or not.


[[ nits ]]

[ section 3 ]

* In the description of "leaf astronomical-body",
  '67p/churyumov-gerasimenko lacks a closing quotation mark.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netmod-geo-location-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, a new registry is to be created called the Geodetic System Values registry. The new registry is to be created on a new registry page called YANG Geographic Location Parameters. The new registry is to be managed via First Come, First Served as defined by RFC 8126.

NOTE:  In accordance with current practice, IANA prefers to leave the string \u201cParameters\u201d out of the name of a new registry grouping, unless doing so will cause confusion. Please let us know if there will be any issues with using the term \u201cYANG Geographic Location\u201d instead of \u201cYANG Geographic Location Parameters.\u201d

There are initial values in the new registry as follows:

+------------+------------------------------------------------------+
| Name | Description |
+============+======================================================+
| me | Mean Earth/Polar Axis (Moon) |
+------------+------------------------------------------------------+
| mola-vik-1 | MOLA Height, IAU Viking-1 PM (Mars) |
+------------+------------------------------------------------------+
| wgs-84-96 | World Geodetic System 1984 [WGS84] w/ EGM96 |
+------------+------------------------------------------------------+
| wgs-84-08 | World Geodetic System 1984 [WGS84] w/ [EGM08] |
+------------+------------------------------------------------------+
| wgs-84 | World Geodetic System 1984 [WGS84] (EGM96 or |
| | better) |
+------------+------------------------------------------------------+

IANA Question --> Should the reference for each one of these five registrations be set to [ RFC-to-be ] or should another reference be used?

Second, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: yang:ietf-geo-location
URI: urn:ietf:params:xml:ns:yang:ietf-geo-location
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a new YANG module will be registered as follows:

Name: ietf-geo-location
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-geo-location
Prefix: geo
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-05-03):

From: The IESG
To: IETF-Announce
CC: Kent Watsen , draft-ietf-netmod-geo-location@ietf.org, kent+ietf@watsen.net, netmod-chairs@ietf.org, netmod@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Grouping for Geographic Locations) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'A YANG Grouping for Geographic Locations'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-05-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a generic geographical location object YANG
  grouping.  The geographical location grouping is intended to be used
  in YANG models for specifying a location on or in reference to Earth
  or any other astronomical object.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/



No IPR declarations have been submitted directly on this I-D.

From: https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents


Changes are expected over time. This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

[Shepherd] A "Proposed Standard" is requested.  This is the proper type of RFC given WG consensus.  The "Proposed Status" RFC type is indicated in Datatracker. The title page says that the Intended status is "Standards Track".



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

[Shepherd] (from the Abstract)
  This document defines a generic geographical location object YANG
  grouping.  The geographical location grouping is intended to be used
  in YANG models for specifying a location on or in reference to Earth
  or any other astronomical object.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

[Shepherd] There were no noteworthy WG process issues.  Controversial points were resolved.  No items had particularly rough consensus.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

[Shepherd] There are no known implementations known to the Shepherd.  No vendors have indicated their plan to implement the specification.  It was originally forwarded to support DT's Terra Stream project.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

[Shepherd] The Shepherd is Kent Watsen.  The Responsible Area Director is Robert Wilton.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

[Shepherd] The Shepherd has read the document, validated the normative YANG module found in Section 3, and validated both the example YANG module and example XML document found in Appendix A.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

[Shepherd] The Shepherd does not have any concerns about the depth or breadth of the reviews that have been performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

[Shepherd] The draft had additional review by non-IETF experts Ben Koziol and Jim Biard:

    Ben Koziol - NOAA Affiliate
    University of Colorado
    Cooperative Institute for Research in Environmental Sciences at the
    NOAA Earth System Research Laboratory/Global Systems Division
   
    Jim Biard
    Research Scholar
    North Carolina State University
    North Carolina Institute for Climate Studies (NCICS



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

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



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

[Shepherd] Yes (https://mailarchive.ietf.org/arch/msg/netmod/6OGBXDIFMZybUi5I0SmzNVnH1qc)



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

[Shepherd] No IPR disclosure has been filed that references this document.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

[Shepherd] The whole WG adopted the effort.  Strong concurrence of a few individuals worked out the details.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

[Shepherd] No one has threatened an appeal or otherwise indicated extreme discontent.



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


[Shepherd] According to IDNITS with "verbose checking":

=====START=====

/tmp/draft-ietf-netmod-geo-location-07.txt:
/tmp/draft-ietf-netmod-geo-location-07.txt(316): Code start at 316:    file "ietf-geo-location@2019-02-17.yang".
/tmp/draft-ietf-netmod-geo-location-07.txt(626): Code end at 626:    .
/tmp/draft-ietf-netmod-geo-location-07.txt(992): Line has weird spacing: '...  name  ietf-...'
/tmp/draft-ietf-netmod-geo-location-07.txt(994): Line has weird spacing: '...mespace  urn:i...'
/tmp/draft-ietf-netmod-geo-location-07.txt(996): Line has weird spacing: '... prefix  geo...'
/tmp/draft-ietf-netmod-geo-location-07.txt(1248): Line is too long: the offending characters are '?'


  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
    being 1 character in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (June 2021) is 173 days in the future.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'EGM08'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'EGM96'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS84'


    Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

=====STOP=====

Of these, the only real issue is the "line too long" issue, which the RFC Editor should catch.  Some of the other "issues" are actually NOT issues at all (e.g., the future date, down refs, etc.)



(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

[Shepherd] The document was reviewed by a YANG Doctor: https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23



(13) Have all references within this document been identified as either normative or informative?

[Shepherd] Yes, all the references have been identified as either normative or informative.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

[Shepherd] All normative documents are fully published.  Some normative documents are by other SDOs.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

[Shepherd] There are no downward references.  The down-refs caught by IDNITS are because those references are published by external SDOs.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

[Shepherd] The publication of this document does not change the status of any existing RFCs.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

[Shepherd] The Shepherd has reviewed the IANA Considerations section.  In addition to the two standard registrations made by any document publishing YANG modules, the document also defines a new "Geodetic System Values" registry.



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

[Shepherd] No new registriries require Expert Review for future allocations.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

[Shepherd] The Shepherd has validated the normative YANG module found in Section 3, and validated both the example YANG module and the example instance XML document found in Appendix A.



(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

[Shepherd] The Shepherd used the following command to check the "style" correctness of the YANG module.  A few discrepancies appeared, but none seemed overly egregious to the Shepherd:

  $ pyang -f yang --keep-comments --yang-line-length 69 ietf-geo-location@2019-02-17.yang > tmp; diff ietf-geo-location@2019-02-17.yang tmp




From: https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents


Changes are expected over time. This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

[Shepherd] A "Proposed Standard" is requested.  This is the proper type of RFC given WG consensus.  The "Proposed Status" RFC type is indicated in Datatracker. The title page says that the Intended status is "Standards Track".



(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

[Shepherd] (from the Abstract)
  This document defines a generic geographical location object YANG
  grouping.  The geographical location grouping is intended to be used
  in YANG models for specifying a location on or in reference to Earth
  or any other astronomical object.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

[Shepherd] There were no noteworthy WG process issues.  Controversial points were resolved.  No items had particularly rough consensus.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

[Shepherd] There are no known implementations known to the Shepherd.  No vendors have indicated their plan to implement the specification.  It was originally forwarded to support DT's Terra Stream project.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

[Shepherd] The Shepherd is Kent Watsen.  The Responsible Area Director is Robert Wilton.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

[Shepherd] The Shepherd has read the document, validated the normative YANG module found in Section 3, and validated both the example YANG module and example XML document found in Appendix A.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

[Shepherd] The Shepherd does not have any concerns about the depth or breadth of the reviews that have been performed.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

[Shepherd] The draft had additional review by non-IETF experts Ben Koziol and Jim Biard:

    Ben Koziol - NOAA Affiliate
    University of Colorado
    Cooperative Institute for Research in Environmental Sciences at the
    NOAA Earth System Research Laboratory/Global Systems Division
   
    Jim Biard
    Research Scholar
    North Carolina State University
    North Carolina Institute for Climate Studies (NCICS



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

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



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

[Shepherd] Yes (https://mailarchive.ietf.org/arch/msg/netmod/6OGBXDIFMZybUi5I0SmzNVnH1qc)



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

[Shepherd] No IPR disclosure has been filed that references this document.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

[Shepherd] The whole WG adopted the effort.  Strong concurrence of a few individuals worked out the details.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

[Shepherd] No one has threatened an appeal or otherwise indicated extreme discontent.



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


[Shepherd] According to IDNITS with "verbose checking":

=====START=====

/tmp/draft-ietf-netmod-geo-location-07.txt:
/tmp/draft-ietf-netmod-geo-location-07.txt(316): Code start at 316:    file "ietf-geo-location@2019-02-17.yang".
/tmp/draft-ietf-netmod-geo-location-07.txt(626): Code end at 626:    .
/tmp/draft-ietf-netmod-geo-location-07.txt(992): Line has weird spacing: '...  name  ietf-...'
/tmp/draft-ietf-netmod-geo-location-07.txt(994): Line has weird spacing: '...mespace  urn:i...'
/tmp/draft-ietf-netmod-geo-location-07.txt(996): Line has weird spacing: '... prefix  geo...'
/tmp/draft-ietf-netmod-geo-location-07.txt(1248): Line is too long: the offending characters are '?'


  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
    being 1 character in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (June 2021) is 173 days in the future.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'EGM08'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'EGM96'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS84'


    Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 4 comments (--).

=====STOP=====

Of these, the only real issue is the "line too long" issue, which the RFC Editor should catch.  Some of the other "issues" are actually NOT issues at all (e.g., the future date, down refs, etc.)



(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

[Shepherd] The document was reviewed by a YANG Doctor: https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23



(13) Have all references within this document been identified as either normative or informative?

[Shepherd] Yes, all the references have been identified as either normative or informative.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

[Shepherd] All normative documents are fully published.  Some normative documents are by other SDOs.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

[Shepherd] There are no downward references.  The down-refs caught by IDNITS are because those references are published by external SDOs.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

[Shepherd] The publication of this document does not change the status of any existing RFCs.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

[Shepherd] The Shepherd has reviewed the IANA Considerations section.  In addition to the two standard registrations made by any document publishing YANG modules, the document also defines a new "Geodetic System Values" registry.



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

[Shepherd] No new registriries require Expert Review for future allocations.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

[Shepherd] The Shepherd has validated the normative YANG module found in Section 3, and validated both the example YANG module and the example instance XML document found in Appendix A.



(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

[Shepherd] The Shepherd used the following command to check the "style" correctness of the YANG module.  A few discrepancies appeared, but none seemed overly egregious to the Shepherd:

  $ pyang -f yang --keep-comments --yang-line-length 69 ietf-geo-location@2019-02-17.yang > tmp; diff ietf-geo-location@2019-02-17.yang tmp