Re: [Geopriv] LIS Discovery

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

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:[e-mail]]
> Sent: Tuesday, 10 June 2008 2:13 PM
> To: Thomson, Martin
> Cc: GEOPRIV WG
> Subject: Re: [Geopriv] LIS Discovery
> 
> 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
> 
> 
> 
> 
> Thomson, Martin wrote:
> > 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
> > [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