Updates to DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery
draft-boucadair-rfc6153-update-01
Discuss
Yes
(Ted Lemon)
No Objection
(Jari Arkko)
(Martin Stiemerling)
Abstain
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Benoît Claise Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-09-23)
Unknown
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 IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-09-21)
Unknown
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 IESG member
Yes
Yes
(2013-09-22)
Unknown
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 IESG member
Yes
Yes
(2013-09-23)
Unknown
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 IESG member
Yes
Yes
(2013-09-18)
Unknown
All about fixing the mistake.
Ted Lemon Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2013-09-23)
Unknown
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 IESG member
No Objection
No Objection
(2013-09-24)
Unknown
I'm ok with fixing this with or without an RFC.
Stewart Bryant Former IESG member
(was Yes)
No Objection
No Objection
(2013-09-25)
Unknown
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 IESG member
Abstain
Abstain
(2013-09-22)
Unknown
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 IESG member
Abstain
Abstain
(2013-09-23)
Unknown
I fully support Pete's (and Barry's) point that this document is not needed.