The Diameter Capabilities Update Application
draft-ietf-dime-capablities-update-07
Yes
(Dan Romascanu)
(Jari Arkko)
No Objection
(Adrian Farrel)
(David Harrington)
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Tim Polk)
Note: This ballot was opened for revision 07 and is now closed.
Dan Romascanu Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2010-10-20)
Unknown
4. Capabilities Update When the capabilities of a Diameter node conforming to this specification change, it MUST notify all of the nodes with which it has an open transport connection and have I think you should insert "which" before "have", because support for this extension needs to be advertised by peers, not the node. A Diameter node only issues a given command to those peers that have advertised support for the Diameter application that defines the command; a Diameter node must cache the supported applications in order to ensure that unrecognized commands and/or Attibute-Value typo: Attribute-Value Pairs (AVPs) are not unnecessarily sent to a peer. 5. Security Considerations The security considerations applicable to the Diameter Base Protocol [I-D.ietf-dime-rfc3588bis] are also applicable to this document. This looks a bit weak, are you sure this extension doesn't raise new security issues?
David Harrington Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2010-10-20)
Unknown
I support Peter's discuss. Section 1., paragraph 3: > Discussion of this draft may be directed to the dime Working Group of > the IETF (dime@ietf.org). Remove. Section 4., paragraph 2: > order to ensure that unrecognized commands and/or Attibute-Value Nit: s/Attibute-Value/Attribute-Value/
Peter Saint-Andre Former IESG member
(was Discuss)
No Objection
No Objection
(2010-10-19)
Unknown
1. In Section 4, there is a typo: "Attibute-Value"
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2010-10-20)
Unknown
Support Peter's discuss. I also suggest being even more explicit about what an implementation should/could do if a peer tries to modify the things this document declares unmodifiable.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2010-10-20)
Unknown
I support Peter's discuss.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
(2010-10-20)
Unknown
I support Peter's discuss.