Skip to main content

Filtering Location Notifications in the Session Initiation Protocol (SIP)
draft-ietf-geopriv-loc-filters-11

Revision differences

Document history

Date Rev. By Action
2012-08-22
11 (System) post-migration administrative database adjustment to the Yes position for Robert Sparks
2012-08-22
11 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-06-15
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-06-15
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-06-15
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-06-04
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-06-04
11 (System) IANA Action state changed to In Progress
2010-06-04
11 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-06-04
11 Amy Vezza IESG state changed to Approved-announcement sent
2010-06-04
11 Amy Vezza IESG has approved the document
2010-06-04
11 Amy Vezza Closed "Approve" ballot
2010-06-04
11 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2010-05-31
11 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-05-26
11 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2010-05-16
11 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2010-05-13
11 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko
2010-05-13
11 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2010-04-13
11 Robert Sparks Responsible AD has been changed to Robert Sparks from Cullen Jennings
2010-04-13
11 Robert Sparks [Note]: 'LC end Mar 10
The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).' added by Robert Sparks
2010-04-05
11 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to Yes from No Objection by Robert Sparks
2010-04-05
11 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks
2010-04-02
11 Robert Sparks
[Ballot comment]
===Comments below pertained to -10 and have been addressed===

Section 3.6 should be more clear on whether it is restricting the use of …
[Ballot comment]
===Comments below pertained to -10 and have been addressed===

Section 3.6 should be more clear on whether it is restricting the use of all the mechanics in event-rate-control, or only noting which of those mechanics need to be used to achieve the purpose addressed in this draft. In particular, I suggest changing "The implementation of only these two attributes" to "The use of only these two attributes".

Ben Campbell's genart review comments are related.

These are very small nits:

2nd paragraph of 3.3 would read more correctly if you said A1, A2, A3 _and_ PC change.

is a typo

