Relative Location Representation
draft-ietf-geopriv-relative-location-08

[Ballot comment]

Thanks for clearing up the IPR thing with a 2nd last call.

-----------------

I didn't check the comments below so they may not
reflect the content of -07

- 4.2 says this extends PIDF-LO as described in 6848, but
this doesn't update any RFCs - should it? (Just asking
I don't really care:-)

- 4.11: The TLV format appears to only support 255 byte
URLs. Is that right? If so, that seems small and worth
stating explicitly.

- 4.11: The map properties (scale etc) are said to be
defined by the MIME type, but then you use an example of
image/jpeg - that seems a bit broken. I would have
expected some other information than image/jpeg to
specify the kind of map and for the MIME type to specify
how to render to map. But I guess this can sort of work
for now.

- 7: If an http URL for a map is used and de-referenced
that might expose the location of the target, esp. if the
map is for a small area. I think you should note that
and, given that (I think) other location URLs are at
least encouraged to use TLS, this draft should also
encourage use of https and not http URLs. I'd be most
happy if you said that https MUST or SHOULD be used:-)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-geopriv-relative-location-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has questions about the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document there are four actions which IANA must complete.

First, IANA is to create a new registry called the "Relative Location Parameters" registry.

IANA Question -->  Is this to be created on a new page (and if so, what's the title? If other registries could be added to the page later, the title should reflect that), or is it to be created in an existing page (and if so, which one)?

Maintenance of the new registry will be done through IETF Review as defined by RFC 5226.

Entries consist of a Relative Location Code, a brief description and a reference.

An initial registry has been supplied by the document authors as follows:

+--------+----------------------------------------+----------------+
| RLtype | description                            | Reference      |
+--------+----------------------------------------+----------------+
| 0-40  | RESERVED by CAtypes registry          | [ RFC-to-be ]  |
| 128    |                                        | & RFC4776      |
+--------+----------------------------------------+----------------+
| 111    | relative location reference            | [ RFC-to-be ]  |
| 113    | relative location shape 2D point      | [ RFC-to-be ]  |
| 114    | relative location shape 3D point      | [ RFC-to-be ]  |
| 115    | relative location shape circular      | [ RFC-to-be ]  |
| 116    | relative location shape spherical      | [ RFC-to-be ]  |
| 117    | relative location shape elliptical    | [ RFC-to-be ]  |
| 118    | relative location shape ellipsoid      | [ RFC-to-be ]  |
| 119    | relative location shape 2D polygon    | [ RFC-to-be ]  |
| 120    | relative location shape 3D polygon    | [ RFC-to-be ]  |
| 121    | relative location shape prism          | [ RFC-to-be ]  |
| 122    | relative location shape arc-band      | [ RFC-to-be ]  |
| 123    | relative location dynamic orientation  | [ RFC-to-be ]  |
| 124    | relative location dynamic speed        | [ RFC-to-be ]  |
| 125    | relative location dynamic heading      | [ RFC-to-be ]  |
| 126    | relative location map type            | [ RFC-to-be ]  |
| 127    | relative location map URI              | [ RFC-to-be ]  |
| 129    | relative location map coordinates      | [ RFC-to-be ]  |
| 130    | relative location map angle            | [ RFC-to-be ]  |
| 131    | relative location map scale            | [ RFC-to-be ]  |
+--------+----------------------------------------+----------------+

Second, in the ns subregistry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns

a new namespace is to be registered as follows:

ID: pidf:geopriv10:relative
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Filename: [ As-supplied-in-approved-document ]
Reference: [ RFC-to-be ]

Third, in the schema subregistry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#schema

a new schema is to be registered as follows:

ID: pidf:geopriv10:relativeLocation
URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Filename: [ As-supplied-in-section-6-of-the-approved-document ]
Reference: [ RFC-to-be ]

Fourth, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry in the Uniform Resource Name (URN) Namespace for IETF Use located at:

http://www.iana.org/assignments/params/params.xhtml

a new subnamespace will be registered as follows:

Geopriv Identifiers
[ RFC-to-be ]
[ Repository-supplied-at-time-of-creation ]

IANA Question -->  Is this to be created on a new page (and if so, what's the title? If other registries could be added to the page later, the title should reflect that), or is it to be created in an existing page (and if so, which one)?

In this new repository, each entry has a URN, Description, Specification, Contact, and Index Value.

This page is to be maintained through IETF Review as defined by RFC 5226.

There are two intial registrations in this new repository, as follows:

URN: urn:ietf:params:geopriv:relative:2d
Description: A two-dimensional relative coordinate reference system
Specification: [ RFC-to-be ]
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net)
Index Value: N/A

URN: urn:ietf:params:geopriv:relative:3d
Description: A three-dimensional relative coordinate reference system
Specification: [ RFC-to-be ]
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net)
Index Value: N/A

