Subject: [HOKEY] Fw: draft-ietf-hokey-ldn-discovery WGLC ends

From: Tina TSOU <[email-masked]>
Date: Wed, 18 Aug 2010 09:50:02 +0800

Hi DHC WG,
Would you look over http://tools.ietf.org/html/draft-ietf-hokey-ldn-discovery-03?
It is DHC related.
Look forward to your comments.

B. R.
Tina
WG Hokey co-chair
http://tinatsou.weebly.com/index.html

----- Original Message ----- 
From: Tina TSOU 
To: [email-masked] 
Sent: Tuesday, August 17, 2010 11:10 AM
Subject: draft-ietf-hokey-ldn-discovery WGLC ends

Hi all,
I believe that all Last Call comments for draft-ietf-hokey-ldn-discovery have been addressed. The WGLC for draft-ietf-hokey-ldn-discovery has been successful.
Now it begins the document shepherding process.

B. R.
Tina
http://tinatsou.weebly.com/index.html

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Aug 2010 15:16:10 -0400

> Look forward to your comments.

Sure.   First, what is the purpose of section 4?   It looks to me like it's not necessary, and places requirements on DHCP servers that will be specific to this option.   We generally discourage this.

The relay agent and server behavior here is interesting, and mirrors some work that we'd considered doing in the DHC working group.   Please take a look at http://tools.ietf.org/html/draft-lemon-dhcpv6-relay-supplied-options-00 and see if this document makes sense.   The reason for doing this is that we'd prefer that you not specify new behavior for the DHCP server or relay agent when defining a new option.

In section 8, RFC3118 can't be cited--it's DHCPv4-specific.   RFC3315 describes a similar mechanism, so this is easy to fix.   There is no standard for authenticating DHCPv6 communications using keys established during a layer 2 authentication phase, so I don't think you should mention that here.   Communications between DHCP servers and relay agents can be authenticated using IPsec, but this isn't practical with DHCP clients--there's no way to know what key to use.

Thanks for requesting review--I hope this is helpful.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 24 Aug 2010 17:22:45 +0700

Ted Lemon  <mailto:[mailto://[email-masked]%5d>
[mailto://[email-masked]] writes:

It is DHC related.

Sure.   

Thanks!

First, what is the purpose of section 4?   It looks to me like it's not
necessary, and places requirements on DHCP servers that will be specific to
this option.   We generally discourage this.

Removed.

The relay agent and server behavior here is interesting, and mirrors some
work that we'd considered doing in the DHC working group.   Please take a
look at
http://tools.ietf.org/html/draft-lemon-dhcpv6-relay-supplied-options-00 and
see if this document makes sense.   

Looks fine to me, but the question is one of timing: as you know, we are
past WGLC on this doc, so I'm wondering how close your draft is to
publication as an RFC (my guess is that it's a ways out).  The problem is
that any reference to your draft would need to be normative, which would
essentially stop all progress on this draft.

The reason for doing this is that we'd prefer that you not specify new
behavior for the DHCP server or relay agent when defining a new option.

In section 8, RFC3118 can't be cited--it's DHCPv4-specific.   RFC3315
describes a similar mechanism, so this is easy to fix.   

OK.

There is no standard for authenticating DHCPv6 communications using keys
established during a layer 2 authentication phase, so I don't think you
should mention that here.   

OK.

Communications between DHCP servers and relay agents can be authenticated
using IPsec, but this isn't practical with DHCP clients--there's no way to
know what key to use.