Subject: [Geopriv] LIS Discovery

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 9 Jun 2008 19:58:47 -0500

Having just realised that there are three days left on this draft before
it expires, I thought I'd do due diligence and update it.  I'm not aware
of anything that needs changing; let me know if you know otherwise.

In checking references, I have discovered that
draft-ietf-dhc-dhcpv6-opt-dnsdomain has long expired.  This isn't
unprecedented for DHC drafts.  My preference is to remove the normative
reference entirely.  Since an informative reference isn't much use to
anyone, I'll just remove the paragraph that depends on it while I'm at
it.  Sing out if you have a better plan.

Ta,
Martin 

------------------------------------------------------------------------------------------------
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://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Jun 2008 00:12:45 -0400

Martin,

I'll bring back two issues I had raised before (I'll even keep the 
numbers!):

2. We need to make sure that there's not a conflict between the DHCP 
option in this document and draft-ietf-geopriv-dhcp-lbyr-uri-option. 
The risk here is that since HELD is being proposed as a deref protocol, 
you end up with two non-interoperable ways to distribute a HELD LbyR. 
What I would propose is an applicability statement for the URI saying 
that it should be dereferenced using the "LCP version" of HELD, as in 
draft-ietf-geopriv-http-location-delivery, not the "deref version" of HELD.

3. I think that the reverse DNS technique in Section 4.2 be removed in 
favor of a set of implementation guidelines that says essentially "IF 
you want discovery to work, you MUST provide DHCP option 15 and you MUST 
put out U-NAPTR records for every domain so distributed."  This is 
appropriate because this document is about actions taken by BOTH the 
endpoint and access network ("discovery" is a misnomer, since the access 
network has to participate, either via DHCP or U-NAPTR).

For reference, previous message was:
<http://www.ietf.org/mail-archive/web/geopriv/current/msg05577.html>

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 10 Jun 2008 00:41:49 -0500

Thanks Richard, I had forgotten about those.  The thread died a
premature death.

I did respond before, but let's try to get some sort of conclusion.

2.  I think a simple applicability statement would suit:
 "The URI result from the discovery process is suitable for location
configuration only; that is, dereferencing the URI provided by this
option provides the location of the requester only.  LIS discovery does
not produce a location URI."

3. The reverse DNS case exists only for those cases where option 15
doesn't work - if you can set option 15, then you can set option XX (LIS
URI).  Some have even pointed out that if you can set option XX (LIS
URI), RFC 3825/4776 are also possible.

We decided to do this to accommodate all end devices, and relying on
DHCP alone doesn't work.  See Figure 1 in l7-lcp-ps if you need a use
case.

Guidelines on what an access network provider needs to provide is
reasonable.  I don't see the problem with keeping "discovery" though;
the label is more helpful than it is inaccurate.

MT

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Tuesday, 10 June 2008 2:13 PM
> To: Thomson, Martin
> Cc: GEOPRIV WG
> Subject: Re: [Geopriv] LIS Discovery
> 
> Martin,
> 
---------------------------------------------------------------------
> ---------------------------
---------------------------------------------------------------------
> ---------------------------
> > [mf2]
> >

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 10 Jun 2008 02:29:18 -0500

I spent a few cpu cycles trying to think of an alternative term to
"discovery". I take Richard's point that the access network has a role.
The label "advertisement and discovery" is overly cumbersome and, in any
case, the process is not quite as proactive as "advertising" anyway.

An analogy is what happens when DNS returns an IP address and, I
suppose, it's not really conventional to refer to IP addresses being
"discovered".

Perhaps an alternative title is "LIS Resolution".

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomson, Martin
Sent: Tuesday, 10 June 2008 3:42 PM
To: Richard Barnes
Cc: GEOPRIV WG
Subject: Re: [Geopriv] LIS Discovery

MT

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Jun 2008 13:08:01 -0500

>Perhaps an alternative title is "LIS Resolution".

