Subject: [Geopriv] Comments on requirements in draft-ietf-geopriv-lbyr-requirements-01

From: Richard Barnes <[email-masked]>
Date: Thu, 06 Dec 2007 16:00:51 -0800

Part 1 in a three-part series.
1. Comments on introductory text
2. Comments on requirements
3. Comments on security considerations

First, the LCP requirements in here are really requirements for whatever
protocol you use to manage references, whether it's an LCP or not.  So I
would change this to discuss a management protocol for LbyR instead
(while "LbyR configuration protocol" is tempting, it would be confusing).

C2. Why is this a SHOULD?  What's the exception?  Also, this requirement
assumes that all location references have explicitly limited lifetimes,
which isn't necessarily true.  I would just modify this to say "When a
location URI has a limited validity interval, its lifetime MUST be
indicated."  Also, in the motivation, "Location URIs may not be intended..."

C4. This should be RECOMMENDED, the exception being when either (1) the
referenced location is public information or (2) the reference is
access-controlled.

C5. Again, this should be RECOMMENDED, same exceptions as above.

C7. This should be a MUST.  The client should always be able to
distinguish between "now" and "earlier".  What would the exception be?

D3. I would rephrase this as follows:
"The location dereference protocol MUST include mechanisms to
authenticate both the client and the server"
Also, the motivation for this requirement is false as written -- as
usual, implementation is not optional, but use in a given transaction
is.  Rephrase as:
"Although the implementations must support authentication of both
parties, any given transaction has the option not to authenticate one or
both parties."

D4. The phrase "MUST result" is unclear, but it sems like a statement
about the types of files that the dereference protocol can return.  I
hope it doesn't mean that the returned document MUST be of type
application/pidf+xml; you should allow for something (like HELD) that
returns a PIDF-LO inside a container.  How about this text:
"The value returned by the dereference protocol MUST contain a
well-formed PIDF-LO document."

D5. I would change "configuration server parameters" to "dereference
server configuration", in both the requirement and the motivation.

There are a couple of requirements from draft-marshall-...-00 that have
disappeared in the meantime, and that need to be brought back:
D6. Location Privacy:  The location dereference protocol MUST support
the application of privacy rules to the dissemination of a requested
location object.  The dereference server MUST obey all provisioned
privacy rules that apply to a requested location object.
D7. Location Confidentiality: The dereferencing protocol MUST support
mechanisms for encrypting messages sent between the derference client
and the dereference server.  It MUST also have a mode in which messages
are unencrypted.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 6 Dec 2007 19:51:30 -0600

Hi Richard,

I only have concerns with one of your comments, so I shall snip out the
rest.

> indicated."  Also, in the motivation, "Location URIs may not be

I believe that all location references must have a life time associated
with them, even if that life time is a very long one.

Cheers
James
------------------------------------------------------------------------------------------------
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: Richard Barnes <[email-masked]>
Date: Thu, 06 Dec 2007 22:40:31 -0800

James,

I think there are use cases in which references do not have explicitly 
limited lifetimes.  The canonical example is the presence case, in which 
the reference is my SIP URI.  I definitely don't want that URI to expire 
(for an indefinite period), nor do I want to categorically rule out 
indefinite subscriptions (e.g., for my mother).

In general, as we discuss LbyR, I think it's useful to keep two use 
cases in mind as endpoints in a continuum:
1. The presence use case: Location URI is very long-lived, access 
control is done by dereference.
2. The pawn ticket use case: Location URIs are short-lived, access 
control is done by controlling access to the reference.
I think we want to accommodate both of these in our requirements.

--Richard

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 7 Dec 2007 08:10:10 -0500

I completely agree that presence URIs (like a person's SIP URI) need to
be considered a form of LbyR. And my SIP URI had better not expire. I
think it's a good idea, though, to expect re-authentication of the
subscription from time to time. That would mean the subscription was not
indefinite. Since re-authentication can be an automated process handled
by the device, users can be made completely unaware of it.
Barbara

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Friday, December 07, 2007 1:41 AM
To: Winterbottom, James
Cc: GEOPRIV
Subject: Re: [Geopriv] Comments on
requirementsindraft-ietf-geopriv-lbyr-requirements-01

James,

--Richard

> with them, even if that life time is a very long one.
------------------------------------------------------------------------
------------------------
> this email is prohibited.
------------------------------------------------------------------------
------------------------

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623