Subject: [Geopriv] LIS Discovery: just like LoST

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Apr 2009 20:17:08 -0500

Hi All,

It has been proposed to adopt a LIS discovery mechanism like that used in LoST (RFC 5222 & 5223).

After consultation, we've identified a few folks who we're going to seek review from, with the plan being to close this work very soon - it's holding up a few other documents.

I intend to submit the following as -10:
	
  <http://held-location.sourceforge.net/draft-ietf-geopriv-lis-discovery-09a.txt>

There are a number of reasons why this solution is superior:

 - It's exactly like LoST.*  This avoids differing and confusing solutions to a superficially similar problem.

 - The security story is a lot simpler and easier to explain and understand.

Depending on your perspective, which might also be considered advantages:

 - It allows network operators the choice of providing different URIs.

 - There's machinery in here that ALTO can use for their very similar discovery problem.

 - It fits in well with the proposed method in the residential gateway discovery document.

The only disadvantage is the addition of a mandatory DNS (U-NAPTR) resolution step.  Richard might suggest that this doesn't always result in extra work, but I plan not to take notice because this only works if you don't care for authentication.

--Martin

* Yes, I know there were problems with LoST discovery, but those were resolved.

------------------------------------------------------------------------------------------------
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: [email-masked]
Date: Wed, 15 Apr 2009 09:40:31 +0100

> used in LoST (RFC 5222 & 5223).

I like it - I had previously noted that previous versions of LIS discovery 
had a complicated DHCP option, when LoST just had a simple domain name 
field.

I note that in §3.2 and §3.3 there are references to LoST which appear to 
be out of place - probably because of c&p from RFC 5223.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Apr 2009 11:26:58 -0400

Hey everyone,

I would like to get this issue resolved and then WGLC this document, so 
that we can meet our scheduled milestone for it.  Please send any 
comments on this issue to the list by Wednesday, 22 April 2009.

Thanks,
--Richard

Thomson, Martin wrote:
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 21 Apr 2009 06:30:22 -0400

This is a reminder to please send any comments about this proposed 
change to the list by tomorrow.  Even comments saying "I'm OK with this 
change" would be helpful.

Thanks,
--Richard

Richard Barnes wrote:
>> After consultation, we've identified a few folks who we're going to 
>> seek review from, with the plan being to close this work very soon - 
>> it's holding up a few other documents.
>>
>>  - It's exactly like LoST.*  This avoids differing and confusing 
>> solutions to a superficially similar problem.
>>
>> The only disadvantage is the addition of a mandatory DNS (U-NAPTR) 
>> resolution step.  Richard might suggest that this doesn't always 
>> result in extra work, but I plan not to take notice because this only 
>> works if you don't care for authentication.
>>
>> --Martin
>>
>> contain privileged, proprietary, or otherwise private information.  If 
>> you have received it in error, please notify the sender

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 23 Apr 2009 01:52:05 -0500

I have just submitted -10.  It should appear shortly.  -10 is exactly as proposed (the -09a below).

Since there have been no comments either way, I can only conclude that no one cares.  That's a shame.  I can only hope that there will be no serious objections as we try to publish this work; work that is depended upon by a number of other documents here and in ECRIT.

Cheers,
Martin

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Tuesday, 21 April 2009 8:30 PM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: [Geopriv] LIS Discovery: just like LoST
> 
> >> It has been proposed to adopt a LIS discovery mechanism like that
> used
> >> in LoST (RFC 5222 & 5223).
> >>
> >>  - There's machinery in here that ALTO can use for their very
> similar
> >> discovery problem.
> >>
> >>  - It fits in well with the proposed method in the residential
> gateway
> >> discovery document.
> >>
> >> * Yes, I know there were problems with LoST discovery, but those
> were
> >> resolved.
> >>
> If

---

From: [email-masked]
Date: Thu, 23 Apr 2009 07:55:51 +0100

> 
> Re: [Geopriv] LIS Discovery: just like LoST
> 
> Since there have been no comments either way

Yes there have - I support the new draft, and said so on-list the day it 
was published :)

Ray

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 23 Apr 2009 02:00:39 -0500

I apologise Ray :)  You are the only one.  Me, I rely too much on my memory.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, 23 April 2009 4:56 PM
> To: Thomson, Martin
> Cc: GEOPRIV; [email-masked]; Richard Barnes

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 23 Apr 2009 09:23:24 -0400

I agree with the approach to support LIS discovery via DHCP.
I really would like to *also* see some method that does not rely on
upgrading intermediate routers/gateways described. That was one of the
chief drivers for creating HELD, was that it could work without upgrades
to such intermediate devices.

The draft, as written, mixes requirements for the semantics of the LIS
discovery mechanisms, with normative requirements for how devices use
the mechanism. I would rather see normative requirements for whether or
not to use, and how to use the option in something like phonebcp. I
think it's good to recommend usage in this doc, but such language should
be non-normative.

In Section 2.1, I agree that an RG (that meets this spec) must be
capable of doing one of these. But I don't agree that it must do one of
these. That is, I think RGs need to be configurable. If an RG is in an
environment where the access network LIS will not provide the best
information, and so the RG has been manually configured with more
accurate info, then it must be possible for the RG to be configured to
send this more accurate data and not LIS info. So, if that section said
"...it is recommended that the residential gateway be capable of
either:" instead of "...the residential gateway MUST either:", I think
it would be better.

