[Dime] FW: DISCUSS and COMMENT: <draft-ietf-dime-capablities-update-06.txt>

["Romascanu, Dan (Dan)" <[e-mail]>]

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Peter Saint-Andre
Sent: Tuesday, October 19, 2010 11:53 PM
To: [e-mail]
Cc: [e-mail];
[e-mail]
Subject: DISCUSS and COMMENT:
<draft-ietf-dime-capablities-update-06.txt>

Discuss:
1. Let me see if I understand this. The basic idea is that any two
Diameter nodes can dynamically inform each other when their capabilities
have changed, without forcing a reconnection. There are several kinds of
capabilities that might change, such as (a) security mechanisms, (b)
commands related to a particular application, and (c) the list of
applications supported. It seems that several rules apply: (a) do not
attempt to dynamically modify a security mechanism that is currently in
use, because reconnection is required, (b) send updated commands related
to a given application only to those peers which also support that
application, and (c) send an updated list of supported applications to
all peers [this seems to implicit].

Unfortunately, these rules are not explained very clearly, and certain
matters are left unspecified:

a. Is it OK to dynamically inform peers about capabilities security
mechanisms that are *not* currently in use for that connection?

b. When a node receives a Capabilities Update Request (CUR) from a peer,
it needs to check if the two entities have any supported applications in
common, and if not it SHOULD disconnect the transport connection. Why?
Does this behavior protect against some unspecified threat? Does this
behavior prevent two entities from exchanging a CUR that updates the
list of supported applications (i.e., if they currently have no
supported applications in common)?

c. Is the Capabilities Update Application limited to informing peers
about new/changed capabilities, or does it also assume that based on
communication of those new/changed capabilities a peer MAY/SHOULD/MUST
take action based on those modified capabilities (e.g., "modifying the
security mechanism")?

Comment:
1. In Section 4, there is a typo: "Attibute-Value"