Subject: [Geopriv] questions/comments regarding draft-schulzrinne-geopriv-relo

From: Andrew Newton <[email-masked]>
Date: Fri, 11 Aug 2006 16:47:51 -0400

A couple of questions/comments on draft-schulzrinne-geopriv-relo.

1) The discovery section could use a little more detail.  I assume that the 
following mechanisms are being described:

    a - if the hostname of the machine sending the query is 
bubba.example.net, then issue a NAPTR query (S-NAPTR/U-NAPTR) at 
bubba.exmaple.net.  How you managed to get your host named bubba.example.net 
is really not important.

    b - if your IP address is 192.168.1.2, then send a NAPTR query (again 
S-NAPTR/U-NAPTR) to 2.1.168.192.in-addr.arpa.

Is there any thought to which I do first?  And what about things like mDNS?

2) For a request with by="events", is it possible to get both the XML 
response and the Subscribe headers?  And if so, what is the purpose of 
having two mechanisms?  The explanation regarding the selection of an HTTP 
header field is a bit confusing, especially the part about the JPEG image. 
It makes it sound as if the querier sends the request in XML and can get 
back an JPEG image.  Did I misread that?

3) The key for the lookup is the source IP address of the request.  Is there 
any thought to allowing something like a DHCP client ID?

-andy

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Aug 2006 22:54:41 -0400

> A couple of questions/comments on draft-schulzrinne-geopriv-relo.

Thanks for your comments.

>
> 1) The discovery section could use a little more detail.  I assume  
> that the following mechanisms are being described:
>
> bubba.exmaple.net.  How you managed to get your host named  
> bubba.example.net is really not important.
>
>    b - if your IP address is 192.168.1.2, then send a NAPTR query  
> (again S-NAPTR/U-NAPTR) to 2.1.168.192.in-addr.arpa.
>

For the reason you imply in (b), namely NATs, I think doing (a) first  
is probably better, although I suspect it doesn't matter much. I can  
come up with scenarios for either case. (In the enterprise case, I  
suspect (a) is easier. For residential DSL, PPP configuration doesn't  
seem to include host names, so only (b) is an option.)

I'll flesh out the discovery section a bit.

>
> 2) For a request with by="events", is it possible to get both the  
> XML response and the Subscribe headers?  And if so, what is the  
> purpose of having two mechanisms?  The explanation regarding the  
> selection of an HTTP header field is a bit confusing, especially  
> the part about the JPEG image. It makes it sound as if the querier  
> sends the request in XML and can get back an JPEG image.  Did I  
> misread that?

That was a remnant of earlier thinking. As you point out, the 'event'  
and the Subscribe header offer the same service.

No, you shouldn't get back a JPEG image; the notion was that

- subscription to be notified of changes in objects apply to data  
types beyond PIDF-LO;

- unlike for XML objects, where one might embed the URL in the  
response, this isn't really feasible for data types such as GIF or JPEG.

>
> 3) The key for the lookup is the source IP address of the request.   
> Is there any thought to allowing something like a DHCP client ID?

Yes, I want to allow other identifiers. We are currently implementing  
switch port numbers returned by CDP, for example. I suspect we need a  
registry of such identifiers unless something like that exists already.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Sat, 12 Aug 2006 09:02:16 -0400

On Aug 11, 2006, at 10:54 PM, Henning Schulzrinne wrote:
> That was a remnant of earlier thinking. As you point out, the  
> 'event' and the Subscribe header offer the same service.
>

In other words, you believe an HTTP Subscribe header could have  
broader use than RELO?

>> 3) The key for the lookup is the source IP address of the  
>> request.  Is there any thought to allowing something like a DHCP  
>> client ID?
>
> Yes, I want to allow other identifiers. We are currently  
> implementing switch port numbers returned by CDP, for example. I  
> suspect we need a registry of such identifiers unless something  
> like that exists already.

I'm not sure about this.  We probably just need an opaque string to  
hold any arbitrary key.  Either the key is found or it is not.  The  
shape and smell of the key are unimportant.  Perhaps there could be  
an optional "client-id" attribute.  If present, it is used.  If not,  
use the source IP address... with the obvious warning that if the  
contents of the client-id attribute is an IP address then this is a  
possible spoofing attempt.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 12 Aug 2006 09:12:49 -0400

> In other words, you believe an HTTP Subscribe header could have broader 
> use than RELO?

Yes, although I don't necessarily want to make this a major part of the 
discussion. It's clearly purely optional functionality that doesn't harm 
innocent bystanders.

>
> I'm not sure about this.  We probably just need an opaque string to hold 
> any arbitrary key.  Either the key is found or it is not.  The shape and 
> smell of the key are unimportant.  Perhaps there could be an optional 
> "client-id" attribute.  If present, it is used.  If not, use the source 
> IP address... with the obvious warning that if the contents of the 
> client-id attribute is an IP address then this is a possible spoofing 
> attempt.
>

The revised version of the draft defines an id attribute that describes 
the format of the opaque string. Something like

<get-location id="CDP">cepsr7-1/17</get-location>

I think that's roughly what you're suggesting, if I understood correctly.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Sat, 12 Aug 2006 09:24:03 -0400

On Aug 12, 2006, at 9:12 AM, Henning Schulzrinne wrote:

> Yes, although I don't necessarily want to make this a major part of  
> the discussion. It's clearly purely optional functionality that  
> doesn't harm innocent bystanders.

Agreed.  I was just making sure we were on the same page.

>> I'm not sure about this.  We probably just need an opaque string  
>> to hold any arbitrary key.  Either the key is found or it is not.   
>> The shape and smell of the key are unimportant.  Perhaps there  
>> could be an optional "client-id" attribute.  If present, it is  
>> used.  If not, use the source IP address... with the obvious  
>> warning that if the contents of the client-id attribute is an IP  
>> address then this is a possible spoofing attempt.
>>
>
> The revised version of the draft defines an id attribute that  
> describes the format of the opaque string. Something like
>

Yup.

Thanks.
-andy