IANA understands that these four actions are the only ones 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 only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Relative Location Representation) to Proposed Standard


The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Relative Location Representation'
  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
ietf@ietf.org mailing lists by 2013-08-02. 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.

This second IETF LC is just to ensure that the IPR
declaration [1] on the non-WG draft that this replaces has
been considered.

[1] https://datatracker.ietf.org/ipr/1348/

Abstract


  This document defines an extension to PIDF-LO (RFC4119) for the
  expression of location information that is defined relative to a
  reference point.  The reference point may be expressed as a geodetic
  or civic location, and the relative offset may be one of several
  shapes.  An alternative binary representation is described.

  Optionally, a reference to a secondary document (such as a map image)
  can be included, along with the relationship of the map coordinate
  system to the reference/offset coordinate system to allow display of
  the map with the reference point and the relative offset.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-relative-location/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-relative-location/ballot/


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

[Ballot discuss]
Three points here:

1. The IANA Considerations section needs to register "geopriv" in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry.

2. I wanted to make sure that IANA is OK with tying the allowable codepoints in the new "Relative Location Parameters" registry with the "Civic Address Types" registry.  The IANA review does acknowledge this relationship, and the fact that the CAtypes registry is closed to new registrations makes this easier, but I spoke with Michelle on the telechat to make sure they're able to handle this without any difficulties.  Michelle suggested that a good way to avoid overlap between the two registries is to put the entries from the latter into the former as "reserved" entries.  Then if there *is* a reason to reassign one, the reservation can be removed and the new entry can be created... but no one will make a mistake because they didn't go look in the other registry.  This also addresses my concern about whether the IESG might forget to check this relationship when evaluating a future RFC that makes a registration here.

So, in Section 8.1, add to the paragraph before the table thus:

NEW
  Values requested to be assigned into this registry MUST NOT conflict
  with values assigned in the CAtypes registry or vice versa, unless
  the IANA considerations section for the new value explicitly
  overrides this prohibition and the document defining the value
  describes how conflicting TLV codes will be interpreted by
  implementations.  To ensure this, the CAtypes entries are
  explicitly reserved in the initial values table below.  Those
  reserved entries can be changed, but only with caution as
  explained here.

And then add entries to the table like this:

  +--------+----------------------------------------+-----------+
  | RLtype | description                            | Reference |
  +--------+----------------------------------------+-----------+
  | 0 - 40 | RESERVED by CAtypes registry          | this RFC  |
  +--------+----------------------------------------+-----------+
  | 111    | relative location reference            | this RFC  |
  ...etc...

I note that values 7 to 15 are unassigned in the CAtypes registry, so you might want to make it this way instead:

  +--------+----------------------------------------+-----------+
  | RLtype | description                            | Reference |
  +--------+----------------------------------------+-----------+
  | 0 - 6  | RESERVED by CAtypes registry          | this RFC  |
  | 7 - 15 | unassigned                            |          |
  |16 - 40 | RESERVED by CAtypes registry          | this RFC  |
  +--------+----------------------------------------+-----------+
  | 111    | relative location reference            | this RFC  |
  ...etc...

You'll know which the right answer to that is, of course.

