Diameter Base Protocol
draft-ietf-dime-rfc3588bis-34
Yes
(Benoît Claise)
(Dan Romascanu)
No Objection
(Adrian Farrel)
(Brian Haberman)
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)
Recuse
(Jari Arkko)
Note: This ballot was opened for revision 29 and is now closed.
Benoît Claise Former IESG member
Yes
Yes
(for -31)
Unknown
Dan Romascanu Former IESG member
Yes
Yes
()
Unknown
Stephen Farrell Former IESG member
(was Discuss)
Yes
Yes
(2012-03-11 for -31)
Unknown
Since -31 says that Diameter MUST be used with one of TLS, DTLS or IPsec, that clears my discuss. Thanks.
Adrian Farrel Former IESG member
No Objection
No Objection
(for -29)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -31)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2012-05-05 for -32)
Unknown
Thanks for addressing all of my comments. It seems you missed a few things in the conversion from "ABNF" to "CCF": 1.1.3 - You say "command ABNFs" when I think you mean "CCFs". If correct, you should also spell it out the first time you use it: "Command Code Format (CCF)". 1.2 - You should define "CCF". 3.2 - In the comment "avp-name", you say "command ABNFs" when I think you mean "CCFs". These could all be done in an RFC Editor note if your AD agrees; no need for a new revision.
Peter Saint-Andre Former IESG member
(was Discuss)
No Objection
No Objection
(2012-03-12 for -31)
Unknown
Thank you for addressing my concerns about the IANA considerations. I have two other comments: 1. In Section 1.3.3, this specification has "[d]eprecated the exchange of CER/CEA messages in the open state" but "assume[s] that the capabilities exchange in the open state will be re-introduced in a separate specification". Do we really want to actively deprecate something that it's assumed will return in the not-too-distant future? Or do we want to change "will be re-introduced" to "might be re-introduced"? 2. It might be helpful to explain why the End-to-End security framework has been deprecated. Did it not work properly? Did no one implement it? Were there such significant interoperability problems that it was deemed better to scrap it? And, will it be (or does it need to be) replaced by something else?
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
(was Discuss)
No Objection
No Objection
(2012-03-29 for -31)
Unknown
Thanks for addressing my concerns.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2012-03-12 for -32)
Unknown
#18) s5.2: Name matching has proved to be a challenge for many in the TLS/DTLS environment. A pointer to RFC 6125 would be much appreciated.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
Recuse
Recuse
(for -29)
Unknown