The labels for figure 3 and 4 are wrong - should say Element Value Change Example
2010-04-02
11 Robert Sparks [Ballot discuss]
(Adopted from Cullen Jennings) : AD needs to review LC comments
2010-03-27
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-03-27
11 (System) New version available: draft-ietf-geopriv-loc-filters-11.txt
2010-03-15
11 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Lt. Mundy.
2010-03-11
11 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-03-11
11 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2010-03-11
11 Dan Romascanu
[Ballot comment]
1. The draft could use a careful editing for English usage.  Some
problems are simple statement structure (e.g., "This document defines
a new …
[Ballot comment]
1. The draft could use a careful editing for English usage.  Some
problems are simple statement structure (e.g., "This document defines
a new event filters and describes others using existing mechanisms
that may be relevant to a subscriber in the context of location
filtering:" does not grammatically connect to the following list).
Other problems leave out information (e.g., the text of section 3.1
does not state that the  element is a child of the
element, although the example makes that clear).

2. Section 3.2, speed changes:  The statement "An implementation MUST
support the functionality as shown in Figure 2 with
replacing the prefix.  No other variant is supported." is nowhere near
clear enough to be a specification.

3. Section 3.6, rate control:  It might be useful to provide a more
extended example than figure 9, one that shows the initial SUBSCRIBE
and NOTIFY, and the subsequent SUBSCRIBE that lengthens the
max-interval value.
2010-03-11
11 Dan Romascanu
[Ballot discuss]
The DISCUSS and COMMENT issues are based on input from Dale Worley.

The following items are problematic as they point to ambiuities in …
[Ballot discuss]
The DISCUSS and COMMENT issues are based on input from Dale Worley.

The following items are problematic as they point to ambiuities in the specification:

1. Section 3.3, element value changes:  In the example, changes in the
subordinate civic address components "A1", "A2", etc. will cause a
trigger, but changes in "country" will not.  This is probably
unrealistic; in a realistic application, a trigger on one civic
address component would be or'ed with triggers on each higher-level
civic address component.

2. Section 3.3, element value changes:  The statement "An
implementation MUST support the functionality as shown in Figure 3
with  replacing the prefix.  No other variant is
supported." is nowhere near clear enough to be a specification.  In
particular, the uses in figures 4 and 5 are clearly distinguishable
from the use in figure 3 (based on the number of  and
elements).
2010-03-11
11 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2010-03-11
11 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-03-11
11 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-03-11
11 Adrian Farrel
[Ballot comment]
I found the second paragraph of Section 1 hard to parse

  The frequency of notifications necessary for various geographic
  location applications …
[Ballot comment]
I found the second paragraph of Section 1 hard to parse

  The frequency of notifications necessary for various geographic
  location applications varies dramatically.  The subscriber should be
  able to get asynchronous notifications with appropriate frequency and
  granularity, without having to issue a large number of notifications
  that are not important to the application.

The second sentence appears to mix "getting" notifications with "issuing" notifications. Are you attempting to distinguish asynchronous notifictations from requst/response transactions?

---

Nit of the smallest type

Section 1
s/that allows the number/that allow the number/
2010-03-11
11 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2010-03-10
11 Jari Arkko
[Ballot discuss]
This is a good document and I was ready to ballot Yes. However, like
other reviewers I had trouble with the normative requirements. …
[Ballot discuss]
This is a good document and I was ready to ballot Yes. However, like
other reviewers I had trouble with the normative requirements. In my
case Section 3.3 said:

  An implementation MUST support the functionality as shown in Figure 3
  with  replacing the prefix.  No other variant is
  supported.

I do not understand what to implement based on this. In particular,
Section 3.3 has also Figure 4 that shows another variant. Is only the
first one required to be supported? What exactly does "MUST support
this example snippet of XML" mean?
2010-03-10
11 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-03-10
11 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2010-03-10
11 Russ Housley
[Ballot comment]
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns
  that are not included in my DISCUSS position.  Please …
[Ballot comment]
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns
  that are not included in my DISCUSS position.  Please consider them.
2010-03-10
11 Russ Housley
[Ballot discuss]
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns
  that ought to be addressed before this document is …
[Ballot discuss]
The Gen-ART Review by Ben Campbell on 9 March 2010 raised some concerns
  that ought to be addressed before this document is approved, and I have
  summarized them below.
 
  (1) Section 3.6 seems to create a profile of the rate-control
      document, but minor modifications to the normative requirements
      are made.  Can you motivate why rate-control does not work as-is?
      If not, perhaps the two documents should be harmonized.

  (2) The empty notify language in the 2nd paragraph of Section 3.6
      seems to conflict with the MUST statements in rate-control
      document:
      >
      > ... depending on the event package and subscriber
      > preferences indicated in the SUBSCRIBE request, the NOTIFY request
      > MUST contain either the current full state or the partial state
      > showing the difference between the current state and the last
      > successfully communicated state.
      >
      This also indicates that the two documents should be harmonized.

  (3) In Section 3.2, first paragraph after figure 2, the text effectively
      declares the example as normative, but fails to offer normative text.
      Also, the "No other variant" language is confusing; it is not clear
      what restriction in the example is constrains .  Please
      make the examples informative and provide normative text.
2010-03-10
11 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2010-03-10
11 Robert Sparks
[Ballot comment]
These are very small nits:

2nd paragraph of 3.3 would read more correctly if you said A1, A2, A3 _and_ PC change.

is …
[Ballot comment]
These are very small nits:

2nd paragraph of 3.3 would read more correctly if you said A1, A2, A3 _and_ PC change.

is a typo

The labels for figure 3 and 4 are wrong - should say Element Value Change Example
2010-03-10
11 Robert Sparks
[Ballot discuss]
Section 3.6 should be more clear on whether it is restricting the use of all the mechanics in event-rate-control, or only noting which …
[Ballot discuss]
Section 3.6 should be more clear on whether it is restricting the use of all the mechanics in event-rate-control, or only noting which of those mechanics need to be used to achieve the purpose addressed in this draft. In particular, I suggest changing "The implementation of only these two attributes" to "The use of only these two attributes".

Ben Campbell's genart review comments are related.
2010-03-10
11 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2010-03-10
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-03-09
11 Lars Eggert
[Ballot comment]
Non-blocking comments:

Section 3.1., paragraph 1:
>    The  element MUST contain a value in meters indicates the
>    minimum distance that …
[Ballot comment]
Non-blocking comments:

Section 3.1., paragraph 1:
>    The  element MUST contain a value in meters indicates the
>    minimum distance that the resource must have moved from the location
>    of the resource since the last notification was sent in order to
>    trigger this event.  Note that the condition could be met by a change
>    in any axis including altitude.

  But surely not only by change along a single axis, right? (I think
  what you mean is that the length of the vector between the two points
  is longer than .)


Section 5.2.3, paragraph 1:
>    If the Target was previously outside the region, the notifier sends a
>    notification when the Target's location is within the region with at
>    least 50% confidence.  Similarly, when a Target starts within the
>    region, a notification is sent when the Target's location moves
>    outside the region with at least 50% confidence.

  Why 50%? Why not 30 or 70%? (Magic number.)


Section 5.2.3, paragraph 2:
>    Note that having 50% confidence that the Target is inside the area
>    does not correspond to 50% outside.  The confidence that the location
>    is within the region, plus the confidence that the location is
>    outside the region is limited to the confidence of the location.  The
>    total confidence depends on the confidence in the location, which is
>    always less than 100% (95% is recommended in [RFC5491]).  The benefit
>    of this is that notifications are naturally limited: small movements
>    at the borders of the region do not trigger notifications.

  Whether the last sentence is true depends entirely on how accurate the
  positioning is compared to the movement.


Section 9., paragraph 0:
> 9.  References

  idnits reports several unused references, including normative ones.


Section 3.3., paragraph 5:
>    In times where it is desireable to know if any one element of a list

  Nit: s/desireable/desirable/
2010-03-09
11 Lars Eggert
[Ballot discuss]
Section 9.1., paragraph 2:
>    [I-D.ietf-geopriv-arch]
>              Barnes, R., Lepinski, M., Cooper, A., Morris, …
[Ballot discuss]
Section 9.1., paragraph 2:
>    [I-D.ietf-geopriv-arch]
>              Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
>              Tschofenig, H., and H. Schulzrinne, "An Architecture for
>              Location and Location Privacy in Internet Applications",
>              draft-ietf-geopriv-arch-01 (work in progress),
>              October 2009.

  DISCUSS: Downref: Normative reference to an Informational draft:
  draft-ietf-geopriv-arch (ref. 'I-D.ietf-geopriv-arch'). Didn't see it
  called out in the IETF LC.
2010-03-09
11 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2010-03-08
11 Cullen Jennings [Ballot discuss]
AD needs to review LC comments
2010-03-08
11 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Yes by Cullen Jennings
2010-03-08
11 Cullen Jennings State Changes to IESG Evaluation from In Last Call by Cullen Jennings
2010-03-08
11 Cullen Jennings [Note]: 'LC end Mar 10
The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).' added by Cullen Jennings
2010-03-08
11 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings
2010-03-08
11 Cullen Jennings Ballot has been issued by Cullen Jennings
2010-03-06
10 (System) New version available: draft-ietf-geopriv-loc-filters-10.txt
2010-03-05
11 Alexey Melnikov
[Ballot comment]
3.3.  Element Value Changes

  Figure 3 shows an example where a notification is sent when the civic
  address tokens A1, A2, …
[Ballot comment]
3.3.  Element Value Changes

  Figure 3 shows an example where a notification is sent when the civic
  address tokens A1, A2, A3, or PC change (all 4 must change in order
  to let the  element evaluate to TRUE).  In times where it is
  desireable to know if any one individual of a list of CAtypes change,
  then they have to be put into separate  filters to ensure
  you are notified when any of the element values change.

In the last sentence: do you mean something like:

     
         
              //ca:A1
         
         
              //ca:A2
         
         
              //ca:A3
         
         
              //ca:PC
         
     

instead of:

     
         
              //ca:A1
              //ca:A2
              //ca:A3
              //ca:PC
         
     

?

3.5.  Location Type:

 
 
     
         
                geodetic

Are leading spaces insignificant in this case?

             
         
     
 
2010-03-05
11 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2010-03-05
11 Alexey Melnikov Created "Approve" ballot
2010-03-03
11 Amanda Baber
IANA comments:

Action 1:

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

ID URI Registration …
IANA comments:

Action 1:

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

ID URI Registration template Reference
-- --- --------------------- ---------
location-filter urn:ietf:params:xml:ns:location-filter location-filter
[RFC-geopriv-loc-filters-09]


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
-- --- -------- ---------
location-filter urn:ietf:params:xml:schema:location-filter location-filter
[RFC-geopriv-loc-filters-09]


We understand the above to be the only IANA Actions for this document.
2010-02-25
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Lt. Mundy
2010-02-25
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Lt. Mundy
2010-02-24
11 Cullen Jennings Telechat date was changed to 2010-03-11 from 2010-03-04 by Cullen Jennings
2010-02-24
11 Cullen Jennings Placed on agenda for telechat - 2010-03-04 by Cullen Jennings
2010-02-24
11 Cindy Morgan Last call sent
2010-02-24
11 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2010-02-24
11 Cullen Jennings Last Call was requested by Cullen Jennings
2010-02-24
11 Cullen Jennings State Changes to Last Call Requested from AD Evaluation by Cullen Jennings
2010-02-24
11 (System) Ballot writeup text was added
2010-02-24
11 (System) Last call text was added
2010-02-24
11 (System) Ballot approval text was added
2010-02-24
11 Cullen Jennings State Changes to AD Evaluation from Publication Requested by Cullen Jennings
2010-01-15
11 Amy Vezza
The GEOPRIV working group requests publication of draft-ietf-geopriv-
loc-filters-09 as Proposed Standard.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd …
The GEOPRIV working group requests publication of draft-ietf-geopriv-
loc-filters-09 as Proposed Standard.

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

The Document Shepherd for this document is Richard Barnes. The
Shepherd has personally reviewed this version of the document, and
believes it is ready for publication.

(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 been the subject of thorough discussion within the
GEOPRIV and SIMPLE working groups. I have no concerns about the level
of review this document has received.

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

I do not believe that this document requires any special review. It
does contain XML schemas, but the structures it defines are simple and
have been reviewed by members of the working group with XML expertise.

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

I have no special concerns about this document. There have been no
IPR disclosures related to the document.

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

There is fairly wide consensus in the working group that this document
is a useful and usable way to encode geolocation-based event filters.

(1.f) 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
entered into the ID Tracker.)

I am not aware of any extreme discontent or potential appeals related
to this document.

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

I have verified that the the document satisfies all ID nits, with the
exception of some reference problems discussed below.

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

References are split into normative and informative, but need some
clean-up (which can be rolled in with responses to last-call and IESG
comments). There is one downref, a normative reference to an
Informative document, which I believe can be made into an informative
reference.


(1.i) Has the Document Shepherd verified that the document IANA
consideration 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 [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, and provides instructions for
IANA to register a new XML schema and namespace.

(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 document contains two XML schemas and several example XML
documents. I have validated that these XML structures are well-formed
using the W3C automated validator ().

(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 describes filters that limit asynchronous location
notifications to compelling events, designed as an extension to RFC
4661
, an XML-based format for event notification filtering, and based
on RFC 3856, the SIP presence event package. The resulting location
information is conveyed in existing location formats wrapped in the
Presence Information Data Format Location Object (PIDF-LO).


Working Group Summary

There is consensus in the working group that the policies described
this document are a useful way to transmit geolocation-based event
filters.


Document Quality

The document has been reviewed by key participants from the GEOPRIV
working group.
2010-01-15
11 Amy Vezza [Note]: 'The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).' added by Amy Vezza
2010-01-15
11 Amy Vezza Earlier history may be found in the Comment Log for draft-mahy-geopriv-loc-filters.
2009-12-28
09 (System) New version available: draft-ietf-geopriv-loc-filters-09.txt
2009-11-09
08 (System) New version available: draft-ietf-geopriv-loc-filters-08.txt
2009-10-26
07 (System) New version available: draft-ietf-geopriv-loc-filters-07.txt
2009-09-15
06 (System) New version available: draft-ietf-geopriv-loc-filters-06.txt
2009-07-27
05 (System) New version available: draft-ietf-geopriv-loc-filters-05.txt
2009-07-13
04 (System) New version available: draft-ietf-geopriv-loc-filters-04.txt
2009-05-07
11 (System) Document has expired
2008-12-02
11 (System) Earlier history may be found in the Comment Log for draft-mahy-geopriv-loc-filters.
2008-12-02
11 (System) Draft Added by the IESG Secretary in state 0.  by system
2008-11-04
03 (System) New version available: draft-ietf-geopriv-loc-filters-03.txt
2008-07-14
02 (System) New version available: draft-ietf-geopriv-loc-filters-02.txt
2007-03-07
01 (System) New version available: draft-ietf-geopriv-loc-filters-01.txt
2006-03-22
00 (System) New version available: draft-ietf-geopriv-loc-filters-00.txt