but how many bits of resolution do you expect here?

;-)

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 10 Jun 2008 18:36:45 -0500

I've decided that's an unresolvable bit ;) ;)

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Wednesday, 11 June 2008 4:08 AM
To: Dawson, Martin; Thomson, Martin; Richard Barnes
Cc: GEOPRIV WG
Subject: Re: [Geopriv] LIS Discovery

;-)

---

From: Richard Barnes <[email-masked]>
Date: Wed, 11 Jun 2008 12:50:20 -0400

[moving this back to the list; I accidentally dropped it off]

Martin,

Thanks for the explanations around the IP-based discovery.  With that in 
mind, I'll take another look back at the document and see if I have 
further comments.

--Richard

Thomson, Martin wrote:
> Hi Richard,
> Inline...
>> Sent: Wednesday, 11 June 2008 1:43 PM
>> To: Thomson, Martin
>> I actually think there's normative language in order here to make sure
>> that a HELD client that supports both LCP and deref processes this
> HELD
>> URI correctly.  Suggested modification to your text:
>> "
>> The URI result from the discovery process is suitable for location
>> configuration only; that is, the client MUST dereference the URI using
>> the process described in [draft-ietf-geopriv-http-location-delivery].
>> URIs discovered in this way are not "location by reference" URIs, in
>> that dereferencing one of them provides the location of the requester
>> only.  Clients MUST NOT embed these URIs in fields in other protocols
>> designed to carry the location of the client.
>> "
>  
> This is good.  I will go with this text until something better comes
> back.
> 
>> I don't think that necessarily follows.  There's plenty of software
> out
>> there that supports 15, but not XX, 3825 or 4776.
> 
> It's got nothing to do with support, it's got everything to do with an
> access network provider being able to control these parameters.  It's a
> trivial exercise to add new options to the DHCP servers I've dealt with
> (ISC, Microsoft Windows Server, the dns proxy one that I can't remember
> the name of right now...).  If that was all we were dealing with, the
> DNS options probably wouldn't exist.  What were dealing with is the case
> where the values provided by DHCP to the host are not controlled by the
> same entity that provides the LIS.  Namely, the case from l7-lcp-ps.
> 
>> In that case, reverse-DNS doesn't work either, since the end host has
> a
>> NATted IP address (unless the access network spoofs the DNS).  The
>> access network already has to have a configuration interface for the
>> home router, in order to configure its outward-facing IP interface;
>> this
>> interface could be, at least in concept, used to configure the DHCP
>> server on the router.
> 
> The methods documented in the draft get around the NAT problem by
> unpeeling the network layers until a working LIS can be found.  That's
> why UPnP and STUN are in there.  UPnP wouldn't be in there are all if it
> wasn't for those wonderful double-NATted networks - discovering a LIS 
> 
> The alternative was to look at all the myriad configuration frameworks
> and get a LIS address in each.  We did a little poll of the varied
> methods and determined that this approach was the most feasible short
> term.  James knows more about this than I do, but apparently, we aren't
> just looking at DHCP and PPP.  PPP doesn't provide an option 15
> equivalent; many of these other protocols wont either.  Furthermore,
> hostnames on the private network are usually privately controlled.
> Moving option 15 from outside to inside isn't done today.
> 
> The other major driver was wanting to avoid software/firmware upgrades
> on routers.  This was a strong driver for the "Layer 7" LCP; it is no
> less a driver in this case.
> 
> These arguments are very similar to the arguments that were tossed back
> and forth when we were discussing the need (or not) for a "layer 7" LCP.
> 
>> Certainly.  I didn't mean to deprecate the term "discovery", just to
>> point out that sometimes it can distract from the fact that there are
>> two parties involved in this situation.
>>
>> --Richard
> 
> I'll endeavour to put some text together on operational guidelines.
> I'll add a suitable introductory statement to the effect that it takes
> two to Tango.
> 
> M
> <snip>