Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)
RFC 5962

[Ballot comment]
One question and two nits.

I almost made this a DISCUSS but I decided against it.  Question:

Was there any thought given to allowing a system of measurement parameter (i.e., imperial vs metric) to allow different speed measurements (e.g., feet/second vs meters/second)?

Nits:

Section 2: r/through/throughout
Section 2: r/[RFC4079])/[RFC4079]

[Ballot comment]
One question and two nits.

Question:

Was there any thought given to allowing a parameter for different speed measurements for imperial/metric (i.e., so feet/second instead of meters/second)?

Nits:

Section 2: r/through/throughout
Section 2: r/[RFC4079])/[RFC4079]

[Note]: 'LC will not have ended by the time this is on agenda but the odds are high there will be zero LC comments. If we decide to approve, I will hold a discuss on any LC comments. Richard Barnes (rbarnes@bbn.com) is the document shepherd.' added by Robert Sparks

[Ballot comment]
3.1.  Angular Measures and Coordinate Reference Systems

  [RFC5491] constrains the coordinate reference system (CRS) used in
  PIDF-LO to World Geodetic System 1984 (WGS 84) using either the two-
  dimensional (latitude, longitude) CRS identified by
  "urn:ogc:def:crs:EPSG::4326" or the two-dimensional (latitude,

s/two-dimensional/three-dimensional

  longitude, altitude) CRS identified by "urn:ogc:def:crs:EPSG::4979".

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following assignment
in the "ns" registry at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template Reference
----- ------------------------------ -------------------- ------------
pidf:dynamic urn:ietf:params:xml:ns:pidf:dynamic pidf:dynamic
[RFC-singh-geopriv-pidf-lo-dynamic-07]


Action 2:

Upon approval of this document, IANA will make the following assignment
in the "schema" registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename Reference
----- ------------------------------ ----------- ------------
pidf:dynamic urn:ietf:params:xml:schema:pidf:dynamic pidf:dynamic
[RFC-singh-geopriv-pidf-lo-dynamic-07]


We understand the above to be the only IANA Actions for this document.

[Ballot discuss]
I would like have a short discussion and the confirmation of the security experts that the following issue does not constitute a problem. The Security Considerations section is remarkably short saying just:

>  This document defines additional location elements carried by
  PIDF-LO.  No additional security considerations beyond those
  described in RFC 4119 [RFC4119] are applicable to this document.

RFC 4119 points back to RFC 3694 and RFC 3693 (section 7.4) to describe the threat model and the security requirements imposed on geopriv as result of the threat model. However, in my reading of these two documents they seem to take into consideration only the threats related to the  current location information, while this drat introduces dynamic information that may be used by attackers to anticipate the future location of a host. To my understanding the security considerations refered in RFC 4119 may still be enough to cover the new scenarions, but I would like to have this confirmed by the security reviewers.

[Ballot comment]
I am agreeing with a comment from Adrian/Tim on velocity.


3.1.  Angular Measures and Coordinate Reference Systems

  [RFC5491] constrains the coordinate reference system (CRS) used in
  PIDF-LO to World Geodetic System 1984 (WGS 84) using either the two-
  dimensional (latitude, longitude) CRS identified by
  "urn:ogc:def:crs:EPSG::4326" or the two-dimensional (latitude,

s/two-dimensional/three-dimensional

  longitude, altitude) CRS identified by "urn:ogc:def:crs:EPSG::4979".

[Ballot comment]
I would also like to see some discussion of Adrian's comments.  I am particularly interested
in the decision to adopt the commonly used scalar definition of acceleration instead of the
vector definition of acceleration.  Was this considered?

[Ballot comment]
I'm not entering a Discuss, but I have a number of fairly strong Comments that I hope you will feel able to debate in email and make updates to the draft accordingly.

---

Your Abstract says...

  This document defines PIDF-LO extensions that are intended to convey
  information about moving objects.

Perhaps you could be a little more afirmative? Such as:

  This document defines PIDF-LO extensions to convey information about
  moving objects.

---

Why is the directional component of acceleration not supplied?

---

In Section 3.1

  The  and  establish a direction.

Aren't they both directions in their own right? And can't they be
different?

establishes a "direction of facing" while
establishes a "direction of travel".

---

In Section 3.1

  Angular
  measures are expressed in degrees and values MAY be negative.

