The Diameter Capabilities Update Application
RFC 6737
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert No Objection
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/
(Dan Romascanu; former steering group member) Yes
(Jari Arkko; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
(Alexey Melnikov; former steering group member) (was Discuss) No Objection
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 steering group member) (was Discuss) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) (was Discuss) No Objection
1. In Section 4, there is a typo: "Attibute-Value"
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
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 steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
I support Peter's discuss.
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) (was Discuss) No Objection
I support Peter's discuss.