Re: [Geopriv] Open issues in draft-ietf-geopriv-lis-discovery?

Hi Richard,

Comments below.

Cheers,
Martin

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Richard Barnes
Sent: Thursday, 1 May 2008 6:47 AM
To: 'GEOPRIV'
Subject: [Geopriv] Open issues in draft-ietf-geopriv-lis-discovery?

Now that we've adopted the LIS discovery draft as a WG item, what do 
people perceive as the open issues?  I'll pose a few questions to get 
the discussion started...

1. Why does this application require U-NAPTR instead of S-NAPTR?  I.e., 
why do you need a full HELD URI instead of just a host and port?
[[MCD]] Is there any problem with being able to get a URI? It means a
tad more flexibility in terms of how the corresponding host is resolved.

2. What sort of URI is allowed to go in the DHCP options?  If this 
option can carry an arbitrary HELD URI (or an arbitrary URI), then it 
would be equivalent to draft-ietf-geopriv-dhcp-lby-uri-options (or even 
RFC 3825/4776 using data URIs!).  My guess is that this is not the 
intent, but there should be text that says something like "This URI MUST

be such that dereferencing it will only provide the location of the 
requestor."
[[MCD]] The intent isn't the same as the DHCP LbyR draft. As opposed to
your suggested definition, I think the more explicit statement would be
"The URI identifies a LIS and is not specific to any particular target
device which can is locatable by this LIS". Since the intent of this
draft, I believe, is actually the latter, I'm not sure that it's
appropriate to be using this option in any case.

3. With the DNS options, it seems like this document could avoid some of

the shaky issues with reverse DNS and NATs by explicitly stating 
requirements for networks in which this is deployed.  For example, you 
might say that in order to support automatic LIS discovery, a network 
MUST use include in DHCP messages either the LIS option (to support 
direct DHCP discovery), or one of the domain and FQDN options (to 
support NAPTR discovery).  In the latter cases, the network MUST insert 
NAPTR records pointing to the LIS for all domain names contained in such

options.

[[MCD]] I agree. In the very common residential scenario - where there
can be no assurance that the DHCP service in the residence is going to
support the option then it is best if the alternative methods are
supported by the broadband provider.
--Richard

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
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
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv