Skip to main content

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

Alvaro Retana
Andrew Alston
Erik Kline
Francesca Palombini
John Scudder
Lars Eggert
Martin Duke
Murray Kucherawy
Paul Wouters
Robert Wilton
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

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

Discuss [Treat as non-blocking comment] (2013-09-23)
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

Discuss [Treat as non-blocking comment] (2013-09-21)
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

Yes (2013-09-22)
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

Yes (2013-09-23)
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

Yes (2013-09-18)
All about fixing the mistake.

(Ted Lemon; former steering group member) Yes

Yes ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection ()

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (2013-09-23)
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

No Objection (2013-09-24)
I'm ok with fixing this with or without an RFC.

(Stewart Bryant; former steering group member) (was Yes) No Objection

No Objection (2013-09-25)
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

Abstain (2013-09-22)
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

Abstain (2013-09-23)
I fully support Pete's (and Barry's) point that this document is not needed.