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

["Thomson, Martin" <[e-mail]>]

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
	
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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?
> 
> 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
> [e-mail]
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv