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

["Roger Marshall" <[e-mail]>]

Martin:
Thanks very much for these comments.  These have remained on the list
now for a few weeks with no objections (that have not been resolved).
Since I too have no objection to anything I see here, and presuming no
major objections based on tomorrow's status update in the geopriv
meeting, I plan to fold these changes in, rev the draft, and recommend
to the wg chairs that the doc go to WGLC.

-roger marshall.

> -----Original Message-----
> From: Thomson, Martin [mailto:[e-mail]] 
> Sent: Wednesday, July 09, 2008 9:38 PM
> To: Roger Marshall
> Cc: GEOPRIV
> Subject: RE: [Geopriv] 
> draft-ietf-geopriv-lbyr-requirements-02 comments
> 
> {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]
> 


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