Subject: [Geopriv] Fwd: [dhcwg] WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28

From: Alissa Cooper <[email-masked]>
Date: Mon, 22 Apr 2013 11:19:34 -0400

Passing this along in case folks want to weigh in during the WGLC of draft-ietf-dhc-container-opt-07, which ends this Sunday, April 28.

Begin forwarded message:

> From: "Bernie Volz (volz)" <[email-masked]>
> Subject: FW: [dhcwg] WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28
> Date: April 15, 2013 12:26:14 PM EDT
> Resent-To: [email-masked], [email-masked],
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "Dhc Chairs ([email-masked])" <[email-masked]>, "Reinaldo Penno (repenno)" <[email-masked]>, "Ralph Droms ([email-masked])" <[email-masked]>
> 
> Hello:
> 
> The DHC WG is doing a WGLC on the http://tools.ietf.org/html/draft-ietf-dhc-container-opt. This document was previously at the IESG but got "dropped" and because it was a long time ago and there has been renewed interest, we felt it best to restart the process.
> 
> During the earlier IESG review, there was mention of whether the GEOPRIV and ECRIT WGs had commented on this work:
> 
>    ---- (4/13/2010 Adopting Cullen Jenning's Discuss) ------ 
> 
>    I would like the geopriv and ecrit folks to get a chance to look at this. My 
>    understanding of their assumptions about DHCP will work is not at all 
>    consistent with this and this could have some fairly significant implications 
>    to plans for Emergency 911 type systems.
> 
> So, we feel it prudent to make you aware of the document and WGLC. Feel free to notify your respective working groups.
> 
> While I wasn't involved during the earlier IESG review, I would guess this may be useful in providing GEOPRIV/ECRIT related information to a DHCPv6 client via the Relay Agent -- for example, the Relay Agent might "know" this information, pass it on to the DHCPv6 server in the Container Option and thus the server could use that information when responding to the client. Though this is somewhat contrary to the gist of Cullen's discuss? I am not really sure what his concern was.
> 
> If you or your WG has any concerns or comments, please either post them to the DHC WG mailing list (under the WGLC) or pass them to us (Tomek and/or myself).
> 
> Thanks in advance.
> 
> - Bernie (dhc wg co-chair)
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
> Sent: Sunday, April 14, 2013 10:54 AM
> To: DHC WG
> Subject: [dhcwg] WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28
> 
> Folks,
> The authors of draft-ietf-dhc-container-opt-07 feel it's ready for WGLC.
> 
> This draft was active around 2010, but then expired. It was revived
> (-06) in December 2012 and updated recently (-07). The last version is more explicit about which options are not allowed in the container option.
> 
> Please review the draft and indicate whether or not you feel it is ready to be published.  We have been getting very anemic responses to working group last calls recently. Your response matters, so please do respond.
> Silent support is not enough. If not enough people voice their support, the document will not advance. Simply saying "I support this work" is enough. Providing detailed review is better, but not necessary.
> 
> Bernie and I will evaluate consensus after April 28.
> 
> At the time of this writing, there is no IPR reported against this draft.
> 
> Tomek
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Apr 2013 09:05:52 -0700

To be honest, it took me a while to remember where this came up.  We
did have a citation for this in the LIS discovery draft until it
became clear that the work had stalled in DHC.

The primary identified use for this was to enable LIS discovery for
residential users.  As a practical matter, this is still a good option
for that scenario, but it's unlikely to be something that anyone can
rely on for the foreseeable future.

I don't believe that there are any specific comments on this work.  We
really just wanted to use it.

I'll note that the treatment of configuration fraud in the security
considerations is a little light.  Authentication options only work if
you have a way to establish who you trust.  One very simple technique
for addressing this is to have specific configuration that describes
what options the RG will pass through.  That's something that I
remember building into our implementation of something similar.

For example, our LIS discovery option had something like these options:
   LIS URI [___________]
   [x] Use LIS URI from ISP network if available.
   [  ] Send LIS URI even if not requested.

On 22 April 2013 08:19, Alissa Cooper <[email-masked]> wrote:
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Apr 2013 13:05:19 -0400

I don't see anything here which would make our use of DHCP to get location obsolete.  We do assume a relay agent, and we thought that was a good thing.  For example, in an enterprise deployment, the relay agent and the server could use the switch port to determine the location.

In a residential gateway, you would, I guess, have to use MAC address of the RG to determine the location.  I don't know enough about how DHCP works in this environment to know if the SP server knows RG MAC address.  That may be what Cullen was worried about.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Apr 2013 10:34:19 -0700

> In a residential gateway, you would, I guess, have to use MAC address of the RG to determine the location.  I don't know enough about how DHCP works in this environment to know if the SP server kno…

Whether the MAC address is known or not is largely[1] immaterial.  The
point is whether the SP can trace the wire back.  This doesn't have
any direct bearing on that.  What this does do is allow the SP to
provide location to devices on the remote side of the RG, albeit
somewhat approximately.  That's valuable.

[1] MAC is needed for DHCP lease query in some environments, but
that's an orthogonal issue.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Apr 2013 13:56:14 -0400

In cable environments, I didn't think the port on the CMTS is known by the DHCP server, and they used MAC address of the RG to figure out which was which.

I may have that wrong.

It might be tempting to use this to pass location from the SP to the RG client without the RG server knowing anything.  There is this though:
                  ...When the RG client
   receives the DHCP Container option, it passes the contents of the
   option to the RG server.  The means through which the information is
   passed between the RG client and the RG server is out of the scope of
   this document and left unspecified.

If it had said "it turns the content into a DHCP option to be returned to the client", great, but it doesn't.

That means RG clients and servers have to have some unspecified mechanism to exchange data.  Not as nice.

Brian