Subject: [Geopriv] Fwd: RE: lbyr-uri-option question

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 May 2008 12:56:49 -0500

Hannes, I apologize for indicating this was directed at Richard, and not you.

(Richard, I'm sorry too  ;-)

>Date: Mon, 19 May 2008 12:55:00 -0500
>To: <[email-masked]>
>From: "James M. Polk" <[email-masked]>
>Subject: RE: [Geopriv] lbyr-uri-option question
>
>Richard
>
>comments in-line
>
>At 01:18 PM 5/17/2008, [email-masked] wrote:
>>Hi Robert,
>>Hi James,
>>
>>I read through the document and I have a couple of comments.
>>
>>
>>-- URIs
>>
>>
>>"
>>Dereferencing can be done in SIP by
>>    use of the SUBSCRIBE/NOTIFY Methods [RFC3265] to either a sip:,
>>    sips: or pres: scheme URI.  Each of these URI schemes are IANA
>>    registered in Section 5 of this document as valid for use by this
>>    Option.
>>"
>>
>>I would like to see you also speaking about the HTTPS-based URI.
>>Respectively, Section 4.2 must be updated.
>
>SIP Location Conveyance explicitly doesn't specify this URI scheme. 
>Further, the two registrations (in the two IDs) are identical per 
>the Application AD's suggestion. I would prefer not to fight the an AD on this.
>
>
>>In fact, I don't think it is useful to register the URI types.
>
>The Application AD thinks otherwise.  You were there for that 
>discussion too (in Vancouver, at the lunch meeting with Robert, 
>Cullen, Lisa, Jon, you, etc). Thus I will respectfully decline to 
>make these changes until I hear directly from Lisa (on either) that 
>another course of action is preferred by her.
>
>
>
>>--- Location URI randomness / uniqueness
>>
>>
>>I would not include mailing list discussions into the draft itself:
>>
>>"
>>    As to the concerns about the Location-URI itself, as stated in the
>>    document here (in Section 3.), it must not have any user identifying
>>    information in the URI string itself.  The Location-URI also must be
>>    hard to guess that it belongs to a specific user.  There is some
>>    debate as to whether this Location-URI need be a random alphanumeric
>>    string or just unique.  If the latter, there is some debate as to
>>    the how we define unique. Is that through space as time, as RFC 3261
>>    defines a SIP Call-ID needs to be (meaning: never a duplicate, ever,
>>    by any device, ever)? Or is it unique to within a specific domain
>>    for as long as it is actively assigned to a client (plus some
>>    interval).
>>"
>>
>>When you hand out a reference then you need to make sure that it is
>>unique throughout the lifetime of the reference with regard to the
>>specific server.
>
>I've asked this question over and over again, and you're the first 
>to answer this (just now, and not before now) as to whether this 
>sequence needs to be unique through time. I also haven't seen that 
>written anywhere - so where exactly is the consensus for this 
>extreme level of uniqueness?
>
>I believe that if a sequence is only given once, then this is the 
>equivalent to an identifier, because only entity ever possessed it. 
>Does that same entity always be given the same sequence by the same 
>domain or network? If so, then it is an identifier, and I don't 
>understand where that requirement comes from. If a domain or network 
>can allocate the same sequence to more than one entity (but not at 
>the same time (which is common sense), then what is the timing of 
>the that decision or interval before the same sequence can be given 
>out specified?
>
>I guess I'm not clear why you want what you want, and I don't know 
>of from where you are asserting this consensus based recommendation?
>
>
>>You don't want to hand out the same references pointing to different
>>entities.
>
>ever?
>
>>That would not make sense.
>
>not at the same time, that would be admittedly foolish. But if the 
>reference is not given out, ever, to more than one entity, then 
>there probably is some form of attack that can take advantage of 
>this (once other identifying information is learned by an adversary)?
>
>In other words, I didn't get this push-back from when I was making 
>the argument of random vs. unique sequence... Unique was stated to 
>be ok with some folks (Martin Dawson was one I remember now)
>
>
>>We discussed the randomness aspect on the mailing list. Hence, it should
>>be clear.
>
>we discussed the randomness aspect of this on the mailing list, yes, 
>but it was never clear why this is needed, so we're not clear yet...
>
>
>
>>--- Authorization Policies
>>
>>
>>I don't see the discussed issue of the geolocation policies being
>>addressed. As discussed during the IETF meeting you need to normatively
>>reference RFC 4745 and
>>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-15.txt to
>>make sense out of it.
>>
>>Without these policies you can only hand out a reference that points to
>>static location.
>>
>>I am also not sure about the encoding of the URIs; I am not the expert
>>in these issues but I wonder whether there is something regarding
>>internationalized domain names to consider.
>>
>>Ciao
>>Hannes
>>
>>
>> >-----Original Message-----
>> >From: [email-masked]
>> >[mailto:[email-masked]] On Behalf Of ext Robert Sparks
>> >Sent: 16 May, 2008 21:56
>> >To: Robert Sparks
>> >Cc: GEOPRIV; James M. Polk
>> >Subject: [Geopriv] lbyr-uri-option question
>> >
>> >(resubjecting the thread)
>> >On May 16, 2008, at 1:49 PM, Robert Sparks wrote:
>> >
>> >> If it's really that small, we should be able to put it down
>> >before the
>> >> end of next week on list I would hope.
>> >>
>> >> James is proposing the document carry only a relative time vs an
>> >> absolute time. If that's a complete description of the issue, then
>> >> someone that feels strongly that it should be an absolute
>> >time please
>> >> respond with why.
>> >>
>> >> James - I didn't follow this sentence:
>> >>
>> >>>  I'd really like to understand why
>> >>> the L-URI simply error a request once it is no longer valid.
>> >>
>> >>
>> >> RjS
>> >>
>> >> On May 16, 2008, at 1:41 PM, James M. Polk wrote:
>> >>
>> >>> Robert
>> >>>
>> >>> Can I ask that
>> >>>
>> >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-
>> >>> option-00.txt
>> >>> be added to the interim discussion?
>> >>>
>> >>> I believe the only remaining open item is the format of the timing
>> >>> field (whether it is given in 'seconds remaining' that a
>> >L-URI is to
>> >>> be considered valid, or with an absolute time (GMT style) that a
>> >>> L-URI is to be considered valid).
>> >>>
>> >>> I haven't been able to get enough responses to this issue - other
>> >>> than from Roger - about this item.  I'd really like to
>> >understand why
>> >>> the L-URI simply error a request once it is no longer
>> >valid. Meaning,
>> >>> I guess I don't understand why this needs to be an absolute time at
>> >>> all...
>> >>>
>> >>> I hope this discussion will not take very long (as in <15 minutes).
>> >>>
>> >>> Once this issue is resolved, I think I'll be asking for
>> >publication,
>> >>> and having that done before Dublin will be beneficial.
>> >>>
>> >>> Let me know
>> >>>
>> >>> James
>> >>>
>> >>>
>> >>> At 01:18 PM 5/16/2008, Robert Sparks wrote:
>> >>>> In case you missed this in the planning thread, or don't
>> >watch ietf-
>> >>>> announce:
>> >>>>
>> >>>> IMPORTANT:
>> >>>> if you are planning to attend and haven't told me, please
>> >do so now.
>> >>>> I need an accurate headcount.
>> >>>>
>> >>>>
>> >>>> Begin forwarded message:
>> >>>>> From: IESG Secretary
>> >>>>> <<mailto:[email-masked]>[email-masked]>
>> >>>>> Date: May 12, 2008 5:45:01 PM CDT
>> >>>>> To: <mailto:[email-masked]>[email-masked]
>> >>>>> Subject: GEOPRIV Interim Meeting, June 12, 2008
>> >>>>>
>> >>>>> The IETF GEOPRIV WG is holding an Interim meeting June 12th in
>> >>>>> Dallas.
>> >>>>> Please see the geopriv mailing list for more details on location
>> >>>>> and draft agenda.
>> >>>>> _______________________________________________
>> >>>>> IETF-Announce mailing list
>> >>>>> <mailto:[email-masked]>[email-masked]
>> >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> >>>>
>> >>>>
>> >>>>
>> >>>> We will meet here:
>> >>>>
>> >>>> Tekelec
>> >>>> 17210 Campbell Road
>> >>>> Suite 250
>> >>>> Dallas, TX 75252-4203
>> >>>>
>> >>>>
>> ><<http://maps.google.com/maps?q=17210+Campbell+Rd,+dallas,+tx,+752 
>> 52>>>> &hl=en
>> >>>>>
>> >http://maps.google.com/maps?q=17210+Campbell+Rd,+dallas,+tx,+75252&
>> >>>>> hl=en
>> >>>>>
>> >>>>
>> >>>> Some hotels near this office can be found here:
>> >>>>
>> ><<http://www.nostrum.com/~rjsparks/hotels.html>http://www.nostrum.co
>> >>>> m/~rjsparks/hotels.html
>> >>>>>
>> >>>>
>> >>>> The current agenda is
>> >>>>
>> >>>> 9:00-10:30lis-discovery
>> >>>> 10:30-12:00 HELD Identity extensions 1:00-2:30HELD Context
>> >>>> management extensions 2:30-4:00Dereferencing
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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
>> >
>> >_______________________________________________
>> >Geopriv mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/geopriv
>> >

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