Subject: RE: [Dime] Summary of 3588bis Issues Status

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Wed, 19 Jul 2006 15:53:19 +0200

Victor,

>These text applies to 4005 and 4072 as they reference the base .... 
>there are other diameter implementations beyond this.

Unless you are talking of some proprietary application I think what we have to date are, in addition to 4005 and 4072, RFC 4004 and RFC 4006.

RFC 4004 section 4

   The value of zero (0) SHOULD be used as the
   Application-Id in all STR/STA and ASR/ASA commands, as these are
   defined in the Diameter base protocol and no additional mandatory
   AVPs for those commands are defined in this document.

   Given the nature of Mobile IPv4, re-authentication can only be
   initiated by a mobile node, which does not participate in the
   Diameter message exchanges.  Therefore, Diameter server initiated
   re-auth does not apply to this application, and RAR/RAA commands MUST
   NOT be sent for Diameter Mobile IPv4 sessions.

RFC 4006 I think was extensively discussed in the list.

So, what is beyond that? Please explain.

If you now write a text in RFC 3588bis as the one I proposed (below) I don't see any issue beyond those standard applications that already use app id 0 (as defined in RFCs).

" RAR,RAA,STR,STA,ASR,ASA use application id of 0 (Diameter Common Messages) unless a service specific application augments those messages with mandatory AVPs ('M' bit set) that define application specific behavior (one example can be found in RFC 4006 for the RAR message)."

Regards
Marco

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: mercoledì 19 luglio 2006 15.46
To: STURA, Marco, VF-IT
Cc: [email-masked]
Subject: Re: [Dime] Summary of 3588bis Issues Status

Hi Marco,
>> I don't see this as a drastic paradigm shift. Actually the reason for this
>> thread is that the text in RFC3588 can be interpreted in different ways, so
>> whether there is a shift or not depends of ones understanding of the >current
>> specifications -where obviously people have different interpretations-.
>>     
>
> I still don't see how there could be different interpretations of implementers of standard applications given the clear text written there, as pointed out by Pasi too (see below).
>   

These text applies to 4005 and 4072 as they reference the base .... 
there are other diameter implementations beyond this.

my two cents,
victor

>   
>> RFC 4005, Section 1.3: "All other messages are defined by [BASE] and use >the Base application id value."
>>     
>
>   
>> RFC 4072, Section 3, last paragraph: "the others [RAR,RAA,STR,STA,ASR,ASA] >use 0 (Diameter Common Messages)."
>>     
>
>   
>> This should not lead to interoperability problems unless the implementors >can't read the specs. And in that case, producing more specs is unlikely to >be of help.
>>     
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]] 
> Sent: mercoledì 19 luglio 2006 14.04
> To: STURA, Marco, VF-IT; Victor Fajardo
> Cc: [email-masked]
> Subject: RE: [Dime] Summary of 3588bis Issues Status
>
> Marco,
>
> I understand your point. OTOH, to me it sounds strange to leave decisions
> related with session life cycle to anything else than the application logic,
> because it usually is dependent on the type of application and the context
> of the scenario.
>
> The way I see it is as follows:
> a) We have hop-to-hop messages, to be consumed by base diameter.
> b) We have messages defined by base protocol, which are related with session
> life-cycle, are generic in nature -hence defined in base diameter rather
> than replicated in every new application specification-, and are consumed by
> application.
> c) Messages which are defined by applications.
>
> I don't see this as a drastic paradigm shift. Actually the reason for this
> thread is that the text in RFC3588 can be interpreted in different ways, so
> whether there is a shift or not depends of ones understanding of the current
> specifications -where obviously people have different interpretations-.
>
>      Thanks,
>      Tolga
>   
>> -----Original Message-----
>> From: STURA, Marco, VF-IT [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 4:05 AM
>> To: Tolga Asveren; Victor Fajardo
>> Cc: [email-masked]
>> Subject: RE: [Dime] Summary of 3588bis Issues Status
>>
>>
>> Tolga,
>>
>> Diameter was defined as a framework with a set of base common
>> messages and procedures on top of which we could build additional
>> service specific application logic. This additional service
>> specific application logic is supposed to use 'utilities' from
>> the base framework such as transport and routing, session
>> handling, capability negotiation and common messages handling.
>>
>> What you're saying is changing the paradigm and philosophy of the
>> base framework; essentially you're saying that we don't have
>> common messages and common mechanisms anymore. All what RFC 3588
>> defines as session based common messages according to your
>> comments is shifted to the service specific application, hence
>> jeopardizing the entire framework. To me your proposal calls for
>> re-building the same handling for those common messages in each
>> of the service specific applications rather than applications
>> re-using the common handling offered by the base framework. Not a
>> good idea IMHO.
>>
>> Regards
>> Marco
>>
>> -----Original Message-----
>> From: Tolga Asveren [mailto:[email-masked]]
>> Sent: martedì 18 luglio 2006 18.17
>> To: STURA, Marco, VF-IT; Victor Fajardo
>> Cc: [email-masked]
>> Subject: RE: [Dime] Summary of 3588bis Issues Status
>>
>> Marco,
>>
>> I think, the reason for different point of views is mainly due to the
>> question who is considered as the owner of a session. IMHO, session is
>> better owned by the application logic, because only it has full knowledge
>> about when a session is supposed to end, hence I believe it is
>> best that any
>> session/application logic related message is handled by the
>> application. For
>> that reason, I think it is a good idea to use the App-Id of the
>> application
>> in message header for the messages under discussion.
>>
>>      Thanks,
>>      Tolga
>>
>>     
>>> -----Original Message-----
>>> From: STURA, Marco, VF-IT [mailto:[email-masked]]
>>> Sent: Tuesday, July 18, 2006 12:33 PM
>>> To: Victor Fajardo
>>> Cc: [email-masked]
>>> Subject: RE: [Dime] Summary of 3588bis Issues Status
>>>
>>>
>>> See in line.
>>>
>>> Br
>>> Marco
>>>
>>> -----Original Message-----
>>> From: Victor Fajardo [mailto:[email-masked]]
>>> Sent: martedì 18 luglio 2006 18.10
>>> To: STURA, Marco, VF-IT
>>> Cc: [email-masked]
>>> Subject: Re: [Dime] Summary of 3588bis Issues Status
>>>
>>> Hi Marco,
>>>
>>> comments inline:
>>>       
>>>>> It maybe a little bit confusing for relays with cannot resolve
>>>>>           
>>> a route via >destination-host to look at an ASR with an app id of 0.
>>>       
>>>> Interesting argument I have to say. Routing ASR based on app id
>>>>         
>>> doesn't ensure that the session ASR is supposed to kill is
>>> actually running on the client where the request is routed to.
>>> Suppose a relay agent connected to 10 clients all of which
>>> support app id x, the relay routes based on app id x to client 2
>>> but the session indicated in the <session-id> is actually running
>>> in client 5. The ASR will not kill the session as requested by
>>> the server, therefore ASR MUST use Destination-Host based routing.
>>>       
>>> I agree with your example above regarding destination-host. It is
>>> required in the case of ASR (and perhaps some other message) though I
>>> guess I was stating a case which is a little bit different than your
>>> example above. I was thinking of the following case:
>>>
>>> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server
>>>
>>> in this case relay2 will not be able to route using dest-host. This is
>>> where dest-realm and app id becomes important. In this case app id of 0
>>> might not work as well ... or maybe I'm wrong.
>>>
>>> [MSt] In this case R1 would advertise it self as a relay (i.e.
>>> 0xffffffff) it won't advertise app id x or y or z. So, any app id
>>> would be routed to R1 by R2.
>>>
>>>       
>>>> Same argument stands for RAR.
>>>>
>>>> In fact the base defines ASR and RAR with Destination-Host AVP
>>>>         
>>> as mandatory in the ABNF of the message.
>>>       
>>>> I think in the AAA thread also available in the issue tracker
>>>>         
>>> there were arguments why ASR is really a common message, same
>>> would be for RAR if no mandatory AVPs are defined by the application.
>>>       
>>> I've read through some of the comments in the AAA thread regarding this
>>> issue and it was not clear to me why an app id of 0 is applicable to ASR
>>> and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set
>>> to 4 (CC app id).
>>>
>>> [MSt] Because the ASR or RAR requests a specific action to the
>>> client that is to be inferred to the session indicated in the
>>> <session-id>. Diameter CC sets the app id 4 in RAR because it
>>> augments the base message with mandatory AVPs defined in it with
>>> associated behavior. All ASR does is "kill the session". So, the
>>> why not stick on the original rules when RFC3588 was defined?
>>> Base common messages such as ASR and RAR MUST use app id 0 unless
>>> augmented with mandatory AVPs that define a specific behavior of
>>> the client (e.g. DCC application).
>>>
>>> hope this helps,
>>> victor
>>>
>>>       
>>>> Regards
>>>> Marco
>>>>
>>>> -----Original Message-----
>>>> From: Victor Fajardo [mailto:[email-masked]]
>>>> Sent: martedì 18 luglio 2006 16.53
>>>> To: STURA, Marco, VF-IT
>>>> Cc: [email-masked]
>>>> Subject: Re: [Dime] Summary of 3588bis Issues Status
>>>>
>>>> Hi Marco,
>>>>
>>>> The main reason (and people can correct me if i'm wrong) is that these
>>>> messages belong to the session/application using them and it is
>>>> better/easier to co-relate these messages to the said
>>>>         
>>> application. Since
>>>       
>>>> the base protocol really defines two sets of messages, one set is for
>>>> session/application usage and another for peer connectivity,
>>>>         
>> it is also
>>     
>>>> semantically correct for the the session message to carry the
>>>>         
>> app id of
>>     
>>>> the session.
>>>>
>>>> In addition, for implementations, it is more practical to look at the
>>>> app id in the header to determine the application that a
>>>>         
>>> message belongs
>>>       
>>>> to ... and rightfully so. In my opinion, ASR belongs to this category
>>>> even if it is server directed. It maybe a little bit confusing for
>>>> relays with cannot resolve a route via destination-host to look at an
>>>> ASR with an app id of 0.
>>>>
>>>> hope this helps,
>>>> victor
>>>>
>>>>         
>>>>> Hi Victor,
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> This topic is issue #2&5 and refers to what app id
>>>>>> should "application session level" messages defined in the base
>>>>>>
>>>>>>
>>>>>>             
>>>>> protocol
>>>>>
>>>>>
>>>>>           
>>>>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current
>>>>>>             
>>> consensus in the
>>>       
>>>>>> meeting and more likely in this list as well is that it MUST
>>>>>>             
>>> carry the
>>>       
>>>>>> app id of the application using it.
>>>>>>
>>>>>>
>>>>>>             
>>>>> Could you bring some light on the reasons behind this consensus? I
>>>>> thought the discussion in the old AAA list was toward a consensus on
>>>>> using Appl ID 0 at least for the ASR/ASA Diameter common messages.
>>>>>
>>>>> Regards
>>>>> Marco
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/dime
>>>       
>>     
>
>
>
>
>
>   

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 19 Jul 2006 10:17:01 -0400

Hi Marco,
> " RAR,RAA,STR,STA,ASR,ASA use application id of 0 (Diameter Common Messages) unless a service specific application augments those messages with mandatory AVPs ('M' bit set) that define application…

I appreciate the discussion and the proposed text. Seeing as how there 
are contending opinions that will never coalesce I think I will leave it 
up to the chairs to arbitrate on the matter. I would not want to decide 
immediately on what text should be added to 3588bis.

my two cents,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Jul 2006 09:58:19 -0400

Marco,

I believe the point is whether it is RFC3588 or the RFCs you quoted needs to
be fixed. I am puzzled how those RFcs had such statements, which IMO clearly
violate what is said about Application-ID in RFC3588 3. Diameter Header
section.

Another point is that considering existing few applications you mentioned is
not really enough. There are also diameter base stack implementations, which
conform to RFC3588 and provide generic capability for any type of
application.

(Just read now Victor just posted in terms of how to proceed in this issue
and I agree with him. Probably the arguments are clear and somehow a
decision needs to be made, so that everybody can interoperate)

    Thanks,
    Tolga

> Sent: Wednesday, July 19, 2006 9:53 AM
> To: Victor Fajardo
> Cc: [email-masked]
> Unless you are talking of some proprietary application I think
> what we have to date are, in addition to 4005 and 4072, RFC 4004
> and RFC 4006.
>
> RFC 4004 section 4
>
> If you now write a text in RFC 3588bis as the one I proposed
> (below) I don't see any issue beyond those standard applications
> that already use app id 0 (as defined in RFCs).
>
> " RAR,RAA,STR,STA,ASR,ASA use application id of 0 (Diameter
> Common Messages) unless a service specific application augments
> those messages with mandatory AVPs ('M' bit set) that define
> application specific behavior (one example can be found in RFC
> 4006 for the RAR message)."
>
> Regards
> Marco
>
> > I still don't see how there could be different interpretations
> of implementers of standard applications given the clear text
> written there, as pointed out by Pasi too (see below).
> >
>
>
> >> RFC 4005, Section 1.3: "All other messages are defined by
> [BASE] and use >the Base application id value."
> >>
> >
> >
> >> RFC 4072, Section 3, last paragraph: "the others
> [RAR,RAA,STR,STA,ASR,ASA] >use 0 (Diameter Common Messages)."
> >>
> >
> >
> >> This should not lead to interoperability problems unless the
> implementors >can't read the specs. And in that case, producing
> more specs is unlikely to >be of help.
> >>
> >