The Diameter Capabilities Update Application
RFC 6737

Note: This ballot was opened for revision 07 and is now closed.

(Jari Arkko) Yes

(Dan Romascanu) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Lars Eggert No Objection

Comment (2010-10-20 for -)
No email
send info
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/

(Adrian Farrel) (was Discuss) No Objection

(David Harrington) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2010-10-20)
No email
send info
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?

(Tim Polk) (was Discuss) No Objection

Comment (2010-10-20)
No email
send info
I support Peter's discuss.

(Peter Saint-Andre) (was Discuss) No Objection

Comment (2010-10-19)
No email
send info
1. In Section 4, there is a typo: "Attibute-Value"

(Robert Sparks) No Objection

Comment (2010-10-20 for -)
No email
send info
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.

(Sean Turner) No Objection

Comment (2010-10-20 for -)
No email
send info
I support Peter's discuss.