Re: Preliminary notes from WG meeting in Memphis

[[e-mail]]

Ralph,

>>>* 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.

>OK.  At the time of the WG meeting your meeting with Jeff had not taken
>place.  The meeting notes will reflect Jeff's concerns in the meeting; how
>about "Jeff Schiller expressed concern about security issues - Jim Bound
>and Charlie
>Perkins will review those issues with Jeff"?

But that conversation did happen right in the room.
We were all sitting there and its the only time I spoke with Jeff about
Technical work at the IETF right in the meeting.  I think the key
selection for the extensions should be recorded too.  My concern with
your words above is that it does not reflect the discussion and
resolution.

What caused it was that some time before we asked for WG Last Call there
was a moratorium via the IESG on specs not addressing security issues.
It was as I heard two weeks prior to RFC 2131 and 2132 going to DS.
Charlie and I were not aware of this and could have pushed last call
prior to that and got an exception too as did RFC 2131 and 2132.  We
proposed that the DHCPv6 spec was not affected as the Exts draft had the
security but needed key selection (which Ted Lemmon caught).  I felt a
bit blind sided and asked what could be done as I felt with all the work
on this and $$$$ for WG attendees to come to IETF mtgs  to get this work 
done and were told to go to last call before Memphis.  That is when the
conversation above I recant happened as I recall it.

In addition I think it be should recorded that Charlie said other than key
selection in exts draft does the WG have any issues prior to going to
IETF Last Call.  I think there were about 40-50 people in the room and
no issues were brought forth.  If that is not some form of WG consensus
I just don't know what is in the IETF.

The editorial issues in your orginal minutes do not reflect that it was
bug fixes for use of the Source Address access in IP packets, fixing
statements in DHCPv6 that just did not get fixed from WG input.

I think also in your minutes the adverb '[serious]' concerns regarding
security.  Is a bit strong.  The hard part we did do using an HMAC-MD5
authenticator in the Exts spec, but needed to add the Key Selection
(which Charlie just sent me for review in an updated Exts spec). 

And there was no mention of issues for DHCPv6 per "operational experience"
at the meeting.

I think the DHCPv6 session went quite well and positive except for the
key selection hickup and new IESG ruling we just did not know about.
Reflecting that positive experience should be in the words in some
manner IMO.

The reason I bring this up is that at the last IETF meeting in the ION
group we had an issue where we let minutes go by that did not reflect
what most of us recall the conversation being and it resulted in holding
up the show for several specifications and their naming conventions. I
would just like to get what happened recorded in any WG I work in from
that experience....---------) as Mott the Hoople once sang.....
'once bitten twice shy'

>>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.

>There is experience with DHCPv4 that indicates specific features in DHCPv4
>may make the development of a server-server protocol more difficult.  Put
>another way, if we had known some details about server-server interactions,
>some minor changes in the DHCPv4 protocol would have made the server-server
>protocol much easier to specify.  The last statement reflects that concern.

This is clearly a thing in DHCPv6 we want to look at as it progresses.
But this was not discussed in the WG meeting for the DHCPv6 session when
Charlie was standing there doing a virtual last call for DHCPv6.  We did
consider issues regarding a server-to-server future, but clearly seeing
one in front of us will help.  I don't think this should prevent us
going to PS as even for DHCPv4 your statement above says "may make" not
will make.  We just do not want to hold up IETF last call for this
subject which is very complex as a logic check.  We have a public domain 
implementation of DHCPv6 now and the IPv6 "implementation culture" moves 
much faster once PS is achieved is my impression.  Once we hit PS we will 
see multiple DHCPv6 implementations across vendor platforms to do what PS 
is supposed to do.

With an "emerging" server-to-server protocol we can succintly note the
issues as we write the code and think about the code for
server-to-server protocol and multicast routing for that matter for
DHCPv6.  

We have done a lot of work on DHCPv6 and the WG has had much time to
review it and comment.  DHCPv6 is also needed by other IPv6 references
now.  Its time to put it to two tests of fire.  IETF last call and then
PS which will cause IMO multiple implementations within 4 months, and
for me as co-author the real test of this protocol "running-code" as
opposed to the abstraction, then model, architecture, and now protocol
Charlie and I have designed for the evolution of IPv6.

thanks for your time on this matter, 
/jim