Access Network Identifier (ANI) Option for Proxy Mobile IPv6
Summary: Needs 5 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 10 and is now closed.
Brian Haberman Yes
( Ron Bonica ) No Objection
( Stewart Bryant ) No Objection
( Gonzalo Camarillo ) No Objection
Benoit Claise (was Discuss) No Objection
( Ralph Droms ) (was Discuss) No Objection
Comment (2012-07-19 for -11)
( Wesley Eddy ) No Objection
( Adrian Farrel ) No Objection
Comment (2012-05-23 for -10)
This is a not-quite-Discuss Comment I think a number of references listed as Informative need to be moved to Normative. Specifically: SMI RFC 3629 RFC 1035 RFC 6275 I am in two mindsabout RFC2460. Happy to discuss why/whether this would be appropriate, but it looks like the uses are explicit "do encode this thing you need to read this reference" type of statements.
Stephen Farrell (was Discuss) No Objection
( Russ Housley ) No Objection
Barry Leiba No Objection
Comment (2012-05-16 for -10)
IANA Considerations rant: o Action-1: This specification defines a new Mobility Header option, the Access Network Identifier. This mobility option is described in Section 3. The Type value for this option needs to be assigned from the same numbering space as allocated for the other mobility options, as defined in [RFC6275]. I noticed the same problem that confused IANA, and was going to kick in a DISCUSS to get it fixed: the registry is called "Mobility Options", and referring to it as a "Mobility Header option" confused it with the "Mobility Header Types" registry. No need for the DISCUSS, though, because the author noticed the error in Pearl's proposed IANA actions, and sorted it out by email. So this comment will just serve to beat people up about this, and to rant a bit. You can otherwise ignore it: Folks, it's just not that hard to go to http://www.iana.org/protocols/ and actually *look up* the correct name of the registry you aim to use... and then to use the *exact* name. Please be specific and accurate; it's important.
( Pete Resnick ) (was Discuss) No Objection
( Robert Sparks ) (was Discuss) No Objection
Comment (2012-08-09 for -13)
I assume the conclusion of the discussion you were having at IETF about the encoding of SSIDs fell out to UTF-8 instead of raw bits?
Martin Stiemerling No Objection
( spt ) No Objection
Comment (2012-05-24 for -10)
I'm piling on with Stephen and Robert.