Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 comments

["Thomson, Martin" <[e-mail]>]

{S} New comment: a location URI, by necessity, indicates the server that hosts the location information.  This could reveal something about the location of the Target.  This is probably worthwhile noting as a security consideration.  This can be addressed, as with any other problem in this domain, by another layer of indirection: namely the use of a (remote) presence server.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Thomson, Martin
> Sent: Thursday, 10 July 2008 11:12 AM
> To: Roger Marshall
> Cc: GEOPRIV
> Subject: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 comments
> 
> Hi Roger,
> 
> I have quite a few editorial comments.  I apologise if this seems like
> a lot; I'm just suggesting a little restructuring to improve
> readability.
> 
> I have a few substantive comments (marked with {S}), but they are
> minor.
> 
> Based on my reading, I'd be happy to see this document published.  It
> would be good to be able to dispense with this particular Dec 2007
> milestone.
> 
> Cheers,
> Martin
> 
> ~~~
> 
> Section 1:
> 
>   It's unclear what the intent of the list in the introduction is.
> From the lead-in, it appears to be enumerating the uses of a location
> reference; the ways that a location URI provides benefit.  However,
> from points 2, 3 and 4, it appears to be describing behaviour.
>   I can't quite work out whether you intended there to be a distinction
> between point 1 and 2; if it was to separate creation from
> distribution, then I'm not sure that this is the correct way to present
> it.
> 
>   If the intent is to avoid discussion of possible uses/benefits of a
> location reference, it might just be best to introduce this as the
> "lifecycle" of a location reference.
>    Creation
>    Dissemination
>    Distribution (conveyance)
>    Dereference
>    Expiry/cancellation
>  Based on this you can then move to set the scope of the document.
> Note that creation, dissemination and cancellation/expiration fall
> under the auspices of location configuration protocols; dereference
> protocols for dereference; point out that conveyance is already
> adequately covered, so it wont be described in detail by the document.
> I don't think that any of this is missing, but I found it hard to get
> this without reading this bit over a couple of times.
> 
>   You can refer to draft-ietf-geopriv-l7-lcp-ps for the definition of
> 'LIS', as you do for RFC 3693 and 'LS'.  (Something for Section 2,
> which needs a definition for LIS)
> 
> Section 3:
> 
>   The first paragraph and the first part of the second paragraph of
> this section might be better suited to Section 1.  Section 1 lacks
> discussion on the motivation for this mechanism.
> 
>   The second part of the second paragraph (discussion of dereference
> protocols) would fit quite nicely with the discussion of configuration
> protocols from Section 1.
> 
>   If you move those, the section intro looks bare.  A vague/generic
> introduction statement will probably suffice: "This section describes
> the entities and interactions ,etc...."
> 
>   Your caption on Figure 1 is strange - the text is repeated on the
> next paragraph.  I assume that you intended something else here.  (for
> the XML format, you only need to use <figure anchor="arch"
> title="Location Reference Entities and Interactions">... and <xref
> target="arch"/>)
> 
>   Note B: s/authorize anything of than/authorize anything other than/
> 
>   Note C: s/Note C. that the/Note C.  The/
> 
>   Next paragraph: extraneous comma: s/via HELD, (/via HELD (/
> 
>   {S} Where you say that a geospatial boundary can be expressed to get
> an updated location when it crosses a boundary, you reference geopriv-
> policy.  While it is possible to use policy to restrict access to
> location information based on its value, policy cannot cause a
> notification to be sent once the condition is met.  This is another use
> for loc-filters.
> 
>   {S} Next paragraph: Justification for expiry needs to include
> security.  This is the primary use, particularly where references use
> the "possession" model.  Expiry limits the time that accidental leaking
> of a URI causes.  (from a requirements perspective I tend towards a
> MUST use, but would be happy with SHOULD use and MUST implement - c.f.
> HELD design).  I have another comment on Section 4 on this topic.
> 
>   Your statement on "access control" and "possession" states a
> requirement: "Dereference protocols must support both types."  It's
> probably not necessary to put this here (ahead of D11).
> 
>   I don't like the terms you've used for "use types".  The terms that
> used in draft-winterbottom-geopriv-deref-protocol (which was long ago
> agreed as a WG item) are better.  "authorization model" is good:
> "possession authorization model" and "access control authorization
> model" are clearer and consistent with the other work.
> 
>   {S} Your discussion of the Access control use type seems to imply
> that the LIS applies authentication and authorization on the location
> configuration protocol.  This isn't necessary - what it necessary is
> that the rule maker (owner/target) is able to provide authorization
> policies to the LIS during this stage, or through some other parallel
> mechanism (your interface 1b).  In fact, I would shift the focus from
> the LCP at this stage to concentrate on how policies are attached to a
> reference through an (undisclosed) mechanism.
> 
>   The paragraph after the two "use types" shouldn't be indented.
> 
> Section 4:
> 
>   {S} C3: For the possession model, this requirement is a MUST.
> 
>   {S} In addition to requirement C2 and C3, I'd like to see a SHOULD-
> strength requirement on expiry time.  Again, for the possession
> authorization model, this is a MUST.  The motivation for this is the
> similar to that for cancellation: the time that a reference can be used
> needs by unknown attackers needs to be limited.  If a user's LocURI
> gets leaked to an attacker, with an expiration time, the exposure is
> limited.
> 
>   {Semi-S} C8: change the name to "Location Only".
> 
>   {S} C7 and D6: These requirements pre-suppose a protocol
> implementation, namely that expiration needs to be indicated in
> relative terms.  (It also pre-supposes that people prefer seconds over
> other units, like microfortnights.)  I'd prefer the following
> requirement:
>     A configuration/dererefence protocol MUST provide an indication of
> the expiry time (or validity interval) for a location URI.
>   (Absolute and relative both have drawbacks.  Absolute suffers from
> problems when clocks are out of sync; relative time suffers from a
> period of uncertainty at the end of the interval due to the receiver
> not knowing when the interval started.  I prefer absolute, but I can
> appreciate how relative time indications use fewer bits.)
> 
>   {S} C11 and D11: Time saving is nice, but this isn't a hard
> requirement.  These are SHOULD requirements.
> 
> Section 5:
> 
>   Remove the lead-in sentence.
> 
>   Remove the "pawn ticket" reference and refer to the possession
> authorization model instead.
> 
> 
> ~~
> -----------------------------------------------------------------------
> -------------------------
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv