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

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 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg