Subject: [Dime] review of the draft-ietf-dime-capablities-update-04

From: <[email-masked]>
Date: Wed, 16 Jun 2010 15:54:22 +0200

Hi,

Please find below the comments/questions after the review of the last
version of draft-ietf-dime-capablities-update
(http://tools.ietf.org/html/draft-ietf-dime-capablities-update-04)

Regards,

Lionel

******
Section 3.  Diameter Protocol Considerations

   This document specifies Diameter Application-ID <TBD1>.  Diameter
   nodes conforming to this specification MUST advertise support by
   including the value <TBD1> in the Auth-Application-Id of the
   Capabilities-Exchange-Req and Capabilities-Exchange-Answer commands
   [RFC3588].

==> s/Capabilities-Exchange-Req and/Capabilities-Exchange-Request and

******
Section 4. Capabilities Update

   When the capabilities of a Diameter node conforming to this
   specification change, it SHOULD notify all of the nodes with which it
   has an open transport connection and have also advertised support for
   the Capabilities Update application using the Capabilities-Update-
   Request message (Section 4.1.1).  This message allows the update of a
   peer's capabilities (supported Diameter applications, etc.).

 ==> Any specific reason for a SHOULD? I understand that the assumption
here is that there is a kind of "always-on" connection between peers and
if you want to advertize the other peer of any change, you have to send
this notification. Is it assumed the ONLY drawback of not sending the
notification is that the other peers will remain unaware of the change,
making useless of the whole application?

==> s/using the Capabilities-Update-Request message (Section
4.1.1)/using the Capabilities-Update-Request (CUR) message (Section
4.1.1)

********
Section 4

   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 AVPs are not
   unnecessarily sent to a peer.

==> the second sentence is correct, but "MUST" refers to the RFC 3588,
not to this specification.

******
Section 4

   The receiver of the CUR MUST determine common applications by
   computing the intersection of its own set of supported Application Id
   against all of the application identifier AVPs (Auth-Application-Id,
   Acct-Application-Id and Vendor-Specific- Application-Id) present in
   the CUR.  

==> First occurrence of CUR in the first sentence.
s/The receiver of the CUR/The receiver of the
Capabilities-Update-Request (CUR)

******
Section 4

   If the receiver of a Capabilities-Update-Req (CUR) message does not
   have any applications in common with the sender then it MUST return a
   Capabilities-Update-Answer (CUA) (Section 4.1.2) with the Result-Code
   AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the
   transport layer connection; however, if active sessions are using the
   connection, peers MAY delay disconnection until the sessions can be
   redirected or gracefully terminated.  Note that receiving a CUA from
   a peer advertising itself as a Relay (see [RFC3588], Section 2.4)
   MUST be interpreted as having common applications with the peer.

==> If there no (more) common application, what will be the purpose of
maintaining transport layer connection? You may delay the release of any
ongoing user session (while trying to redirect AAA signaling to another
peer) but it will be anyway inpossible to rely on the "previous"
diameter connection with the "updated" peer anyway for sending/receiving
Diameter commands. Could you please clarify the intention of this "MAY
delay disconnection"?

******
Section 4

  The CUR and CUA messages MUST NOT be proxied, redirected or relayed.

==> woudl be useful to add that it is excatly in the same way as for
CER/CEA, just to understand.

******
Section 4

   Even though the CUR/CUA messages cannot be proxied, it is still
   possible for an upstream agent to receive a message for which there
   are no peers available to handle the application that corresponds to
   the Command-Code.  This could happen if, for example, the peers are
   too busy or down.  In such instances, the 'E' bit MUST be set in the
   answer message with the Result-Code AVP set to
   DIAMETER_UNABLE_TO_DELIVER to inform the downstream peer to take
   action (e.g., re-routing requests to an alternate peer).

==> Is there any specificity here compared to the normal behaviour
described in RFC3588; If not, is it really needed to keep this text, as
it is anyway assume that you need the RFC3588 to handle correctly this
diameter application?

******
Section 4.1.2. Capabilities-Update-Answer

   The Capabilities-Update-Answer indicated by the Command-Code set to
   <TBD3> and the Command Flags' 'R' bit set, is sent in response to a
   CUR message.

==> s/'R' bit set/'R' bit cleared

Lionel Morand

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 18 Jun 2010 15:17:55 +0700

> ==> s/Capabilities-Exchange-Req and/Capabilities-Exchange-Request and

OK, good catch; the same change must be made globally in
http://www.ietf.org/id/draft-ietf-dime-rfc3588bis-21.txt, since the same
error occurs there.

> making useless of the whole application?

Changed to MUST.

> 4.1.1)/using the Capabilities-Update-Request (CUR) message (Section

OK

> not to this specification.

Don't understand.

> Capabilities-Update-Request (CUR)

Why?  The acronym has been expanded before...

> Diameter commands. Could you please clarify the intention of this "MAY

I'm assuming that an administrator might want to signal that an certain app
will no longer be available (thereby avoiding service interruption) _before_
the application is actually removed/disabled.

> CER/CEA, just to understand.

Again, I'm not sure why this would be needed...

> it is anyway assume that you need the RFC3588 to handle correctly this

Don't understand: RFC 3588 (BTW, I've changed the refs to RFC 3588 to
draft-ietf-dime-rfc3588bis) doesn't talk about this app at all; why would
one assume that the CUR/CUA commands are the same as CER/CEA?

> ==> s/'R' bit set/'R' bit cleared

OK

---

From: <[email-masked]>
Date: Sat, 19 Jun 2010 01:43:15 +0200

Hi Glen,

Thank you for a so prompt answer.

See below.

Regards,

Lionel

> -----Message d'origine-----
> De : Glen Zorn [mailto:[email-masked]] 
> Envoyé : vendredi 18 juin 2010 10:18
> À : MORAND Lionel RD-CORE-ISS
> Cc : [email-masked]; [email-masked]
> Objet : RE: review of the draft-ietf-dime-capablities-update-04
> 
> http://www.ietf.org/id/draft-ietf-dime-rfc3588bis-21.txt, 
> since the same error occurs there.
> 
> > 
> > ******
> >  ==> Any specific reason for a SHOULD? I understand that the 
> > assumption here is that there is a kind of "always-on" connection 
> > between peers and if you want to advertize the other peer of any 
> > change, you have to send this notification. Is it assumed the ONLY 
> > drawback of not sending the notification is that the other 
> peers will 
> > remain unaware of the change, making useless of the whole 
> application?
> 
> Changed to MUST.

OK.

> > not to this specification.

Sorry. The question is: why MUST in capital letters in this specification whereas this one is related to a normal behaviour of peer following the RC3588? If I'm correct "MUST", SHOULD", etc. applies to requirements defined by the present specification according  to RFC2119. 

> Why?  The acronym has been expanded before...

OK. It was there OR at the previous occurrence ;)

> > maintaining transport layer connection? You may delay the 
> release of 
> > any ongoing user session (while trying to redirect AAA signaling to 
> > another
> > diameter connection with the "updated" peer anyway for 
> > sending/receiving Diameter commands. Could you please clarify the 
> > intention of this "MAY delay disconnection"?
> 
> I'm assuming that an administrator might want to signal that 
> an certain app will no longer be available (thereby avoiding 
> service interruption) _before_ the application is actually 
> removed/disabled.

OK.

> Again, I'm not sure why this would be needed...

The main purpose of this application is to "enhance" the general purpose of capability exchange. So, in my understanding, what is applicable to CER/CEA applies automatically to CUR/CUA except stated otherwise. But it was just an open proposal. Something like:

  "As for CER/CEA messages, the CUR and CUA messages MUST NOT be proxied, redirected or relayed."

> > described in RFC3588; If not, is it really needed to keep 
> this text, 
> > as it is anyway assume that you need the RFC3588 to handle 
> correctly 
> > this diameter application?
> 
> draft-ietf-dime-rfc3588bis) doesn't talk about this app at 
> all; why would one assume that the CUR/CUA commands are the 
> same as CER/CEA?

I was referring here to the description on how to handle unsupported command-code, that is specified in RFC3588 and may be not needed here, except if you want to highlight something specific.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 19 Jun 2010 16:23:35 +0700

...

> Sorry. The question is: why MUST in capital letters in this
> specification whereas this one is related to a normal behaviour of peer
> following the RC3588? If I'm correct "MUST", SHOULD", etc. applies to
> requirements defined by the present specification according  to RFC2119.

So the desired change is from "A Diameter node MUST cache" to "A Diameter
node must cache"?

...

> The main purpose of this application is to "enhance" the general purpose
> of capability exchange. So, in my understanding, what is applicable to
> CER/CEA applies automatically to CUR/CUA except stated otherwise. 

OK, but I don't think that the draft says (or even really implies) that
anywhere...

> But it
> was just an open proposal. Something like:
> 

