WG Review: Dynamic Host Configuration (dhc)

2013-08-30 Thread The IESG
The Dynamic Host Configuration (dhc) working group in the Internet Area
of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to
the IESG mailing list (iesg at ietf.org) by 2013-09-09.

Dynamic Host Configuration (dhc)

Current Status: Active WG

Chairs:
  Bernie Volz v...@cisco.com
  Tomek Mrugalski tomasz.mrugal...@gmail.com

Assigned Area Director:
  Ted Lemon ted.le...@nominum.com

Mailing list
  Address: dh...@ietf.org
  To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg
  Archive: http://www.ietf.org/mail-archive/web/dhcwg/

Charter:

Proposed Updated DHC WG Charter (August 26, 2013)
-

The Dynamic Host Configuration working group (DHC WG) has developed DHCP
for automated allocation, configuration and management of IP addresses
and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft
Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently
a Proposed Standard and is documented in RFC 3315. Subsequent RFCs
document additional options and other enhancements to the specifications.

The DHC WG is responsible for defining DHCP protocol extensions.
Definitions of new DHCP options that are delivered using standard
mechanisms with documented semantics are not considered a protocol
extension and thus are outside of scope for the DHC WG. Such options
should be defined within their respective WGs and reviewed by the DHCP
Directorate. However, if such options require protocol extensions or new
semantics, the protocol extension work must be done in the DHC WG.

The DHC WG has the following main objectives:
  
1. Develop extensions to the DHCPv6 infrastructure as required to meet
   new applications and deployments of DHCP. The topics currently in
   development are:
   - DHCPv6 Failover, High Availability and Load Balancing
   - Extend DHCPv6 to work with multiple provisioning domains
   - DHCP provisioning of IPv4 clients over IPv6 networks
   - SOLMAXRT counter update
   - Container option 
   - Access Network Identifier
   - DNS registration for SLAAC

   Additional topics may only be added with approval from the responsible
   Area Director or by re-chartering.

2. Develop a replacement for OPTION_NTP_SERVER (RFC 5908).   The
   DHC working group will develop this option, taking input from the NTP
   working group during the development process.   Last call on this
option
   will be done in the DHC working group.

3. Specify guidelines for creating new DHCPv6 options.

4. Develop documents that help explain operational considerations for
   the wider community.

5. Issue updated versions of the DHCP base specifications--
   RFC 3315 (DHCPv6), RFC 3633 (DHCPv6 Prefix Delegation) and
   RFC 3736 (Stateless DHCPv6) so as to fix errata and bring
   the documents to the point where they can advance along the
   IETF Standards Track.

6. In the process of updating the DHCP base specifications, in
   cases where time is of the essence, issue corrections and
   clarifications of the specifications in order to quickly address
   interoperability problems.

7. Write analyses and interoperability reports on existing DHC
   documents, including base specs.

8. When serious interoperability problems are found in other DHCP
   specifications, issue updated versions of those problems to
   address the interoperability problems.

Milestones:
  Done - WG Last Call on DHCP Options for Internet Storage Name
Service (draft-ietf-dhc-isnsoption-03.txt)
  Done - WG Last Call on Load Balancing for DHCPv6
(draft-ietf-dhc-dhcpv6-loadb-02.txt)
  Done - WG Last Call on Time Configuration Options for DHCPv6
(draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt)
  Done - WG Last Call on IPv6 Prefix Options for DHCPv6
(draft-troan-dhcpv6-opt-prefix-delegation-02.txt)
  Done - WG Last Call on DNS Configuration options for DHCPv6
(draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt)
  Done - WG Last Call on NIS Configuration Options for DHCPv6
(draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt)
  Done - Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG
  Done - Identify DHCPv4 authentication design team
  Done - Identify DHCPv4 specification review design team
  Done - Identify DHCPv4 relay agent message authentication design
team
  Done - Submit DHCP Options for Internet Storage Name Service to
IESG (draft-ietf-dhc-isnsoption)
  Done - Submit DNS Configuration options for DHCPv6 to IESG
(draft-ietf-dhc-dhcpv6-opt-dnsconfig)
  Done - Submit NIS Configuratio Options for DHCPv6 to IESG
(draft-ietf-dhc-dhcpv6-opt-nisconfig)
  Done - Submit IPv6 Prefix Options for DHCPv6 to IESG
(draft-troan-dhcpv6-opt-prefix-delegation)
  Done - Submit 'Detection of Network Attachment (DNA) in IPv4' to
IESG (draft-ietf-dhc-dna-ipv4)
  Done - Resolve IPR 

Protocol Action: 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' to Best Current Practice (draft-eastlake-rfc5342bis-05.txt)

2013-08-30 Thread The IESG
The IESG has approved the following document:
- 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE
   802 Parameters'
  (draft-eastlake-rfc5342bis-05.txt) as Best Current Practice

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Joel Jaeggli.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/




Technical Summary

Some IETF protocols make use of Ethernet frame formats and IEEE 802
parameters.  This document discusses some use of such parameters in
IETF protocols, specifies IANA considerations for assignment of
points under the IANA OUI (Organizationally Unique Identifier),
provides some values for use in documentation, and obsoletes RFC
5342.


Working Group Summary

As was the previous document, this version was prepared under the 
assumption that this would this would be AD sponsored. There is a not a 
logically good home for an IANA maintained registry of IETF assigned 
entries under the IANA OUI, for the previous RFC  the sponsoring AD 
was also  the IEEE liason.

Document Quality

The document makes small but important changes to RFC 5342 
(Repeated from the document) 

Add MAC addresses and IANA OUI-based protocol and other values for
use in documentation.

Eliminate any requirements for parallel unicast and multicast
assignment that are not requested. Such requirements had been
included in [RFC5342] on the theory they would make bookkeeping
easier for IANA but have proved to be problematic in practice.

The document has been reviewed by the previously shepherding AD.
The document has been throught IETF last call and has Addressed
IANA review concerns.

Personnel

Joel Jaeggli is the Shepherding AD and Author of the Shepherding report.