RADIUS Option for the DHCPv6 Relay Agent
draft-ietf-dhc-dhcpv6-radius-opt-14

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    dhc mailing list <dhcwg@ietf.org>,
    dhc chair <dhc-chairs@tools.ietf.org>
Subject: Protocol Action: 'RADIUS Option for DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-radius-opt-14.txt)

The IESG has approved the following document:
- 'RADIUS Option for DHCPv6 Relay Agent'
  (draft-ietf-dhc-dhcpv6-radius-opt-14.txt) as Proposed Standard

This document is the product of the Dynamic Host Configuration Working
Group.

The IESG contact persons are Ted Lemon and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/

Ballot Text

Technical Summary:

  This document defines RADIUS DHCPv6 option that is similar to its DHCPv4
  counter-part that was defined in RFC4014. The DHCPv6 RADIUS option provides a
  mechanism to exchange authorization and identification information between the
  DHCPv6 relay agent and the DHCPv6 server.  This mechanism is meant for the
  centralized DHCPv6 server to select the right configuration for the requesting
  DHCPv6 client based on the authorization information received from the RADIUS
  server, which is not co-located with the DHCPv6 server.  The Network Access
  Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in
  this document.

Working Group Summary:

  This document was called draft-yeh-dhc-dhcpv6-authorization-opt prior to its
  adoption. There was unanimous support for it (9 people in favor of adoption
  and none against), so this document was adopted in May 2012. There was quite
  high interest in this work - 55 posts since its adoption. There was never any
  opposition for this work.

Document Quality:

  I'm not aware of any existing implementations, but the level of support from
  both DHCP vendors (Nominum, Weird Solutions, Cisco, ISC), hardware vendors
  (Huawei, Cisco) and operators (Orange, Telecom Italia) suggests that this will
  be implemented and deployed shortly after option code is assigned by IANA.
  There was no single lead reviewer and many people contributed to the draft (55
  posts about it to DHC list, 41 posts to RADEXT during its WG life). This
  document went through rapid updates (10 revisions 10 months), because its lead
  author - Leaf Yeh - was eager to address any comments as soon as they appeared.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Tomek Mrugalski is the document shepherd. Ted Lemon is the responsible AD.

RFC Editor Note