Updates to DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery
draft-boucadair-rfc6153-update-01

[Ballot comment]
On reflection, "no objection" is a closer fit to my position, i.e. I am OK with the RFC approach if that is the way that the sponsoring AD wishes to go, but I am equally OK with using another approach provided it fully conforms to IETF procedures.

[Ballot comment]
I'm a No Objection unless Ted hears from IANA that we don't need to publish an RFC before they can fix the error in the registry.

[Ballot comment]
for the record...

I don't mind if the draft is required to not.

I am in favor of fixing this, hence my balloted position.

[Ballot discuss]
I arrive to the exact same conclusion as Pete.
Let's not create an RFC for this, when a management item on a IESG telechat could do the trick.

[Ballot comment]
I fully agree with Pete's DISCUSS and the discussion that's followed.  We should just fix the error in registration with a management item, and not publish a document for it.  There's no real ambiguity in 6153, and once the registration is fixed this document has no value at all.

[Ballot comment]
I don't object to the use of an RFC to resolve this.

Pete makes a good point that normally we would fix IANA bugs simply by telling IANA what needs to be fixed.

However, in this case the bug was recorded in the RFC text and so is part of RFC 6153. So the fix is needed.

It would not be appropriate to change this in an Erratum because it is not simply a typo.

Moral - review the IANA action when they send you an email telling you to review their action. Double check in Auth48.

[Ballot discuss]
As far as I can tell, the error is not in the spec itself (6153). The error was that nobody noticed that IANA allocated in the wrong registry for one of these codepoints. The IANA Considerations in 6153 is not crystal clear, but it's not obviously wrong. I don't see why we want to waste the RFC Editor's time on this. Why don't we just do a Management Item telling IANA to fix the registry according to the obvious intent of 6153? If something really needs to be changed in 6153, file an erratum. I don't see the point in publishing this thing.

IESG/Authors/WG Chairs:

IANA has reviewed draft-boucadair-rfc6153-update-01.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the DHCPv6 Option Codes registry located at:

http://www.iana.org/assignments/dhcpv6-parameters

A new option code is to be registered as follows:

Value: [ TBD-at-Registration ]
Description: OPTION-IPv6_Address-ANDSF
Reference: [ RFC-to-be ]

IANA notes that the authors have proposed a value of 143 for this option code.

Note: the IANA state in the Datatracker is "Not OK" because IANA was just now able to send this request to the designated expert for review. If the request is approved, the state will be updated.

Second, in the BOOTP Vendor Extensions and DHCP Options registry in the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters page located at:

http://www.iana.org/assignments/bootp-dhcp-parameters

Value 143, currently registered as "OPTION-IPv6_Address-ANDSF," will be changed to "Unassigned," making it available for future registration.

IANA understands that these two actions are the only ones required tupon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Updates to DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Updates to DHCPv4 and DHCPv6 Options for Access Network Discovery and
  Selection Function (ANDSF) Discovery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document updates RFC 6153 by correcting IANA allocations made
  for DHCPv4 and DHCPv6 options for Access Network Discovery and
  Selection Function (ANDSF) Discovery.  This document assigns a code
  for DHCPv6 option for ANDSF and withdraws an already assigned DHCPv4
  option code.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-boucadair-rfc6153-update/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-boucadair-rfc6153-update/ballot/


No IPR declarations have been submitted directly on this I-D.

Note added 'This document corrects a clerical error in the assignment of DHCP option codes for rfc6153.  I don't think it should be at all controversial, since the problem is obvious and the correction straightforward.'