[dhcwg] draft-ietf-dhc-vpn-option-11.txt

[Kim Kinnear <kkinnear at cisco.com>]

I have submitted a new version of the VPN option draft today:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-11.txt

The changes since the 09 version are as follows.  This includes
the three outstanding "tickets" on this draft from:

http://trac.tools.ietf.org/wg/dhc/trac/query?status=new&status=assigned&status=reopened&component=vpn-option

  1.  Clarified the response of a DHCPv6 server to the appearance
  of the DHCPv6 VSS option in the ORO or ERO options.
  Specifically, the draft says that for the VSS option the
  processing specified in the draft concerning the DHCPv6 VSS
  option takes precedence over any activity implied by the
  appearance of the DHCPV6 VSS option in the ERO or ORO options.
  This was based on a discussion largely between Bernie Volz and
  David Hankins (though others contributed) concerning this
  issue.  This is also the second issue in ticket #19.

  2.  Added more words to make it clear that if you use a DHCPv4
  relay agent that supports the VSS sub-option and you configure
  it to send that sub-option to a DHCPv4 server, then you MUST
  also use a DHCPv4 server that supports the VSS sub-option.
  This was based on a discussion with Alfred Hoenes.  This is
  also the issue from ticket #21.

  3.  A variety of editorial corrections were made, based on
  several respondents, though largely based on reviews by Alfred
  Hoenes and Josh Littlefield.

  4.  Updated to new boilerplate.  I didn't include the text
  suggested by idnits concerning the inclusion of old text or
  information as all there is nothing in this draft that is an
  issue and the authors are all still available.  I *think* I got
  that right, but you never know.

  5. Editorial updates from ticket #12:

http://trac.tools.ietf.org/wg/dhc/trac/ticket/12

  6.  The first issue in ticket #19 is to specify that if the DHCP
  server changes the VPN the from one sent in, that it should (if
  possible) send back the new VSS information using the same
  "type" as was used when the packet was received.  Modified the
  draft to say essentially that.

In all cases above, I believe these changes clarified the
original intent of the draft and did not change the behavior that
had already passed the DHC WG last call.  As such (and for a
change), I don't think this draft needs to go through a DHC WG
last call again.

I believe that this draft is ready to progress to the next step
after last call.

Regards -- Kim