Are you sure that this is an RFC 2119 "MAY"? Wouldn't "may" be perfectly
adequate?

---

In Section 3.1

  The first measure specifies the horizontal direction from the current
  position of the presentity to a point that it either pointing towards
  or travelling towards.

You (I hope) don't mean "either". Hopefully there is a little more
predictability! I think you mean:

  The first measure specifies the horizontal direction from the current
  position of the presentity to a point that it is pointing towards
  (for ) or travelling towards (for ).

---

In Section 3.1

  The second measure, if present, specifies the vertical component of
  this angle.  This angle is the elevation from the local horizontal
  plane.  If the second angle value is omitted, the vertical component
  is unknown and the speed measure MAY be assumed to only contain the
  horizontal component of speed.

Well, surely it is only if the second angle value of  is
omitted that you can make that assumption. If the second angle of
is absent, it says nothing about speed.

Additionally, when you say "MAY" in this case, it implies that the
normal case is something else that you have not stated.

---

Section 5

At the very least, you are introducing additional information that may
be distributed. Knowledge of that information makes a presentity more
vulnerable, therefore the definition of additional Presence Information
puts further weight behind the need to use security mechanisms.

[Ballot comment]
3.1.  Angular Measures and Coordinate Reference Systems

  [RFC5491] constrains the coordinate reference system (CRS) used in
  PIDF-LO to World Geodetic System 1984 (WGS 84) using either the two-
  dimensional (latitude, longitude) CRS identified by
  "urn:ogc:def:crs:EPSG::4326" or the two-dimensional (latitude,

s/two-dimensional/three-dimensional

  longitude, altitude) CRS identified by "urn:ogc:def:crs:EPSG::4979".

[Note]: 'LC will not have ended by the time this is on agenda but the odds are high there will be zero LC comments. If we decide to approve, I will hold a discuss on any LC comments. Richard Barnes (rbarnes@bbn.com) is the document shepherd.' added by Cullen Jennings

[Note]: 'LC will not have ended by the time this is on agenda but the odds are high there will be zero LC comments. If we decide to approve, I will hold a discuss on any LC comments.

Richard Barnes (rbarnes@bbn.com) is the document shepherd.' added by Cullen Jennings

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Richard Barnes is the document shepherd. He has reviewed the document
and believes that this document is suitable for publication as Proposed
Standard.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has had sufficient review from the GEOPRIV WG. This
document has been reviewed by Open Geospatial Consortium (OGC) members,
and while there were some reservations about the choice not to use GML,
the document was otherwise considered appropriate.

This document is the basis for existing work in the GEOPRIV WG
(draft-ietf-geopriv-loc-filters).

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

The document shepherd does not believe that additional review is needed.
There are no especially difficult items in the document. The usual
IETF LC review process should be adequate (including Gen-ART, SECDIR,
and so on).

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

This document was originally presented with an intended status of
experimental. However, the work has since matured considerably. Since
a GEOPRIV document (draft-ietf-geopriv-loc-filters) with an intended
status of proposed standard now relies on this document, the authors and
document shepherd believe that it is most appropriate to publish as
proposed standard.

(1.e) 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?

This document is being made as an individual submission, but this is
mostly due to working group work scheduling concerns and not with the
quality or suitability of the document. A number GEOPRIV participants
have contributed to this document through reviews or suggestions.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No appeal is anticipated.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The document contains no NITS. No formal review is required for this
publication.

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document correctly splits references into two sections. There are
no down-refs. There is one informational reference to an OGC document
that is already referenced in other standards track RFCs (RFC 5491).

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The IANA considerations section identifies an XML namespace and schema
that are registered in the IETF URN space. These correctly follow the
procedures in RFC 3688.

No registry is established by this document.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The XML schema and examples have been validated using Xerces-J 2.9.1.

(1.k) 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 extensions to the Presence Information Data Format
- Location Object (PIDF-LO) for presentity orientation, speed heading
and acceleration.

Working Group Summary

This is an AD-sponsored independent submission to the RFC editor.

Document Quality

There are currently no implementations of this specification. Extensive
reviews of the document have been made by several GEOPRIV participants;
each of whom are indicated in the acknowledgements.

Personnel

Richard Barnes is the Document Shepherd for this document.
Cullen Jennings is the Responsible Area Director.