Updates to DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery
draft-boucadair-rfc6153-update-01
Discuss
Yes
No Objection
Abstain
No Record
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Alvaro Retana No Record
Andrew Alston No Record
Erik Kline No Record
Francesca Palombini No Record
John Scudder No Record
Lars Eggert No Record
Martin Duke No Record
Murray Kucherawy No Record
Paul Wouters No Record
Robert Wilton No Record
Roman Danyliw No Record
Warren Kumari No Record
Zaheduzzaman Sarker No Record
Éric Vyncke No Record
(Benoît Claise; former steering group member) 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.
(Pete Resnick; former steering group member) 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.
(Adrian Farrel; former steering group member) Yes
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.
(Joel Jaeggli; former steering group member) Yes
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.
(Sean Turner; former steering group member) Yes
All about fixing the mistake.
(Ted Lemon; former steering group member) Yes
(Jari Arkko; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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.
(Stephen Farrell; former steering group member) No Objection
I'm ok with fixing this with or without an RFC.
(Stewart Bryant; former steering group member) (was Yes) No Objection
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.
(Barry Leiba; former steering group member) Abstain
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.
(Brian Haberman; former steering group member) Abstain
I fully support Pete's (and Barry's) point that this document is not needed.