[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard



> Working Group Summary
>
>    The competitor to this protocol, IKECFG, has been largely
> dismissed by
>    both the IPSEC and IPSRA working groups.  There was no
> significant dissent
>    during the LAST CALL period.  The document outlines why it
> is a more
>    appropriate solution than IKECFG.

You know, I'm not going to disagree with this draft going to proposed
standard, but I find it kind of sad that the WG summary had to have quite
this much spin on it.

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.


> -----Original Message-----
> From: owner-ipsec@xxxxxxxxxxxxxxxxx
> [mailto:owner-ipsec@xxxxxxxxxxxxxxxxx]On Behalf Of The IESG
> Sent: Thursday, July 05, 2001 10:24 AM
> To: IETF-Announce:;
> Cc: RFC Editor; Internet Architecture Board; ipsec@xxxxxxxxxxxxxxxxx
> Subject: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode
> toProposed Standard
>
>
>
>
> The IESG has approved the Internet-Draft 'DHCPv4
> Configuration of IPSEC
> Tunnel Mode' <draft-ietf-ipsec-dhcp-13.txt> as a Proposed Standard.
> This document is the product of the IPSEC Remote Access
> (IPSRA) Working
> Group.  The IESG contact persons are Jeffrey Schiller and Marcus
> Leech.
>
>
> Technical Summary
>
>    This protocol provides a mechanism for IPSEC tunnel
> configuration using
>    the existing DHCP, IKE and IPSEC protocols.  It defines a new HTYPE
>    for IPSEC virtual interfaces, and describes the steps
> necessary to make
>    DHCP work correctly and securely for IPSEC tunnel configuration.
>
> Working Group Summary
>
>    The competitor to this protocol, IKECFG, has been largely
> dismissed by
>    both the IPSEC and IPSRA working groups.  There was no
> significant dissent
>    during the LAST CALL period.  The document outlines why it
> is a more
>    appropriate solution than IKECFG.
>
> Protocol Quality
>
>    This document was reviewed by Marcus Leech.  At least two
> implementations
>    are known to exist.
>
>
>