Re: Preliminary notes from WG meeting in Memphis Sat, 12 April 1997 18:19 UTC

Received: from cnri by id aa13951; 12 Apr 97 14:19 EDT
Received: from by CNRI.Reston.VA.US id aa12923; 12 Apr 97 14:19 EDT
Received: from by; (5.65v3.2/ id AA05491; Sat, 12 Apr 1997 14:05:50 -0400
Date: Sat, 12 Apr 1997 14:05:50 -0400
Message-Id: <>
Precedence: bulk
To: Multiple recipients of list <>
Subject: Re: Preliminary notes from WG meeting in Memphis
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4


I will send extensive comments on the server-to-server protocol and
security architecture as I am able.  I was unable to attend those parts
and will respond to mail already submitted as I am able.  Also can you
add Charlie to v4 and v6 lists with his new org address I know he had to
continue travel this week. thx...

>* DHCPv6 (dhc-dhcpv6-09.txt, dhc-v6exts-05.txt)
>                                             - current drafts need further
>  editorial review and clarification; serious concerns about security
>  raised by WG; v6 docs also need to reflect current v4 operational
>  experience (esp. wrt multiple servers)

The strategy agreed to at the DHCPv6 session was:  

We will fix editorial legacy parts missed in DHCPv6 spec.  That will
move to IETF Last Call.  If the IESG and IETF find no other issues Jeff
Schiller will permit it to move to PS as we promised to add key
selection to our v6-exts draft.   Charlie and I should have a fix for
the ext draft shortly.  

I would like to see this recorded in the minutes.

What "exactly/precisely" does the last statement mean "v6 docs need to
reflect current v4 operational experience"...  I don't recall that
discussion at the DHCPv6 meeting.  I would suggest more words be
reflected in that statement and if it was discussed not at the DHCPv6
session where it was discussed, it could be an answer is apparent to us
as authors and that tells us something too.  Also current v4 operational
experience in all cases will not apply (e.g. use of multicast, no
bootp, use of solicit/advertise).  It is a new protocol not based on
DHCPv4 even architecturally.  But operational issues like redundant
server responses, multiple relays btw servers etc.. has been thought
out.  But as I said its not clear to me what the statement means and
what is expected to be done from the statement.

We need to get this to PS I have an offline commit from several vendors
and research environments to begin implementations.  So when we are
ready for draft standard there will not be an issue.