Subject: [Geopriv] Review of draft-marshall-geopriv-lbyr-requirements-00

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 20 Feb 2007 16:50:35 -0600

I've had a read through this draft and I have some comments.

Feel free to split off threads from this to address individual points; it's a long email.

~ General

I like the formatting and style of the document.  It is quite clear and easy to read.

Two cases are conflated in this document:

 - The case where a LIS (in the access network) provides a reference
   is the case that the document should address.

 - The other case, where an LS provides a reference, is moot.  I can
   already publish a PIDF-LO to a presence server (LS) and my AoR
   suffices as a reference.  I don't think that anyone has suggested
   that this use case requires a new set of protocols.  Thankfully,
   the draft only touches on this case occasionally.

It is also useful to discuss (perhaps with reference to another
document) some of the properties of a location reference.  We have
highlighted two forms (pawn ticket where possession implies permission
and identifiers that are public which are protected by privacy rules
at the de-reference server), and these drive some of the requirements.

~ Section 3

Section 3.1 - I see no reason to diverge from RFC 3693 terminology
except in the case of LS.  The term LIS is well understood in this
context and clearly highlights the one case that is applicable in this
context.

Section 3.2 - I believe that there are three actors in this scenario:
the LIS, the Target and the Location Recipient.  It wasn't clear
whether "de-reference protocol client" meant Target or LR.

~ Section 4

I predict that this section will be contentious.

The model that you present is too specific to the ECRIT model. A
better approach would initially show the model with the significant
three actors (crude diagram):

          __<acquire<__     __<dereference<__
         /             \   /                 \
  + Target +         +  LIS  +             +  LR +
        \                                    /
         \_________>convey reference>_______/

A specific example of how that model applies to a "real world" case,
such as ECRIT would be helpful, but only once the paradigms have been
established.  Using such a specific case entangles the conceptual
aspects too closely.

Based on my general comment, the required scenarios are reduced to
two:
  2. Location provision from LIS by reference.
  3. Location indirection by the LIS, at the request of the Target.

Location updates, such as you suggest in the fourth interaction
described, are possible in either case.  However, this is not
limited to PSAP only.

~ Section 5

In general, the requirements are sound.  However, it might do to
identify which protocols these requirements apply to.  There are
three protocols in the LbyR case (as opposed to two for LbyV):
acquistion, conveyance, and de-reference.

Rq1. - Interesting point, to which I will ask a question for my
amusement.  Why is this necessarily a requirement?  Obviously,
this is a fairly trivial requirement to satisfy based on the
existing candidates.  However, a location acquisition protocol
could be provided that did not support this and instead relied on
the dereference protocol. (or does that satisfy the requirement
by-proxy?)

Rq3. - suggest an extra sentence: "If both LbyR and LbyV can be
conveyed, the conveyance protocol MUST provide guidance on how a
recipient selects one or other." (or something to that effect,
c.f. pidf-lo-profile)

Rq4. - I presume that the motivation for this is that the
reference could (depending on its properties) be stolen and used
by other than those the Target intends.  This extends to Rq5.,
being the case where the Target relies on rules to protect
privacy.

Rq6. "location reference uri" -> "location reference identifier"

 - This requirement (to me) implies that an expiry time is encoded
   in the identifier.  I think that the requirement is that any
   mechanism that provides a location reference must also provide
   a way to limit the validity of that reference (and should also
   provide a way to extend or shorten the validity period).

nit: Rq9.''
nit: Rq12 motivation unclosed parentheses

~ Section 6

Is this an ECRIT document?  I'd prefer to see some security
considerations here.  the l7-lcp-ps document might be a good
reference, but it doesn't cover everything.  Off the top of my head
the considerations need to discuss privacy, theft of a location
reference and the impact of the two forms of location reference.

Regards,
Martin 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv