I might want to comment the Section 4 of this document.
Firstly, none of the three registries are properly specified, per RFC
5226. Among other, there is no clear format of the registries.
Therefore I propose the following changes.
> 4. IANA Considerations
>
> 4.1. 'Altitude Types' Registry
>
> IANA is asked to create and maintain the registry called 'Altitude
> Types' following the guidelines below.
>
> The registry consists of 3 values: Altitude Type, Description and
> Reference. They are described below.
>
> Altitude Type - an integer; refers to the value used in DHCP options
> described in this document. Values from 0 to 15 are assigned.
>
> Description - the description of the altitude described by this code.
>
> Reference - the reference to the document that describes the
> altitude code. Such MUST define the way that the 30 bit altitude
> values and the associated 6 bit uncertainty are interpreted.
>
> Initial values are given below; new assignments are to be made
> following the 'Standards Action' policies [RFC5226]
>
> # Description Reference
> +-------+---------------------------+------------+
> | 0 | No known altitude | RFC xxxx |
> | 1 | Altitude in meters | RFC xxxx |
> | 2 | Altitude in floors | RFC xxxx |
> | 3-14 | Unassigned | RFC xxxx |
> | 15 | Reserved | RFC xxxx |
> +-------+---------------------------+------------+
> [RFC Editor: Please replace xxxx with RFC number assigned to this
> document.
and etc. for each registry and the request to assign the DHCP code number.
Moreover, IMO RFC 5226 should be referenced normatively as it describes
procedures for assignment of new values to the registry. Informative is
not appropriate here. I'd also like to ask whether the following
reference is acceptable for normative:
> [EPSG] European Petroleum Survey Group, http://www.epsg.org/ and
> http://www.epsg-registry.org/
Normative references are allowed to documents only, but not websites.
Thank you in advance for considering my comments in the next version of
the draft.
Mykyta Yevstifeyev
05.02.2011 0:19, The IESG wrote:
> The IESG has received a request from the Geographic Location/Privacy WG
> (geopriv) to consider the following document:
> - 'Dynamic Host Configuration Protocol Options for Coordinate-based
> Location Configuration Information'
> <draft-ietf-geopriv-rfc3825bis-16.txt> as a Proposed Standard
>
> This is the 2nd IETF LC for this document focusing on changes resulting from IESG review.
> The first last call was on version -12 of the document.
> IESG review resulted in these substantial changes:
> - The document will obsolete RFC3825
> - Option code 123 is defined in this document
> - The document defines a new option code instead of extending the behavior of code 123
>
> 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
> ietf@ietf.org mailing lists by 2011-02-18. 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 specifies Dynamic Host Configuration Protocol Options
> (both DHCPv4 and DHCPv6) for the coordinate-based geographic location
> of the client. The Location Configuration Information (LCI) includes
> Latitude, Longitude, and Altitude, with resolution or uncertainty
> indicators for each. Separate parameters indicate the reference
> datum for each of these values. This document obsoletes RFC 3825.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