3. In writing this up, I note that you already do have a collision: the value 128 is assigned in the CAtypes registry, with a reference to RFC 4776... and this document also uses that value for "relative location map coordinates".  Please confirm whether this is OK (and how it relates to the warning in the paragraph above).

[Ballot comment]
In 4.5, you don't reference an RFC that describes the encoding, but rather an IEEE document. I do not dispute that this is the right thing to do, because I don't know of an IETF document that specifies this, but one concern I have is that the order of the bits in memory or on the wire is not specified, and the in-memory representation for floating point numbers does vary on CPU architectures of different endianness, including some interesting variations on some ARM processors. I think you ought to specify a wire-format encoding, or find a document you can reference that already specifies it.

I find the discussion about covert channels in the fractional bits to be somewhat unhelpful. Under what circumstances would suppressing a covert channel make sense? Is this a privacy concern, or is the concern that someone might use this very narrow channel to attempt to transmit information without being tracked?

[Ballot comment]
While the timestamp shows in the XML, its use and relevance in a
relational location system is not discussed. It should be noted that
both the located object and the reference point may be in motion.
Thus a location may be given at time=t2 with reference to a reference
point's location at time=t1 (where t1 is usually <= t2). Obviously, it
is also the case that the actual location is timestamped.

[Ballot discuss]

An IPR/process-nit DISCUSS-DISCUSS:

The IETF last call seems to have gone out saying there
are no IPR declarations.  The shepherd write-up also says
there's no IPR.  There is one [1] for
draft-thomson-geopriv-relative-location-01 from 2010, and
its RAND with possible fee.  Is that because the
"replaced-by" information wasn't updated (it looks like
it was) or perhaps the IPR holder didn't think that the
WG draft was really covered or is it some tooling bug?
If the IPR declaration does apply then another IETF LC is
needed I guess.

  [1] https://datatracker.ietf.org/ipr/1348/

[Ballot comment]

- 4.2 says this extends PIDF-LO as described in 6848, but
this doesn't update any RFCs - should it? (Just asking
I don't really care:-)

- 4.11: The TLV format appears to only support 255 byte
URLs. Is that right? If so, that seems small and worth
stating explicitly.

- 4.11: The map properties (scale etc) are said to be
defined by the MIME type, but then you use an example of
image/jpeg - that seems a bit broken. I would have
expected some other information than image/jpeg to
specify the kind of map and for the MIME type to specify
how to render to map. But I guess this can sort of work
for now.

- 7: If an http URL for a map is used and de-referenced
that might expose the location of the target, esp. if the
map is for a small area. I think you should note that
and, given that (I think) other location URLs are at
least encouraged to use TLS, this draft should also
encourage use of https and not http URLs. I'd be most
happy if you said that https MUST or SHOULD be used:-)

[Ballot discuss]
Two points here:

1. As already discussed with Martin, the IANA Considerations section needs to register "geopriv" in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry (and we need to make sure that IANA is aware of the additional action).

2. This is a "DISCUSS-DISCUSS" point, with no action needed by the authors: I want to make doubly sure that IANA is OK with tying the allowable codepoints in the new "Relative Location Parameters" registry with the "Civic Address Types" registry.  The IANA review does acknowledge this relationship, and the fact that the CAtypes registry is closed to new registrations makes this easier, but I want to talk with Michelle on the telechat and make sure they're able to handle this without any difficulties.  I'll also note that because the registration policy for the new registry is "IETF Review", it will be up to the IESG to check new registrations against this linkage, so we need to make sure it's clearly documented in the header of the registry itself.

[Ballot comment]
In 1.  Introduction

  In addition to the relative location, an optional URI can be provided
  to a document that contains a map, floorplan or illustration.

I'm reading this text as saying those are the three choices. Is that what you meant?

In 3.  Overview

  This extension allows the creator of a location object to include two
  location values plus an offset.

It would be helpful to this reader if you named the two location values. The following text talks about a "baseline location", but I'm not sure whether that's one of the two location values, and whether it is or not, I'm not sure what the other location value is.