OK.

> I was referring here to the description on how to handle unsupported
> command-code, that is specified in RFC3588 and may be not needed here,
> except if you want to highlight something specific.

I'm not sure what harm it does, though.

...

---

From: <[email-masked]>
Date: Sun, 20 Jun 2010 23:37:34 +0200

Hi Glen,

See below.

Lionel

> Envoyé : samedi 19 juin 2010 11:24
> > specification whereas this one is related to a normal behaviour of 
> > peer following the RC3588? If I'm correct "MUST", SHOULD", etc. 
> > applies to requirements defined by the present 
> specification according  to RFC2119.
> 
> So the desired change is from "A Diameter node MUST cache" to 
> "A Diameter node must cache"?

Actually, I would propose to remove the second paragraph and modify the beginning of the section as follow:

New:

   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 also advertised support for
   the Capabilities Update application using the Capabilities-Update-
   Request (CUR) message (Section 4.1.1).  This message allows the
   update of a peer's capabilities (supported Diameter applications,
   etc.) [received in an initial Capability-Exchange-Request or in a previous CUR].

   [As with a CER], the receiver of the CUR MUST determine common
   applications by computing the intersection of its own set of 
   supported Application Id against all of the application identifier AVPs
   (Auth-Application-Id, Acct-Application-Id and Vendor-Specific-
   Application-Id) present in the CUR [and MUST cache the resulting set 
   of applications supported by the peer]. The value of the Vendor-Id AVP in the 
   Vendor-Specific-Application-Id MUST NOT be used during computation.

According to the proposed modification at the end of the first paragraph, do you confirm that CUR will be always sent after an initial CER?
Therefore, what should be the behaviour of a peer receiving the CUR from a known peer which has no ongoing connection with? Should it reject the request or process it as a CER?

> > The main purpose of this application is to "enhance" the general 
> > purpose of capability exchange. So, in my understanding, what is 
> > applicable to CER/CEA applies automatically to CUR/CUA 
> except stated otherwise.
> 
> OK, but I don't think that the draft says (or even really 
> implies) that anywhere...
> 
> > But it
> > > Don't understand: RFC 3588 (BTW, I've changed the refs to 
> RFC 3588 
> > > to
> > > draft-ietf-dime-rfc3588bis) doesn't talk about this app 
> at all; why 
> > > would one assume that the CUR/CUA commands are the same 
> as CER/CEA?
> >

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 21 Jun 2010 08:30:46 +0700

...

> According to the proposed modification at the end of the first
> paragraph, do you confirm that CUR will be always sent after an initial
> CER?

Of course; the proposed change seems to just beat one to death with the club
of the obvious ;-)

> Therefore, what should be the behaviour of a peer receiving the CUR from
> a known peer which has no ongoing connection with? Should it reject the
> request or process it as a CER?

Again, that's pretty obviously a protocol error.  What should happen if a
AAR is received before a CER?  It's the same thing...

...

---

From: <[email-masked]>
Date: Mon, 21 Jun 2010 03:48:45 +0200

> > > So the desired change is from "A Diameter node MUST cache" to "A 
> > > Diameter node must cache"?
> > 
> >    etc.) [received in an initial 
> Capability-Exchange-Request or in a 
> > previous CUR].
> > 
> >    supported Application Id against all of the application 
> identifier 
> > AVPs
> >    of applications supported by the peer]. The value of the 
> Vendor-Id 
> > AVP in the
> > paragraph, do you confirm that CUR will be always sent after an 
> > initial CER?
> 
> Of course; the proposed change seems to just beat one to 
> death with the club of the obvious ;-)
> 
> > Therefore, what should be the behaviour of a peer receiving the CUR 
> > from a known peer which has no ongoing connection with? Should it 
> > reject the request or process it as a CER?
> 
> Again, that's pretty obviously a protocol error.  What should 
> happen if a AAR is received before a CER?  It's the same thing...
> 

I admit that it is obvious... But not said in the draft. According to
the current text, the receiving peer just compares the supported
applications received in the CUR to in its own set of supported
applications, without checking if there is an ongoing connection. I
think that this check should be an additional step compared to the
normal handling of the CER. But I may be wrong...

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 21 Jun 2010 11:11:40 +0700

> normal handling of the CER. But I may be wrong...

This is an _application_.  How is it possible to receive an application
message w/o an active transport connection?  How is it possible to have an
active transport connection w/o there having been a CER/CEA exchange?  I
don't understand.