Thanks,
Barbara

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Thomson, Martin
> Sent: Thursday, April 23, 2009 2:52 AM
> To: Richard Barnes
> Cc: GEOPRIV
> Since there have been no comments either way, I can only conclude that
> no one cares.  That's a shame.  I can only hope that there will be no
> serious objections as we try to publish this work; work that is
> depended upon by a number of other documents here and in ECRIT.
> 
> Cheers,
> Martin
> 
> > > I would like to get this issue resolved and then WGLC this
> document,
> > so
> > >> seek review from, with the plan being to close this work very
soon
> -
------------------------------------------------------------------
> --
> > ----------------------------
> > >>
------------------------------------------------------------------
> --
> > ----------------------------
> > >>
> > >> [mf2]
-----------------------------------------------------------------------
> -------------------------
-----------------------------------------------------------------------
> -------------------------
> [mf2]

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 23 Apr 2009 20:24:02 -0500

Hi Barbara,

Unfortunately, the method that does not require an update to the RG was removed.  As I have made clear, I consider this document an incomplete solution until that part is done.  However, what exists currently was seen as expedient.

My intent is to push for completion of the solution with something like the first option from draft-thomson-geopriv-res-gw-lis-discovery-00.  One this work is done, the RG work is a high priority.  I'd be very much interested in your opinion on that option.

I didn't really think through the consequences of normative (2119) text on RG behaviour.

I propose to remove the MUSTs, allow the RG to act as a LIS (being non-specific on the protocol, intentionally; that aspect doesn't matter), and explain the consequences of using static configuration on the RG.  Then, if the person configuring the RG knows better (and they have likely more information, so they probably will) then they are informed of the consequences.

   Support of this specification by residential gateways ensures that
   the devices they serve are able to acquire location information.  In
   many cases the residential gateway configures the devices it serves
+  using DHCP.  A residential gateway is able to use DHCP to assist 
+  devices in gaining access to their location information.  This can
+  be accomplished by providing an access network domain name DHCP option
+  suitable for LIS discovery, or by acting as a LIS directly.  To 
+  actively assist devices, a residential gateway can either:

   o  acquire an access network domain name from the access network
      provider (possibly using DHCP) and pass the resulting value to
      devices; or

   o  discover a LIS on its external interface, then provide devices
      with the domain name that was used to successfully discover the
      LIS; or

   o  explicitly include configuration that refers to a particular LIS; or

+  o  act as a LIS and directly provide location information to the 
+     devices it serves, including providing a means to discover this
+     service.

   [[the paragraph that follows is removed and replaced with]]

+  As with devices, configuration of a specific domain name or location
+  information is only accurate as long as the residential gateway does not
+  move.  If a residential gateway that relies on configuration rather than 
+  automatic discovery is moved, the devices it serves could be provided
+  with inaccurate information.  Devices could be led to discover a LIS that
+  is unable to provide accurate location information, or - if location is
+  configured on the residential gateway - the residential gateway could
+  provide incorrect location information.

No prohibitions here, just a clear description of the consequences of possible choices.  I've removed the two MUSTs that relate to your concern.  The RECOMMENDED and MUST regarding the container option I think relate to interoperability, and therefore can remain, let me know if you disagree.

--Martin

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Thursday, 23 April 2009 11:23 PM
> To: Thomson, Martin; Richard Barnes
> Cc: GEOPRIV
> Subject: RE: [Geopriv] LIS Discovery: just like LoST
> 
> The information transmitted is intended only for the person or entity
> to which it is addressed and may contain confidential, proprietary,
> and/or privileged material. Any review, retransmission, dissemination
> or other use of, or taking of any action in reliance upon this
> information by persons or entities other than the intended recipient is
> prohibited. If you received this in error, please contact the sender
> and delete the material from all computers. GA625
> 
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 24 Apr 2009 09:10:25 -0400

Hey Martin,
Thanks. I agree with this.
Barbara

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Thursday, April 23, 2009 9:24 PM
> To: Stark, Barbara; Richard Barnes
> Cc: GEOPRIV
> Unfortunately, the method that does not require an update to the RG was
> removed.  As I have made clear, I consider this document an incomplete
> solution until that part is done.  However, what exists currently was
> seen as expedient.
> 
> My intent is to push for completion of the solution with something like
> the first option from draft-thomson-geopriv-res-gw-lis-discovery-00.
> One this work is done, the RG work is a high priority.  I'd be very
> much interested in your opinion on that option.
> 
> I propose to remove the MUSTs, allow the RG to act as a LIS (being non-
> specific on the protocol, intentionally; that aspect doesn't matter),
> and explain the consequences of using static configuration on the RG.
> Then, if the person configuring the RG knows better (and they have
> likely more information, so they probably will) then they are informed
> of the consequences.
> 
> No prohibitions here, just a clear description of the consequences of
> possible choices.  I've removed the two MUSTs that relate to your
> concern.  The RECOMMENDED and MUST regarding the container option I
> think relate to interoperability, and therefore can remain, let me know
> if you disagree.
> 
> --Martin
> 
> > > I have just submitted -10.  It should appear shortly.  -10 is
> exactly
> > > as proposed (the -09a below).
> > >
> > > > change to the list by tomorrow.  Even comments saying "I'm OK
> with
> > > this
> > > > >> After consultation, we've identified a few folks who we're
> going
> > > to
> > > > >>  - The security story is a lot simpler and easier to explain
> and
> > > > >> understand.
> > > > >>
> > > > >>  - It allows network operators the choice of providing
> different
> > > > URIs.
> > > > >>
> > > > >> result in extra work, but I plan not to take notice because
> this
> > > > only

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621