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

From: "Roger Marshall" <[email-masked]>
Date: Sun, 24 Feb 2008 22:22:45 -0800

Part 2 - Richard's early comments (and my now, late responses) on the
lbyr -01 requirements.  

Please find my responses in-line, staging for -02.  
Thanks.

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 4:01 PM
> To: 'GEOPRIV'; Roger Marshall
> Subject: Comments on requirements in 
> draft-ietf-geopriv-lbyr-requirements-01
> 
> Part 1 in a three-part series.  
  ^^^^^^
  Part 2 (should have read part 2)

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

RSM - I guess there is a question of whether you have a configuration
protocol as a member of a location management protocol (suite?), or a
management protocol which also does the configuration part - and just
call it an LCP.  I don't see a huge difference, given that,
1. The LCP request initiates management action, that is, there is no
separate "management" request for the creation of the location URI
itself - it happens based on the request to receive a location URI.
2. The expiration of a location URI - could be viewed as a configuration
event, such as the target saying, "I'm giving up this location URI -
don't need it anymore - I'm getting unconfigured...".

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

RSM - good comment. text changed.

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

RSM - this discussion item has been extended on the list - will result
in additional requirements.

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

RSM - changed C5 language based on the C4 thread/discussion (Polk - Q2,
2/17).

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

RSM - this has been completely replaced by the 'valid-for' wording
similar to Polk's dhcp-uri-option draft (later thread).  Does it
satisfy, or is there a gap based on the original text, which has been
removed?

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

RSM - I'm ok with it, so I've changed the text.  There's been no
objection so far on the list to these D3/D4/D5 suggestions.

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

RSM - Yes.  Text changed.

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

RSM - Yep.  Phrase inserted, title & text also changed for clarity.

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

RSM - I can't tell for sure why these were removed... other than the
notion that you were building the security requirements in your doc.
Since you're the one bringing it up here, I've included back into the
next version of the doc D9 & D10, though slightly reworded from what is
written above.

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

RSM - same comment as above.

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.

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