Skip to main content

The Diameter Capabilities Update Application
RFC 6737

Yes

(Dan Romascanu)
(Jari Arkko)

No Objection

(Adrian Farrel)
(David Harrington)
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)

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

Lars Eggert No Objection

Comment (2010-10-20)
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

Yes ()

                            

(Jari Arkko; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2010-10-20)
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

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Peter Saint-Andre; former steering group member) (was Discuss) No Objection

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

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection (2010-10-20)
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

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) No Objection

No Objection (2010-10-20)
I support Peter's discuss.

(Stewart Bryant; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (2010-10-20)
I support Peter's discuss.