Subject: [Geopriv] Last Call: <draft-ietf-geopriv-rfc3825bis-16.txt> (Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 04 Feb 2011 14:19:20 -0800

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
[email-masked] mailing lists by 2011-02-18. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Feb 2011 16:06:18 -0800

This IETF Last Call statement makes incorrect statements with respect to the RFC 3825bis changes.   As a result, I believe that it should be corrected and reissued.

1. The original document obsoleted RFC 3825 from the very beginning.  So this does not represent a change.  See http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis-00.txt
2. The original document also utilized Option Code 123.  This also did not change. 

> From: [email-masked]
> To: [email-masked]
> Date: Fri, 4 Feb 2011 14:19:20 -0800
> CC: [email-masked]
> Subject: [Geopriv] Last Call: <draft-ietf-geopriv-rfc3825bis-16.txt>	(Dynamic Host	Configuration Protocol Options for	Coordinate-based Location	Configuration Information) to	Proposed Standard
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 05 Feb 2011 08:53:36 +0200

Hello,

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:
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>