Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-dhcp-privacy & draft-krishnan-dhc-dhcpv6-privacy

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 22 Jan 2015 18:37:55 +0000

Hello:

During the Honolulu IETF-91 meeting, there was consensus to adopt the following documents as working group items:

draft-jiang-dhc-dhcp-privacy-00  Privacy considerations for DHCP

draft-krishnan-dhc-dhcpv6-privacy-00      Privacy considerations for DHCPv6

If you do NOT favor the adoption of one or both, please reply to this mail and also state your objections. This adoption call will end on Feb 4, 2015, and unless we hear objections, these documents will be adopted.

You may also indicate your support for adopting them, but because of the WG meeting consensus, this is not necessary.

The HTML version of the documents can be viewed at http://tools.ietf.org/html/draft-jiang-dhc-dhcp-privacy-00 and http://tools.ietf.org/html/draft-krishnan-dhc-dhcpv6-privacy-00.

Thanks!

- Tomek & Bernie

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 23 Jan 2015 12:42:40 +0800

Q: Will these 2 drafts be put into standard track?

Best Regards,

Leaf

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Friday, January 23, 2015 2:38 AM
To: [email-masked]
Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-dhcp-privacy &
draft-krishnan-dhc-dhcpv6-privacy

Hello:

During the Honolulu IETF-91 meeting, there was consensus to adopt the
following documents as working group items:

If you do NOT favor the adoption of one or both, please reply to this mail
and also state your objections. This adoption call will end on Feb 4, 2015,
and unless we hear objections, these documents will be adopted.

You may also indicate your support for adopting them, but because of the WG
meeting consensus, this is not necessary.

The HTML version of the documents can be viewed at
http://tools.ietf.org/html/draft-jiang-dhc-dhcp-privacy-00 and http://tools.
ietf.org/html/draft-krishnan-dhc-dhcpv6-privacy-00.

Thanks!

- Tomek & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 23 Jan 2015 04:52:29 +0000

I believe these would be Informational as they will not propose anything to implement.

They presently are specified as being Standards Track - we would probably want to make sure they are adopted as Informational.

Other drafts being worked on will document how one might mitigate some or all of these privacy concerns.

-        Bernie

From: Leaf Yeh [mailto:[email-masked]]
Sent: Thursday, January 22, 2015 11:43 PM
To: Bernie Volz (volz); [email-masked]
Subject: RE: [dhcwg] WG Adoption Call - draft-jiang-dhc-dhcp-privacy & draft-krishnan-dhc-dhcpv6-privacy

Best Regards,
Leaf

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Friday, January 23, 2015 2:38 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-dhcp-privacy & draft-krishnan-dhc-dhcpv6-privacy

Hello:

Thanks!

- Tomek & Bernie

---

From: "Linhui Sun" <[email-masked]>
Date: Fri, 23 Jan 2015 13:24:32 +0800

Hi, all

I do support the two documents to be adopted as WG items. While I got a minor confusion about section 3.5 in [draft-krishnan-dhc-dhcpv6-privacy-00]. And I also believe this minor issue can be solved after it becomes the WG item. 

3.5.  Subscriber ID @ [draft-krishnan-dhc-dhcpv6-privacy-00]
   A DHCPv6 relay includes a Subscriber ID option [RFC4580] to associate
   some provider-specific information with clients' DHCPv6 messages that
   is independent of the physical network configuration.
   In many deployments, the relay agent that inserts this option is
   configured to use client's link-layer address as Subscriber ID.

As defiend in RFC4580 (also described in this document), the Subscriber ID is expected to provide provider-specific information and be independent of the physical network configuration.  However, the Subscriber ID often uses client's link-layer address in practice as described in the second paragraph. There seems to be a conflict between the original design motivation and the actual deployment, since the client's link-layer address seems not to be provider-specifc and is relevant to physical network configuration.

Best Regards,
Linhui

[email-masked]
 
From: Bernie Volz (volz)
Date: 2015-01-23 02:37
To: [email-masked]

 

Thanks!
 
- Tomek & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 23 Jan 2015 12:20:04 +0000

In DOCSIS the subscriber is identified by Cable Modem's mac-address (i.e. link-layer address) ... They use vendor options to send this because subscriber-id and other work that was needed was not standardized at time. Not that when CPE sends requests, CM mac-address is used by relay in vendor options (or if ever used, subscriber-id).

- Bernie (from iPad)

On Jan 23, 2015, at 12:23 AM, Linhui Sun <[email-masked]<mailto:[email-masked]>> wrote:

Hi, all

3.5<http://tools.ietf.org/html/draft-krishnan-dhc-dhcpv6-privacy-00#section-3.5>.  Subscriber ID @ [draft-krishnan-dhc-dhcpv6-privacy-00]

   A DHCPv6 relay includes a Subscriber ID option [RFC4580<http://tools.ietf.org/html/rfc4580>] to associate

Best Regards,
Linhui
________________________________
[email-masked]<mailto:[email-masked]>

From: Bernie Volz (volz)<mailto:[email-masked]>
Date: 2015-01-23 02:37
To: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-dhcp-privacy & draft-krishnan-dhc-dhcpv6-privacy

Hello:

Thanks!

- Tomek & Bernie