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

From: "Roger Marshall" <[email-masked]>
Date: Tue, 8 Jul 2008 16:51:08 -0700

Martin:
I agree with your suggestion of a random-unique concatenation, and so
there is some new text in the just posted next version, -03.

Sorry for the lateness of my response.

-roger. 

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2008 3:30 PM
> To: Roger Marshall; James M. Polk; Hannes Tschofenig
> Cc: GEOPRIV
> Subject: RE: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> 
> As James said, the point is that the URI be hard to guess iff 
> possession implies permission.
> 
> To implement the "hard to guess" bit we recommend a random number.
> However, that doesn't obviate the other requirement, which is 
> that a location URI must refer to a location - if it isn't 
> unique, then the server can't be sure which result to 
> provide.  Therefore, it needs to be BOTH unique and hard to guess.
> 
> There isn't anything preventing both uniqueness and 
> randomness from being used at the same time, just concatenate 
> a random number and sequence number together.  I note that 
> often people rely on the odds of a collision with massive 
> random numbers to provide an approximation of uniqueness.
> 
> Cheers,
> Martin
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Roger Marshall
> > Sent: Wednesday, 2 April 2008 9:05 AM
> > To: James M. Polk; Hannes Tschofenig
> > Cc: GEOPRIV
> > Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> > 
> > The Philly geopriv minutes reference a "129 bits of entropy...EKR 
> > statement..." - besides the obvious typo, the 128 bits of entropy
> there
> > related to the security draft,
> > http://www3.tools.ietf.org/html/draft-barnes-geopriv-lo-sec-02,
> whereas
> > the stuff below came from a couple of Richard's (and others)
> discussion
> > thread on Q3:
> > 
> > 1. a snippet of Richard's response of one such message...
> > 
> > R*: The dereference protocol MUST define an anonymized format for 
> > location URIs.  This format MUST identify the desired LO  
> by a random 
> > token with at least 128 bits of entropy (rather than an
> > !                          ^^^^^^^^^^^^^^^^^^^
> > explicit identifier, such as an IP address).  Any URI whose 
> > dereference will not subject to authentication and access 
> control MUST 
> > be anonymized.
> > 
> > Link to above message:
> > http://www.ietf.org/mail-archive/web/geopriv/current/msg05352.html
> > 
> > 
> > 2. ...also an earlier email talking about (base) number 
> examples which 
> > don't work...
> > 
> > Example 1: Using a 5-digit number doesn't work, because that's only
> 10k
> > queries, and I can write a script to run through those in a few 
> > minutes.
> > 
> >   Thus, you need more digits.
> > 
> > Example 2: Using a 32-byte number doesn't work if you assign it 
> > sequentially, since I can just start from the bottom and win a lot 
> > faster than at random.  Thus, the numbers need to be assigned at 
> > random.
> > 
> > Link to complete message:
> > http://www.ietf.org/mail-archive/web/geopriv/current/msg05346.html
> > 
> > What was the resolution between unique & random?  Whatever the
> outcome,
> > it should probably be inserted into the lbyr-requirements 
> draft, yes?
> > 
> > -roger marshall.
> > 
> > > -----Original Message-----
> > > From: James M. Polk [mailto:[email-masked]]
> > > Sent: Tuesday, April 01, 2008 1:36 PM
> > > To: Roger Marshall; Hannes Tschofenig
> > > Cc: GEOPRIV
> > > Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> > >
> > > Roger
> > >
> > > There were comments in Philly that 128 was an arbitrary number 
> > > without backing, so why was it picked.  There was also 
> discussion on 
> > > the difference between unique and random in Philly, which was 
> > > resolved -- but that doesn't mean either issue is dropped.
> > >
> > > James
> > >
> > > At 03:03 PM 4/1/2008, Roger Marshall wrote:
> > > >The following summarizes the third of the three original subj:
> > > >questions, Q1,Q2,Q3:
> > > >
> > > >Q3.
> > > >
> > > >...about draft-ietf-geopriv-lbyr-requirements-01
> > > >Sent: Friday, February 15, 2008 4:24 PM, From: James M. Polk
> > > >
> > > > >
> > > > > I may have missed the text, but I don't see it in a
> > > requirement --
> > > > > but at the last meeting, I was told by James W and Hannes
> > > that each
> > > > > LbyR URI MUST be unique.  I don't read that anywhere 
> in this ID.
> > > > >
> > > > > I read that "...it MUST be hard to guess..."
> > > > >
> > > > > why can't all 200 participants in the room draw from a
> > > smaller pool
> > > > > of numbers that a cryptographically random value?  It
> > > would still be
> > > > > "hard to guess" who has which identifier...
> > > >
> > > >Not much discussion here, but there seemed to be two
> > > differing views on
> > > >this:
> > > >
> > > >[a.] One view (Hannes) is that we need to add a new 
> requirement...
> > > >
> > > > > [...from...] Tschofenig, Hannes
> > > > > Sent: Sunday, February 17, 2008 3:48 AM
> > > > > Subject: Re: [Geopriv] Q3 about
> > > >draft-ietf-geopriv-lbyr-requirements-01
> > > > >
> > > > > Uniqueness is very important. The draft should really 
> have such
> a
> > > > > requirement. Saying that a part of the identifier is
> > > random is not
> > > > > enough.
> > > > >
> > > > > We need to add a requirement.
> > > >
> > > >[b.] the other view, (James P. responding to Richard's
> clarification
> > > >q's), seems to take some exception with the idea of a new req.
> > > >
> > > >[...from...] James M. Polk
> > > >Sent: Sunday, February 17, 2008 7:05 PM To: Richard Barnes;
> > > Tschofenig,
> > > >Hannes
> > > >Subject: Re: [Geopriv] Q3 about
> > > draft-ietf-geopriv-lbyr-requirements-01
> > > > >
> > > > > At 08:27 PM 2/17/2008, Richard Barnes wrote:
> > > > > >Could you two clarify what you mean by "unique"?
> > > > >
> > > > > well, this is part of what I was getting at. For example,
> > > within RFC
> > > > > 3261, the Call-ID value "MUST be unique through space and
> > > time" --
> > > > > meaning the alphanumeric value is never repeatable by any
> > > UA ever,
> > > > > not just within the same UA.
> > > > >
> > > > > This is reeeeally unique.
> > > > >
> > > > > I think this is more than we need here.
> > > > >
> > > > > >That is, within what scope should the URI be unique?
> > > > >
> > > > > I think a URI has to be unique within a LIS for all 
> clients that 
> > > > > have asked for one. I'm not sure we need to be any more
> > > unique than
> > > > > that.
> > > > >
> > > > > >Do you mean to prevent the LS from issuing multiple URIs
> > > > > that refer to
> > > > > >the same location?
> > > > >
> > > > > I actually don't see a problem in this... but I could be
> > > wrong (and
> > > > > want to know why I'm wrong BTW)
> > > > >
> > > > > >Or are you trying to rule out a case where an LS just hands
> > > > > out one URI
> > > > > >(or a few URIs), then hands out different LOs depending
> > > on who asks
> > > > > >(i.e., the LS uses one URI to refer to multiple LOs)?
> > > > >
> > > > > No, from my pov, unique means that a LIS has one unique
> > > URI for each
> > > > > client that has asked for one.
> > > > >
> > > > > I do not believe this URI has to be unique from 
> what's given out 
> > > > > tomorrow, as long as no two clients have the same URI.
> > > > > This is one of the uses of the valid-for parameter (that both
> the
> > > > > DHCP Option ID and HELD ID have).  My client shouldn't
> > > necessarily
> > > > > always be given the same URI, since there is no real guarantee
> it
> > > > > won't be compromised, someone will always have knowledge
> > > of my URI
> > > > > once they learn it once.
> > > > >
> > > > > Having my URI change periodically has a benefit, as 
> long as it 
> > > > > doesn't change sooner than the active timer of the 'valid-for'
> > > > > parameter is set (unless there's been a new request and a
> > > particular
> > > > > client's URI has been overwritten.
> > > >
> > > >SUMMARY:
> > > >I don't have any further record of any progression on the
> > > topic, which
> > > >kept me from adding said requirement in -02.  What should the 
> > > >resolution now be?
> > > >
> > > >Thanks.
> > > >
> > > >-roger marshall.
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of James M. Polk
> > > > > Sent: Monday, March 31, 2008 1:19 PM
> > > > > To: Hannes Tschofenig
> > > > > Cc: GEOPRIV
> > > > > Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02
> > ???
> > > > >
> > > > > At 07:53 AM 3/30/2008, Hannes Tschofenig wrote:
> > > > > >It seems that you are saying that Roger has to keep things
> > going.
> > > > >
> > > > > All I'm saying is that there was never a post
> > > articulating what the
> > > > > consensus reached answers were to each of the 3 questions
> > > I asked on
> > > > > the list.  I don't believe that is asking a lot. Do you
> > > think this
> > > > > is asking too much?
> > > > >
> > > > > Each of the 3 questions had ~ 5 to 75 responses, so there
> > > were a lot
> > > > > of folks interested in the questions, and obviously the first 
> > > > > response didn't answer any of the 3 Qs right away.
> > > > >
> > > > >
> > > > > >Roger, could you post a description of the outstanding
> > > issues with
> > > > > >a suggestions on how to address them?
> > > > > >
> > > > > >Ciao
> > > > > >Hannes
> > > > > >
> > > > > >James M. Polk wrote:
> > > > > > > At 12:40 PM 3/29/2008, Hannes Tschofenig wrote:
> > > > > > >> Given the status of HELD this document should have been
> > > > > finished a
> > > > > > >> while ago.
> > > > > > >> I am not even sure whether I have seen a WGLC for it.
> > > > > > >>
> > > > > > >> What are the next steps for it?
> > > > > > >> Why isn't it done already?
> > > > > > >
> > > > > > > weeeeelllll....
> > > > > > >
> > > > > > > There were 3 fairly substantiative questions posted
> > > > > against -01 of
> > > > > > > the ID just before the -0X deadline, and there needs to
> > > > > be time for
> > > > > > > proper review of -02 to see if this version answers at
> > > > > least these 3 questions.
> > > > > > >
> > > > > > > I think 1 has been answered
> > > > > > >
> > > > > > > I think another has not reached consensus
> > > > > > >
> > > > > > > and the last wasn't answered at all
> > > > > > >
> > > > > > > but this is memory (which may or may not be reliable)
> > > > > > >
> > > > > > >
> > > > > > >> _______________________________________________
> > > > > > >> Geopriv mailing list
> > > > > > >> [email-masked]
> > > > > > >> https://www.ietf.org/mailman/listinfo/geopriv
> > > > > >
> > > > > >_______________________________________________
> > > > > >Geopriv mailing list
> > > > > >[email-masked]
> > > > > >https://www.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > >
> > > >
> > > >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]
> > > >https://www.ietf.org/mailman/listinfo/geopriv
> > >
> > >
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > 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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 8 Jul 2008 16:55:14 -0700

James:
I have made some text changes in the just posted -03 version, in order
to try to accommodate your suggestion to make the distinction between
"access control" and "possession" models a little more clear.  Decided
not to fold it in to the abstract though, since to me it is not as
primary to the document as other things also not mentioned there.

I apologize for the tardiness in getting a response back to you.

-roger.

> Sent: Tuesday, April 01, 2008 6:16 PM
> To: Winterbottom, James; Roger Marshall; Hannes Tschofenig
> Cc: GEOPRIV
> At 05:18 PM 4/1/2008, Winterbottom, James wrote:
> >These requirements only make sense in the case where 
> possession of the 
> >URI is equivalent to possession of the data or resource at the other 
> >end of the URI. They may not apply in situations where 
> authentication, 
> >authorization and subsequent policy invocation occur prior 
> to the data 
> >or resource being made available to the requesting entity. 
> The degree 
> >to which the requestor is authenticated is application and 
> deployment 
> >specific.
> 
> None of this above is clearly articulated in the draft, and 
> if true, should be, including in the abstract.  Then I would 
> go along quietly about the ID and only point out nits  ;-)
> 
> >For example in an enterprise the mere fact that I am on the 
> enterprise 
> >network may be all the authentication that is required.
> >
> >Providing this clear division of location reference type is 
> made, I am 
> >not sure that I understand what the outstanding issue is.
> 
> If the possession model were made clearer in the draft (i.e., 
> that this model is the only model this doc is valid under), I 
> see little or no issues with the draft moving forward.
> 
> I have issues if the possession model is *not* the only model 
> to be used in this document.
> 
> 
> >Cheers
> >James
> >
> >
> [mailto:[email-masked]] On
> >Behalf
> > > Of Roger Marshall
> > > location URIs.  This format MUST identify the desired LO  by a
> > > random token with at least 128 bits of entropy (rather than an
> > > !                          ^^^^^^^^^^^^^^^^^^^
> > > control MUST be anonymized.
> > >
> > > Link to above message:
> > > > Subject: Re: [Geopriv] 
> draft-ietf-geopriv-lbyr-requirements-02 ???
> > > >
> > > > Roger
> > > >
> > > > There were comments in Philly that 128 was an arbitrary
> > > > number without backing, so why was it picked.  There was also
> > > > discussion on the difference between unique and random in
> > > > Philly, which was resolved -- but that doesn't mean either
> > > > issue is dropped.
> > > >
> > > > James
> > > >
> > > > > > LbyR URI MUST be unique.  I don't read that 
> anywhere in this ID.
> > > > > >
> > > > > > Uniqueness is very important. The draft should 
> really have such
> >a
> >-------------------------------------------------------------
> -----------------------------------
> >-------------------------------------------------------------
> -----------------------------------
> >[mf2]
> 
>

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 8 Jul 2008 16:59:29 -0700

James:
I don't agree that these requirements have meaning only to a
"possession" model of location URI.  Many, if not all also are
applicable to an "access control" model, and therefore I made no
restriction, though the text changed (mostly in section 3, "Overview of
Location-by-Reference").  The just posted -03 contains a brief change
log in an appendix, highlighting some of the more significant changes.

Again, please forgive the lateness of my response.  Catching up.

-roger marshall.

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2008 3:18 PM
> possession of the URI is equivalent to possession of the data 
> or resource at the other end of the URI. They may not apply 
> in situations where authentication, authorization and 
> subsequent policy invocation occur prior to the data or 
> resource being made available to the requesting entity. The 
> degree to which the requestor is authenticated is application 
> and deployment specific. For example in an enterprise the 
> mere fact that I am on the enterprise network may be all the 
> authentication that is required.
> 
> made, I am not sure that I understand what the outstanding issue is.
> 
> Cheers
> James
> 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Jul 2008 20:12:12 -0500

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.

~~
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 09 Jul 2008 22:06:51 -0500

At 08:12 PM 7/9/2008, Thomson, Martin wrote:
>   {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.

I have an issue with this statement about the draft.

SHOULD or MUST "use" is not up to a requirements document, I don't 
believe.  Protocol documents talk about the hazards of not enabling a 
function or capability, Requirements documents need to MUST virtually 
everything, otherwise the document is ambiguous.  Requirements 
documents are specifically for protocol designers, not for 
education.  The comment about "SHOULD use" is pointless unless it 
MUST be implemented, which is towards the coming standards track RFC authors.

I think that is confusing the point of a requirements document (i.e. 
it's for protocol authors).  Protocol documents have MUSTs and 
SHOULDs, which are towards implementors.  SHOULD need to always have 
a legitimate reason to ignore why a SHOULD is not created within a 
protocol and implemented by coders.

Therefore, I believe the "SHOULD use" point trying to be made here 
needs to be moved into the Intro section, to give another use-case or 
to give further justification for this protocol (to-be) to be designed.

my 1.75 cents

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Jul 2008 23:38:01 -0500

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

> 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.
> 
> 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
>  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"/>)
> 
>   {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.
> 
> 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.
> 
>   {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.
> 
>   {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:
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Jul 2008 23:48:22 -0500

I have this problem: I assume that people are able to extract meaning from what I write, rather than picking up on superficial details.  I stand by the statement, based on its intent.  I was making a comment, not a suggestion for text.  And it was for the intro section, if you hadn't noticed.

If you want to discuss the philosophy of requirements, there are rats in that hole.  I don't view a requirements document of this nature as being any different to a protocol document that specifies requirements for a protocol implementation.  SHOULD has a place in each as a way of allowing flexibility in implementation.

If you want a suggestion for text, here:

  C2. Location URI expiration:  A location URI SHOULD expire.  Location URIs that use authorization by possession MUST expire.

  Motivation: A location URI that is somehow acquired by an attacker could be used indefinitely unless the reference expires.  Cancellation only works if the Rule Maker or Target is aware that the URI has been stolen.  Expiration limits the loss of private data caused by exposure of the location URI.  Where authorization policies are employed, time limits in the authorization policy can be used to limit the impact of unintentional exposure; however, where possession implies authorization, an attacker could gain access to location information for an indefinite period.  

I think that this includes sufficient justification for the SHOULD.  In this case, as in other, MUST strength is unnecessary.  Too strict requirements would be an unnecessary impediment to protocol implementation.  In this case, I can envisage a protocol where the authorization policy is used and stable references are important.

Alternative text for C7:

  C7: Location URI expiration indication: A location configuration protocol MUST provide a means to indicate when a location URI expires.

  Motivation: As for existing C7.

Cheers,
Martin

> Sent: Thursday, 10 July 2008 1:07 PM
> To: Thomson, Martin; Roger Marshall
> Cc: GEOPRIV
> Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 comments
>

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 30 Jul 2008 06:21:15 -0700

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.

> 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.
> 
> >   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.
> > 
> > notification to be sent once the condition is met.  This is another 
> > use for loc-filters.
> > 
> > the "possession" model.  Expiry limits the time that accidental 
> > towards a MUST use, but would be happy with SHOULD use and 
> MUST implement - c.f.
> > 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.
> > 
> ----------------------------------------------------------------------
> > -
> > -------------------------
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> 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.