Further down in Section 3,

  The baseline location SHOULD be general enough to describe both the
  reference location and the relative location (reference plus offset).
  Location objects SHOULD NOT have all location information in the
  baseline location. 

I'm not sure the first SHOULD is a 2119 SHOULD (perhaps something like "needs to be"?), and I'm not sure why the second SHOULD NOT isn't a MUST NOT.

In 4.9.4.  Polygon or Prism Shape

  At least 3 points MUST be included in a polygon.  In order to
  interoperate with existing systems, an encoding SHOULD include 15 or
  fewer points, unless the recipient is known to support larger
  numbers.

Is there any way to signal support for more than 15 points? If not, I'm somewhat uneasy about this being a SHOULD - what you know about other entities in a loosely-coupled distributed system may be true when you discover them, but might change later. Is this saying that a sender might include 18 points, thinking that other peers support 18 points, while being ready to fall back to 15 if 18 is beyond the peer's capability? Does that sound like a good plan for location information being used by a PSAP?

in tracker
IANA Actions - YES


NOTE: This revised review is based on version 05 of the drafted document.

IANA has a question about this document's actions.

We understand that, upon approval of this document, there are five actions which we must complete.

First, a new registry called the "Relative Location Parameters" registry will be created. The registry will be maintained via "IETF Review" as defined in RFC5226. New values to be assigned in this registry must either be explicitly different from values registered in the CAtypes registry located at:

http://www.iana.org/assignments/civic-address-types-registry

unless the extenuating circumstances documented in Section 8.1 of the approved document are observed.

We understand that the new registry is to be created on a new page in the IANA Matrix located at:

http://www.iana.org/protocols

There are initial registrations in this new registry as follows:

+--------+----------------------------------------+----------------+
| RLtype | description                            | Reference      |
+--------+-------+--------------------------------+----------------+
| 111    | relative location reference            | [ RFC-to-be ]  |
| 113    | relative location shape 2D point      | [ RFC-to-be ]  |
| 114    | relative location shape 3D point      | [ RFC-to-be ]  |
| 115    | relative location shape circular      | [ RFC-to-be ]  |
| 116    | relative location shape spherical      | [ RFC-to-be ]  |
| 117    | relative location shape elliptical    | [ RFC-to-be ]  |
| 118    | relative location shape ellipsoid      | [ RFC-to-be ]  |
| 119    | relative location shape 2D polygon    | [ RFC-to-be ]  |
| 120    | relative location shape 3D polygon    | [ RFC-to-be ]  |
| 121    | relative location shape prism          | [ RFC-to-be ]  |
| 122    | relative location shape arc-band      | [ RFC-to-be ]  |
| 123    | relative location dynamic orientation  | [ RFC-to-be ]  |
| 124    | relative location dynamic speed        | [ RFC-to-be ]  |
| 125    | relative location dynamic heading      | [ RFC-to-be ]  |
| 126    | relative location map type            | [ RFC-to-be ]  |
| 127    | relative location map URI              | [ RFC-to-be ]  |
| 128    | relative location map coordinates      | [ RFC-to-be ]  |
| 129    | relative location map angle            | [ RFC-to-be ]  |
| 130    | relative location map scale            | [ RFC-to-be ]  |
+--------+-------+--------------------------------+----------------+

Second, in the IETF XML namespace registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xml#ns

a new namespace will be registered as follows:

ID: geopriv10:relative
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Filename: ns/geopriv10/relative.txt
Reference: [ RFC-to-be ]

Third, in the IETF XML schema registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xml#schema

a new schema will be registered as follows:

ID: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
URI: geopriv10:relativeLocation
Filename: schema/geopriv10/relativeLocation.txt
Reference: [ RFC-to-be ]

Fourth, a new registry will be created called the "Geopriv Identifiers" registry.  This registry will be maintained via "IETF Review" as defined by RFC 5226.

There are two new public identifiers will be registered as follows:

