Re: [Gen-art] Gen-ART review of draft-ietf-geopriv-lbyr-requirements-09

["Spencer Dawkins" <[e-mail]>]

Hi, Richard,

Yes, -09 does address all the comments I sent on -07.

Thanks for your quick response!

Spencer

----- Original Message ----- 
From: "Richard Barnes" <[e-mail]>
To: "Spencer Dawkins" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, November 30, 2009 4:39 PM
Subject: Re: Gen-ART review of draft-ietf-geopriv-lbyr-requirements-07


> Spencer,
>
> -09 is out now:
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-lbyr-requirements-09.txt
> >
> Does these changes address your concerns?
>
> --Richard
>
>
>
> On Oct 21, 2009, at 8:30 PM, Spencer Dawkins wrote:
>
>> Hi, Russ,
>>
>> I'm sorry, but I don't see text changes based on my comments in 
>> http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-lbyr-requirements/draft-ietf-geopriv-lbyr-requirements-08-from-07.diff.html .
>>
>> Some of them were nits, which aren't actually part of the Gen-ART 
>> review, but my concerns about 2119 language and a couple of  sentences 
>> that didn't parse probably are worth looking at (just  search for "pars" 
>> in my review).
>>
>> Thanks,
>>
>> Spencer
>>
>>
>>> Spencer:
>>>
>>> Draft -08 is on the telechat agenda for tomorrow.  Does it resolve  your 
>>> concerns?
>>>
>>> Russ
>>>
>>> At 06:47 PM 6/3/2009, Spencer Dawkins wrote:
>>>> I have been selected as the General Area Review Team (Gen-ART)
>>>> reviewer for this draft (for background on Gen-ART, please see
>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>>> Please resolve these comments along with any other Last Call  comments
>>>> you may receive.
>>>>
>>>> Document: draft-ietf-geopriv-lbyr-requirements-07
>>>> Reviewer: Spencer Dawkins
>>>> Review Date: 2009-06-03
>>>> IETF LC End Date: 2009-06-09
>>>> IESG Telechat date: (not known)
>>>>
>>>> Summary: This document is almost ready for publication as an 
>>>> Informational RFC.
>>>>
>>>> Comments: Most of my notes below involve text clarity. I did  question 
>>>> one 2119 keyword use in Section 4.1, as well.
>>>>
>>>>
>>>> 1.  Introduction
>>>>
>>>>  Location determination, different than location configuration or
>>>>
>>>> Spencer (clarity): Is this s/different than/as distinct from/ ?  but 
>>>> this sentence didn't parse for me.
>>>>
>>>>  dereferencing, often includes topics related to manual provisioning
>>>>  processes, automated location calculations based on a variety of
>>>>  measurement techniques, and/or location transformations, (e.g.,  geo-
>>>>  coding), and is beyond the scope of this document.
>>>>
>>>>  The issues around location configuration protocols have been
>>>>  documented in a location configuration protocol problem statement  and
>>>>  requirements document [I-D.ietf-geopriv-l7-lcp-ps].  There are
>>>>  currently several examples of a location configuration protocols
>>>>  currently proposed, including, DHCP
>>>>  [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD
>>>>
>>>> Spencer (clarity): got a reference for LLDP-MED here?
>>>>
>>>>  [I-D.ietf-geopriv-http-location-delivery] protocols.
>>>>
>>>>
>>>> 2.  Terminology
>>>>
>>>>  Location Configuration Protocol:  A protocol which is used by a
>>>>     client to acquire either location or a location URI from a
>>>>
>>>> Spencer (clarity): I'm guessing here that you mean s/either 
>>>> location/either a location object/
>>>>
>>>>     location configuration server, based on information unique to  the
>>>>     client.
>>>>
>>>> 3.3.  Location URI Authorization
>>>>
>>>>  Location URIs manifest themselves in a few different forms.  The
>>>>  different ways that a location URI can be represented is based on
>>>>  local policy, and are depicted in the following four scenarios.
>>>>
>>>>  1. No specific information at all:  As is typical, a location URI  is
>>>>
>>>> Spencer (clarity): could this be something more like "No location 
>>>> information included in the URI:"?
>>>>
>>>>     used to get location information.  However, in this case, the  URI
>>>>     representation itself does not need to reveal any specific
>>>>     information at all.  Location information is acquired by the
>>>>     dereferencing operation a location URI.
>>>>
>>>>  2. No user specific information:  By default, a location URI MUST  NOT
>>>>
>>>> Spencer (clarity): could this be "URI does not identify a user:"?
>>>>
>>>>     reveal any information about the Target other than location
>>>>     information.  This is true for the URI itself, (or in the  document
>>>>     acquired by dereferencing), unless policy explicitly permits
>>>>     otherwise.
>>>>
>>>> 3.4.  Location URI Construction
>>>>
>>>>  Depending on local policy, a location URI may be constructed in  such
>>>>  a way as to make it difficult to guess.  Accordingly, the form of  the
>>>>  URI is then constrained by the degree of randomness and uniqueness
>>>>  applied to it.  In this case, it may be important to protect the
>>>>  actual location information from inspection by an intermediate  node.
>>>>
>>>> Spencer (clarity): is this section applicable to all of the  scenarios 
>>>> in the previous section, or just to "possession  authorization model"? 
>>>> If not applicable to all, you might point  that out here.
>>>>
>>>>  Construction of a location URI in such a way as to not reveal any
>>>>  domain, user, or device specific information, with the goal of  making
>>>>  the location URI appear bland, uninteresting, and generic, may be
>>>>  helpful to some degree in order to keep location information more
>>>>  difficult to detect.  Thus, obfuscating the location URI in this  way
>>>>  may provide some level of safeguard against the undetected  stripping
>>>>  off of what would otherwise be evident location information,  since it
>>>>  forces a dereference operation at the location dereference  server, an
>>>>  important step for the purpose of providing statistics, audit  trails,
>>>>  and general logging for many different kinds of location based
>>>>  services.
>>>>
>>>> 4.1.  Requirements for a Location Configuration Protocol
>>>>
>>>>  C3. Location URI cancellation:  The location configuration protocol
>>>>     MUST support the ability to request a cancellation of a specific
>>>>     location URI.
>>>>
>>>>     Motivation: If the client determines that in its best interest  to
>>>>     destroy the ability for a location URI to effectively be used to
>>>>     dereference a location, then there should be a way to nullify  the
>>>>     location URI.
>>>>
>>>> Spencer (clarity): sorry, but can't parse this sentence. Something 
>>>> like "If the client determines that a location URI should no  longer 
>>>> provide a location, then there should be a way to nullify  the location 
>>>> URI"?
>>>>
>>>>  C5. User Identity Protection:  The location URI MUST NOT contain
>>>>     information that identifies the user or device.  Examples  include
>>>>     phone extensions, badge numbers, first or last names.
>>>>
>>>> Spencer (minor): this is probably a good idea, but I'm not sure  it's a 
>>>> 2119 MUST (NOT). How would you recognize this on the wire  (do you know 
>>>> what MY badge number is :-)?
>>>>
>>>>     Motivation: It is important to protect caller identity or  contact
>>>>     address from being included in the form of the location URI  itself
>>>>     when it is generated.
>>>>
>>>>  C7. Selective disclosure:  The location configuration protocol MUST
>>>>     provide a mechanism to control what information is being  disclosed
>>>>     about the Target.
>>>>
>>>> Spencer (clarity): not obvious who is controlling this disclosure 
>>>> until you get to the motivation sentence - perhaps "a mechanism 
>>>> allowing the Rule Maker to control ..."?
>>>>
>>>>     Motivation: The Rule Maker has to be in control of how much
>>>>     information is revealed during the dereferencing step as part of
>>>>     the privacy features.
>>>>
>>>>  C8. Location URI Not guessable:  As a default, the location
>>>>     configuration protocol MUST return location URIs that are random
>>>>     and unique throughout the indicated lifetime.  A location URI  with
>>>>     128-bits of randomness is RECOMMENDED.
>>>>
>>>>     Motivation: Location URIs should be constructed in such a way  that
>>>>     an adversary cannot guess them and dereference them without  having
>>>>     ever obtained them from the Target.
>>>>
>>>> Spencer (clarity): s/ever/previously/ ?
>>>>
>>>> 4.2.  Requirements for a Location Dereference Protocol
>>>>
>>>>  D1. Location URI support:  The location dereference protocol MUST
>>>>     support a location reference in URI form.
>>>>
>>>>     Motivation: It is required that there be consistency of use
>>>>     between location URI formats used in an configuration protocol  and
>>>>
>>>> Spencer (nit): s/in an/in a/
>>>>
>>>>     those used by a dereference protocol.
>>>>
>>>> 5.  Security Considerations
>>>>
>>>>  The method of constructing the location URI to include randomized
>>>>  components helps to prevent adversaries from obtaining location
>>>>  information without ever retrieving a location URI.  In the
>>>>  possession model, a location URI, regardless of its construction,  if
>>>>  made publically available, implies no safeguard against anyone  being
>>>>  able to dereference and get the location.  Care has to be paid when
>>>>  distribution such a location URI to the trusted location  recipients.
>>>>
>>>> Spencer (clarity): s/distribution/distributing/ ?
>>>>
>>>>  When this aspect is of concern then the authorization model has  to be
>>>>  chosen.  Even in this model care has to be taken on how to  construct
>>>>  the authorization policies to ensure that only those parties have
>>>>  access to location information that are considered trustworthy  enough
>>>>  to enforce the basic rule set that is attached to location
>>>>  information in a PIDF-LO document.
>>>>
>>>> _______________________________________________
>>>> Gen-art mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/gen-art
>>
>>
>