Subject: [dhcwg] comments on draft-daniel-dhc-dhcpv4-tep-conf

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 08:39:58 -0700

This draft breaks a couple of existing assumptions about DHCP.   First, 
it requires that the option be send only in a DHCPACK message in 
response to a DHCPREQUEST message.   Normally the DHCPOFFER message 
contains the same options as the DHCPACK message.   So I would strongly 
suggest that this restriction be relaxed to allow the DHCPOFFER to 
contain this option.

Secondly, the draft allows multiple copies to appear.   This 
contradicts the Encoding Long Options RFC (sorry, can't remember the 
number off the top of my head), which would create a huge headache for 
DHCP server and client implementations.   So please change the option 
so that there can be only one of them, and that if multiple values need 
to be sent, that is encoded within the option.

Also, there is quite a bit of information in this document that goes 
beyond describing the format of the option.   It looks like you're 
defining a new protocol.   If you are not defining a new protocol, it 
would be better to refer to the document that defines the protocol, and 
remove the words from this document that describe that protocol in 
detail.   If you are defining a new protocol here, this draft probably 
needs to be reviewed by the working group responsible for that area as 
well as by the DHC working group.  (sorry if this has already been 
said)

I've enclosed a couple of diffs for some minor editorial suggestions.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Syam Madanapalli <[email-masked]>
Date: Tue, 3 Aug 2004 16:33:53 -0700 (PDT)

Hello Ted Lemon ,

This draft breaks a couple of existing assumptions
about DHCP. First, it requires that the option be send
only in a DHCPACK message in response to a DHCPREQUEST
message. Normally the DHCPOFFER message contains the
same options as the DHCPACK message. So I would
strongly suggest that this restriction be relaxed to
allow the DHCPOFFER to contain this option.

---> Initially we have taken this approach, so that we
     could establish the bidirectional tunnel
simultaneously 
     at both the places. With your proposal now we can
     create the tunnel only one side, the other side 
     need to repeat this procedure to create the other
     end of the tunnel.
 
     To overcome this we have new proposal where DHCP
Inform 
     is used to to create the tunnel.  Following link
has the PPT
       
http://home.megapass.co.kr/~natpp00/IETF-60-DHCPv4-CTEP.ppt

Secondly, the draft allows multiple copies to appear.
This contradicts the Encoding Long Options RFC (sorry,
can't remember the number off the top of my head),
which would create a huge headache for DHCP server and
client implementations. So please change the option so
that there can be only one of them, and that if
multiple values need to be sent, that is encoded
within the option.

---> Yep, we will make this change.

Also, there is quite a bit of information in this
document that goes beyond describing the format of the
option. It looks like you're defining a new protocol.
If you are not defining a new protocol, it would be
better to refer to the document that defines the
protocol, and remove the words from this document that
describe that protocol in detail. If you are defining
a new protocol here, this draft probably needs to be
reviewed by the working group responsible for that
area as well as by the DHC working group. (sorry if
this has already been said)

---> The intention of the draft is to propose an 
    Option as well as a protocol (may be a procedure) 
    to automate the tunnel configuration acroos IPv6 
    Clouds seperated by v4 network. 

    And this draft recommends running a DHCP Client 
    on a border dual Stack router, I am not sure if 
    this is okay. Otherwise you need another protocol 
    between DHCP Client and router to configure Tunnel
    end points automatically.

I've enclosed a couple of diffs for some minor
editorial suggestions. 
Attachment: draft-daniel-dhc-dhcpv4-tep-conf-comments

---> We will take these suggestions.

Thank you,
Syam

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail