Subject: RE: [AAA-WG]: Application IDs for EAP

From: "Glen Zorn" <[email-masked]>
Date: Fri, 2 Jul 2004 11:55:30 -0700

Bernard Aboba <mailto:[email-masked]> writes:

...
 
> RFC 3588 is very explicit on this point -- new application IDs can
> only be used if the command is fundamentally changed, such as by
> changing the round-trips, or adding a new mandatory AVP.  Otherwise
> the existing command definition (and application ID) is used.  Doing
> anything else breaks Diameter interoperability.   

However, by defining the Service-Identifier AVP as a kind of qualifier
for the application ID draft-ietf-aaa-diameter-cc-05.txt allows the
definition of new service-specific (and even vendor-specific) mandatory
AVPs while continuing to use the CC app ID.

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 5 Jul 2004 14:26:55 -0700 (PDT)

> AVPs while continuing to use the CC app ID.

As I understood it, these new AVPs were not "mandatory" in the sense that
the Service-Identifier AVP allowed their use to be negotiated, and
therefore they would only be sent if the endpoints supported them. So I
don't see any contradiction between those two points of view.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 5 Jul 2004 19:39:40 -0700

Bernard Aboba <mailto:[email-masked]> writes:

>> However, by defining the Service-Identifier AVP as a kind of
>> qualifier for the application ID draft-ietf-aaa-diameter-cc-05.txt
>> allows the definition of new service-specific (and even
>> vendor-specific) mandatory AVPs while continuing to use the CC app
>> ID. 
> 
> As I understood it, these new AVPs were not "mandatory" in the sense
> that the Service-Identifier AVP allowed their use to be negotiated,
> and therefore they would only be sent if the endpoints supported
> them. So I don't see any contradiction between those two points of
> view. 

Sorry, my comments arose from the -05 version of the draft, in which the
inclusion of the Service-Identifier in the CCR/CCA is optional.
Apparently that problem is being fixed.   

Hope this helps,

~gwz

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 5 Jul 2004 22:43:24 -0700

> them. So I don't see any contradiction between those two points of

Hmm.  It seems like that depends upon how you define the term
"negotiated". Section 4.1, para. 5 of draft-ietf-aaa-diameter-cc-05.txt
says

   This specification, together with service specific documents, is 
   governing the credit control message. The rule is that service 
   specific documents only define what existing AVPs or new AVPs are 
   used as input to the rating process (i.e. they do not define new 
   credit control applications), and thus need to be included in the 
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Credit-Control-Request command by a Diameter Credit Control Client 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   supporting a given service as *[AVP].
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So it looks to me as if negotiation in this case means basically sending
CCRs to every DCCA server you can find until you don't get back an
error; however, since the error you get back will be an application
error rather than a protocol error, neither relays nor proxies can help
you out.  So unless you are only one hop from a good server, protocol
behavior may be nondeterministic (especially in the case of relays)
because without looking pretty deep into the packet there's no way to
know that just forwarding the next CCR to the same server.  Proxy agents
might be able to handle this, but not relays.  In addition, if multiple
proxies are available to the client there is no way for it to know which
of them (if any) supports the correct service(s) because the
Service-Identifier AVP isn't included in the CER.

Hope this helps,

~gwz