+-------------------------------------------+------------------------------+---------------------+------------------+
|  URN                                      |Description                  | Specification      | Contact          |
| urn:ietf:params:geopriv:relative:2d      |A two-dimensional relative    | [RFC-to-be]        | GEOPRIV WG      |
|                                          |coordinate reference system  |                    |                  |
| urn:ietf:params:geopriv:relative:3d      |A twhree-dimensional relative | [RFC-to-be]        | GEOPRIV WG      |
|                                          |coordinate reference system  |                    |                  |
+-------------------------------------------+------------------------------+---------------------+------------------+

QUESTION: Do authors intend to have a brand new top-level registry for
this new registry "Geopriv Identifiers"?  Or, is it a sub-registry of
an existing registry?  And if so, please point out the existing registry.

Fifth, in the CAtype registry located at:

http://www.iana.org/assignments/civic-address-types-registry

a new CAtype is to be added as follows:

CAtype: [ TBD-at-registration ]
Local name: REL
Description: Relative location from a reference point
Example:
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org).
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Type: A
Reference: [ RFC-to-be ]

NOTE: The CAtype registry is maintained via Expert Review as defined in RFC5226.

We understand that these are the only actions required 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 only to confirm what actions will be performed.

IESG/Authors/WG Chairs:

NOTE: IANA has a question about this document's actions.

IANA has reviewed draft-ietf-geopriv-relative-location-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there are five actions which IANA must complete.

First, a new registry called the "Relative Location Parameters" registry will be created.  The registry will be maintained via "IETF Review" as defined in RFC5226.  New values to be assigned in this registry must either be explicitly different from values registered in the CAtypes registry located at:

http://www.iana.org/assignments/civic-address-types-registry

unless the extenuating circumstances documented in Section 8.1 of the approved document are observed.

QUESTION: Should this new registry be created on a new page, or should it be added to the "Civic Address Types Registry" page?

8.1. Relative Location Registry

There are initial registrations in this new registry as follows:

+--------+----------------------------------------+----------------+
| RLtype | description                            | Reference      |
+--------+-------+--------------------------------+----------------+
| 111    | relative location reference            | [ RFC-to-be ]  |
| 113    | relative location shape 2D point      | [ RFC-to-be ]  |
| 114    | relative location shape 3D point      | [ RFC-to-be ]  |
| 115    | relative location shape circular      | [ RFC-to-be ]  |
| 116    | relative location shape spherical      | [ RFC-to-be ]  |
| 117    | relative location shape elliptical    | [ RFC-to-be ]  |
| 118    | relative location shape ellipsoid      | [ RFC-to-be ]  |
| 119    | relative location shape 2D polygon    | [ RFC-to-be ]  |
| 120    | relative location shape 3D polygon    | [ RFC-to-be ]  |
| 121    | relative location shape prism          | [ RFC-to-be ]  |
| 122    | relative location shape arc-band      | [ RFC-to-be ]  |
| 123    | relative location dynamic orientation  | [ RFC-to-be ]  |
| 124    | relative location dynamic speed        | [ RFC-to-be ]  |
| 125    | relative location dynamic heading      | [ RFC-to-be ]  |
| 126    | relative location map type            | [ RFC-to-be ]  |
| 127    | relative location map URI              | [ RFC-to-be ]  |
| 128    | relative location map coordinates      | [ RFC-to-be ]  |
| 129    | relative location map angle            | [ RFC-to-be ]  |
| 130    | relative location map scale            | [ RFC-to-be ]  |
+--------+-------+--------------------------------+-----------+

Second, in the IETF XML namgespace registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xml#ns

a new namespace will be registered as follows:

ID: geopriv10:relative
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Filename: ns/geopriv10/relative.txt
Reference: [ RFC-to-be ]

Third, in the IETF XML schema registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xml#schema

a new schema will be registered as follows:

ID: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
URI: geopriv10:relativeLocation
Filename: schema/geopriv10/relativeLocation.txt
Reference: [ RFC-to-be ]

Fourth, in the IETF XML public identifiers registry located at:

http://www.iana.org/assignments/xml-registry/xml-registry.xml#publicid

