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