Subject: [Geopriv] Re: [Ecrit] thomson-geopriv-lis-discovery-03

From: Cullen Jennings <[email-masked]>
Date: Sun, 2 Dec 2007 22:14:06 -0800

On Nov 29, 2007, at 9:34 PM, Thomson, Martin wrote:

> (Bring this back to Geopriv...)
>
> Hi Cullen,
>
> Thanks for your comments.
>
> Re 1.2: HTTP-based services require a path as well as a host and  
> port.  We would have to bastardize HTTP to avoid that.
I think my question is why can't you construct the path from the host  
and port? But this is trivial stuff - don't care one way or other.

>
> Re 4.2.1.1: UPnP is specifically suggested because the way that it  
> works is to find the next layer out from the Device.  We aren't  
> looking for a public address; instead, we are actually looking for  
> an address in the next nearest network layer.  This is on the  
> assumption that a LIS in that layer is more likely to be able to  
> locate us.
I see - thanks for explaining.

>   (Actually, the piece of UPnP that is required is relatively small  
> - perform discovery, find devices that support the WANIPConnection  
> profile, call GetExternalIPAddress on that device).
and I supsect the related security for that.

>
> The reason that we can't rely on the domain name is that a domain  
> name extracted from a device like a home router isn't useful for  
> discovery.  Note that the home router case also drives the UPnP  
> recommendation, particularly for layered NAT.
>
> Ta,
> Martin

Cullen <with my individual hat on>

>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]]
>> Sent: Friday, 30 November 2007 2:42 PM
>> To: ECRIT
>> Subject: [Ecrit] thomson-geopriv-lis-discovery-03
>>
>>
>> This does a nice job of laying out the options. Few questions ...
>>
>> Section 1.2. Do we really need to discover a URI or would host, port,
>> and type of protocol be enough? If so, SRV would be simpler and more
>> widely supported.
>>
>> Section 4.2.1.1 UPnP would not work in many of the cases we are
>> interested in such as layered NAT and even worse it may not be
>> possible to detect this failure. I would not be in favor of UPnP
>> unless it really was the only solution. It is also very complicated
>> to spec the exact parts of it you would need - UPnP is a lot of  
>> things.
>>
>> Do we have any idea how common DHCP without a domain name option is?
>> I'm wondering if people would bother to implement way to get IP for
>> reverse IP approaches.
>>
>> Cullen <with my individual contributor hat on>
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ecrit
>
> ---------------------------------------------------------------------- 
> --------------------------
> 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://www1.ietf.org/mailman/listinfo/geopriv