Subject: [Geopriv] draft-ietf-geopriv-lbyr-requirements-06 feedback

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 25 Feb 2009 22:52:37 -0600

Hi Roger,

Reviewing the changes since the last version, I have a few comments.  Nothing that is crucial, certainly nothing that would make prevent this from being presented to the IESG.

Section 1. first paragraph: the following statement is without support and is in fact not helpful in this context.

	... Within this document, the use of location information
	is constrained according to specific policies included in
	[I-D.ietf-geopriv-policy].

Can you please remove this sentence.

The following statement has implications that could be misconstrued:

      Despite the standard technique of passing	
	location directly in SIP, ...

This implies that SIP is _the_ way.  I know that suggesting otherwise might be consider blasphemous, but I'd like to think that location has wider applicability than one specific signalling protocol.  No problem with using SIP as a f'rinstance, but statements of this nature carry an implication of some sort of special status.

My suggestion is to replace that sentence and the ensuing text with:

	For LbyV, location information is conveyed directly in the
 	form of a PIDF-LO (4119, blahblah).  Using LbyV might either
	be infeasible or undesirable in some circumstances.  There are
	cases where LbyR is better able to address location requirements
	for the specific architecture or application.  This document ...

Your definitions of Location-by-Value and Location-by-Reference are much shorter, but they suggest nouns.  We already have nouns for this case: LO and location URI respectively.  These terms are more verb-y.  Suggest instead:

	Location-by-Value (LbyV): Conveying location information in
	    the form of a location object (LO), such as a PIDF-LO.

	Location-by-Reference (LbyR): Conveying location information
	    indirectly using a location URI.

(minor: suggest using "reference" rather than "pointer" when defining Location URI)

Grammar nit in Section 3 (right above 3.1), misplacement of "is":

   This is communications path, (*), out of scope for this document.

I found Section 3.4 to be a little hard to read.  There are the requirements and the motivation, which are in Section 4 already, but this text doesn't add that much other than some interesting embellishments.  Such as "bland, uninteresting, and generic", which - objectively - don't actually mean anything.

Might I suggest that Section 3.4 be reduced to four points:

(1. background: no need for any information in the URI at all)

  Location URIs are intended to convey location information.  However, the URI representation itself does not need to reveal any information at all.  Location information is acquired by dereferencing a location URI.

(2. no user specific information)

  In all cases, a location URI cannot (or MUST NOT) reveal any information about the Target other than location information.  Either in the URI itself, or in the document acquired by dereferencing, unless policy explicitly permits otherwise.

(3. access control means that unauthorized recipients can't get the information)

  If the "access control authorization" model is used, the location URI cannot include any location information in its representation.  Location URIs operating under this model could be widely published to recipients that are not authorized to receive this information.

(4. possession means that the URI is a secret)

  If the "possession authorization" model is used, the location URI is confidential information shared between the LIS/LS, the Device and all authorized Location Recipients.  Because knowledge of the location URI is used to authenticate and authorize access to location information, the URI needs to include sufficient randomness to make guessing its value difficult.  A possession model URI can include location information in its representation.

(Note that the AoR statement goes - point 2 states that this is possible, but only if policy permits it.  Certainly it can't be used for possession model unless other provisions were made.)

Cheers,
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]

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 26 Feb 2009 08:14:05 -0800

Martin:
Thanks for the feedback.  

I added the first paragraph text only because the draft still had an
unreferenced geopriv-policy draft reference - something which I have no
objection to removing altogether.

I agree with all the other recommendations that you've made, and will do
a quick revision.

-roger.

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]] 
> Sent: Wednesday, February 25, 2009 8:53 PM
> To: Roger Marshall
> Cc: GEOPRIV
> Subject: draft-ietf-geopriv-lbyr-requirements-06 feedback
> 
> Hi Roger,
> 
> Reviewing the changes since the last version, I have a few 
> comments.  Nothing that is crucial, certainly nothing that 
> would make prevent this from being presented to the IESG.
> 
> 
> Section 1. first paragraph: the following statement is 
> without support and is in fact not helpful in this context.
> 
> This implies that SIP is _the_ way.  I know that suggesting 
> otherwise might be consider blasphemous, but I'd like to 
> think that location has wider applicability than one specific 
> signalling protocol.  No problem with using SIP as a 
> f'rinstance, but statements of this nature carry an 
> implication of some sort of special status.
> 
> Your definitions of Location-by-Value and 
> Location-by-Reference are much shorter, but they suggest 
> nouns.  We already have nouns for this case: LO and location 
> URI respectively.  These terms are more verb-y.  Suggest instead:
> 
> I found Section 3.4 to be a little hard to read.  There are 
> the requirements and the motivation, which are in Section 4 
> already, but this text doesn't add that much other than some 
> interesting embellishments.  Such as "bland, uninteresting, 
> and generic", which - objectively - don't actually mean anything.
> 
>   Location URIs are intended to convey location information.  
> However, the URI representation itself does not need to 
> reveal any information at all.  Location information is 
> acquired by dereferencing a location URI.
> 
>   In all cases, a location URI cannot (or MUST NOT) reveal 
> any information about the Target other than location 
> information.  Either in the URI itself, or in the document 
> acquired by dereferencing, unless policy explicitly permits otherwise.
> 
>   If the "access control authorization" model is used, the 
> location URI cannot include any location information in its 
> representation.  Location URIs operating under this model 
> could be widely published to recipients that are not 
> authorized to receive this information.
> 
>   If the "possession authorization" model is used, the 
> location URI is confidential information shared between the 
> LIS/LS, the Device and all authorized Location Recipients.  
> Because knowledge of the location URI is used to authenticate 
> and authorize access to location information, the URI needs 
> to include sufficient randomness to make guessing its value 
> difficult.  A possession model URI can include location 
> information in its representation.
> 
> 
> (Note that the AoR statement goes - point 2 states that this 
> is possible, but only if policy permits it.  Certainly it 
> can't be used for possession model unless other provisions were made.)
> 
> Cheers,
> Martin

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.