two new public identifiers will be registered as follows:

ID: geopriv10:relative:2d
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d
Filename: /publicid/geopriv10/relative/2d.dtd
Reference: [ RFC-to-be ]

ID: geopriv10:relative:3d
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d
Filename: /publicid/geopriv10/relative/3d.dtd
Reference: [ RFC-to-be ]

Fifth, in the CAtype registry located at:

http://www.iana.org/assignments/civic-address-types-registry

a new CAtype is to be added as follows:

CAtype: [ TBD-at-registration ]
Local name: REL
Description: Relative location from a reference point
Example:
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group (geopriv@ietf.org).
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Type: A
Reference: [ RFC-to-be ]

NOTE: The CAtype registry is maintained via Expert Review as defined in RFC5226.  IANA has sent a request for review to this registry's designated expert.

IANA understands that these are the only actions required 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 only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce:;
CC:
Bcc:
Reply-To: IETF Discussion List
Sender:
Subject: Last Call:  (Relative Location Representation) to Proposed Standard


The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Relative Location Representation'
  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
ietf@ietf.org mailing lists by 2013-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 an extension to PIDF-LO (RFC4119) for the
  expression of location information that is defined relative to a
  reference point.  The reference point may be expressed as a geodetic
  or civic location, and the relative offset may be one of several
  shapes.  Optionally, a reference to a secondary document (such as a
  map image) can be included, along with the relationship of the map
  coordinate system to the reference/offset coordinate system to allow
  display of the map with the reference point and the relative offset.
  Also included in this document is a Type/Length/Value (TLV)
  representation of the relative location for use in other protocols
  that use TLVs.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-relative-location/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-relative-location/ballot/


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

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

The type of RFC being requested is Proposed Standard. This is the proper type because the document specifies an extension to an existing standards track data format (defined in RFC 4119).

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

This document defines an extension to PIDF-LO (RFC4119) for the
expression of location information that is defined relative to a
reference point. The reference point may be expressed as a geodetic
or civic location, and the relative offset may be one of several
shapes. Optionally, a reference to a secondary document (such as a
map image) can be included, along with the relationship of the map
coordinate system to the reference/offset coordinate system to allow
display of the map with the reference point and the relative offset.
Also included in this document is a Type/Length/Value (TLV)
representation of the relative location for use in other protocols
that use TLVs.

Working Group Summary:

This document is the product of many years of discussion within the WG. Ultimately, a design team comprised of authors with originally differing views came together to produce a specification that obtained WG consensus.

Document Quality:

There are both existing implementations of what is specified here and plans to implement it.

Personnel:

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

Alissa Cooper is the document shepherd. Richard Barnes is the responsible area director.

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

This document is ready for publication. It has been thoroughly reviewed by the shepherd and the authors have made changes requested by the shepherd to prepare it for publication.

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

No. This document was discussed at length within the working group, where we have expertise from the OGC community, the IEEE community, the indoor location community, and other potential consumers of this specification.

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

No. The relevant location-based experts in the WG have reviewed the draft.

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

The WG has discussed the contentious parts of this document at length, particularly the implications of how baseline locations would be interpreted by clients that do not understand relative location. We arrived at a consensus position that the WG could agree to.

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

Each author has confirmed this.

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

No IPR has been filed.

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

By the time this document was completed, the WG had lost a bit of interest in it, but we did obtain consensus.

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

There have been no appeal threats or expressions of 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.

There are no nits found in this document.

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

The document does not require formal reviews.

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

Yes.

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

There are no such references.

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

There is a normative reference to Clinger1990, which is an academic article that specifies an algorithm for converting a number in decimal scientific notation into the best approximation in binary floating point with fixed precision. Although this is not an official standard from an SDO, this reference is believed to be safe.

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

No status changes will result from this publication.

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

The IANA considerations section is consistent with the body of the document and contains all of the information necessary for IANA to create and populate the new Relative Location Parameters 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.

There are no such registries in this document.

(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, etc.

All of the XML in this document has been validated.