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

From: Richard Barnes <[email-masked]>
Date: Wed, 30 Apr 2008 16:46:34 -0400

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?

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."

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.

--Richard

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 30 Apr 2008 18:22:46 -0500

Hi Richard,

Comments below.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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?

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.

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.

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

------------------------------------------------------------------------------------------------
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]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 30 Apr 2008 19:23:47 -0500

I see that Martin D has already responded.  I'll still respond, because
the answers aren't that clear to me.  It's a shame that all the good
questions are hard.

1. My initial impression is to say "there is no need for U-NAPTR over
S-NAPTR", but then I automatically invite the response "so let's change
it to S-NAPTR" and I hate it when people say that; it's too easy.
  Here is my short list of reasons:
    a. Why not?  (I know it's a rude way to answer a question, but it's
perfectly valid.  I understand the advantages inherent in simplicity,
but if that's all there is, consider my other reasons.)
    b. Consistency.  We need host and port, but DHCP is providing a URI,
why doesn't the DNS?  A LIS is identified by a URI, so a URI should be
provided.
    c. Flexibility.  If we used S-NAPTR a fixed rule would be needed to
convert to a URI, which limits flexibility.  I haven't seen it yet, but
wouldn't it be sensible if a LIS that serves multiple access networks
could identify the network using the extra info in the URI.
Nw1.example.org could point to held://lis.example.org:12345/nw1/;
nw2.example.org could point to held://lis.example.org:12345/nw2/.

2a. I see no need to limit the URI scheme.

2b. The intent of the URI is to identify the LIS.  Given the subject of
the document, I find it hard to imagine that someone would mistake that
intent.  There's no harm in being clear on that if you see fit; pick
either piece of suggested text.

3a. The dodgy options exist for a good reason, and the document is clear
on when they are applicable: only when the DHCP option doesn't deliver.
Is that not explicit enough for you?

3b. Your discussion on what a network should provide is probably useful.
Operational guidance is often lacking in these documents.  Provide DHCP,
or at least provide a DNS record and a predictable way of getting to
that DNS record.  However saying that you must provide the DHCP
hostname/domain option doesn't entirely work, because if you can get
DHCP to the Target then may as well directly use the LIS DHCP option.
DNS exists for cases where DHCP doesn't reach the Target.

Cheers,
Martin