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

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

Fully agree with Pasi.

And, as far as I know, there are implementations out there that comply with the specs refereed by Pasi and surprisingly inter-work successfully. There are also implementations that comply with RFC 4006, where application specific behavior is defined as a result of the RAR message if certain mandatory AVPs were present (e.g. credit pool re-authorization vs full session re-authorization).

So, I think the rule should be

" 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: [email-masked] [mailto:[email-masked]] 
Sent: mercoledì 19 luglio 2006 11.39
To: [email-masked]; STURA, Marco, VF-IT
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

Victor Fajardo wrote:
> I'm still not sure why we 'MUST' use app id of 0 ? 

In the case of RFC 4005 and 4072: because the spec says so?

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.

<snip>

> Unless I have the wrong take on this issue, there is a consensus
> that we should just use the app id of the application for simplicity
> and correctness.

The last time this was discussed, there was consensus that using 0 is
the right answer, and this lead to adding the above-quoted text to RFC
4005 and 4072.

So unless the approach in 4005/4072 leads to significant problems,
even when correctly implemented, I'd suggest not changing it.
Changing it could also lead to interoperability problems with
those implementations that correctly implement 4005/4072.

Best regards,
Pasi

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

---

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

[TOLGA]Probably this is not the optimum way to achieve routing, especially
considering that it would happen statistically for half of the session
life-cycle related messages, if App-Id=0 is used.

Only for server initiated messages and as I said a more realistic deployment is one logical proxy that enforces policies for all applications of the Real A.

Marco

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

Marco,

Please see below for comments.

   Thanks,
   Tolga

> From: STURA, Marco, VF-IT [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 5:12 AM
> To: Tolga Asveren; Victor Fajardo
> Cc: [email-masked]
> See in line.
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: martedì 18 luglio 2006 18.52
> To: STURA, Marco, VF-IT; Victor Fajardo
> Cc: [email-masked]
> [.. snip ..]
> > 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.
> [TOLGA] Let me try to further refine the scenario:
>               *****************************
>               *  Realm A                  *
>               *                           *
>               *           +---------+     *
>               *        +--+C1 App=X |     *
>               * +----+ |  +---------+     *
>          +----*-+ P1 +-+  +---------+     *
> +---+  +-+--+ * +----+----+C2 App=Y |     *
> |S1 +--+ R1 | *           +---------+     *
> +---+  +-+--+ *                           *
>          |    * +----+                    *
>          +----*-+ P2 +----+---------+     *
>               * +----+    |C3 App=Z |     *
>               *           +---------+     *
>               *                           *
>               *****************************
> In this case, R1 wouldn't have enough knowledge to route the message
> properly to the correct proxy just by looking to the App-Id in the message
> header, if App-Id is populated with "0".
>
> [MSt] I think you assume P1 and P2 advertise supports for App x/y
> and App z respectively but I would rather consider this
> configuration an academic use case since typically you have only
> one logical Proxy as a interconnect point for a given realm in
> real deployments as a central point for policy enforcement.
> However, let see whether a server initiated message using
> Destination-Host and app id 0 based routing works.
[TOLGA]To me this configuration is not unrealistic, because Realm-A is
supporting multiple applications and that may require different policy
enforcement processing per application. Maybe a better configuration would
be to have a gateway relay in Realm-A to provide a single point of enterance
but that wouldn't change anything in the context of current discussion.
>
> S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP)
> app id 0. In the realm-based routing table R1 will certainly find
> a match for realm A and app id 0, say for instance the match is
> for P1. ASR is routed to P1, which doesn't have C3 in its peer
> table and then answers with DIAMETER_UNABLE_TO_DELIVER. R1
> attempts then to deliver the message via the alternative entry
> for Realm A, hence P2. P2 now deliver the message to C3. So,
> app-id 0 works at the end if Destination-Host based routing is
> used and, actually, is to be used for certain server initiated
> messages as also defined in RFC 3588 in section 6.1.
[TOLGA]Probably this is not the optimum way to achieve routing, especially
considering that it would happen statistically for half of the session
life-cycle related messages, if App-Id=0 is used.

---

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

[... resending...]

Pasi,

OTOH we also have the following text from RFC3588:
3. Diameter Header

Application-ID

The application-id in the header MUST be the same as what is contained in
any relevant AVPs contained in the message.

If one is building a diameter base stack following RFC3588, this sentence
probably would make them think that all messages intended for a specific
application will use applications identifier in App-Id filed of the message
header.

	Thanks,
	Tolga

> Sent: Wednesday, July 19, 2006 5:39 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Jul 2006 10:15:16 -0400

[.. resending ..]

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 what 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]
> 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
>
> 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."
> >>
> >
> >
> [RAR,RAA,STR,STA,ASR,ASA] >use 0 (Diameter Common Messages)."
> >>
> >
> >
> implementors >can't read the specs. And in that case, producing
> more specs is unlikely to >be of help.
> >>
> >
> > Sent: mercoledì 19 luglio 2006 14.04
> > 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
> >
> >> Sent: Wednesday, July 19, 2006 4:05 AM
> >> 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
> >>
> >> Sent: martedì 18 luglio 2006 18.17
> >> 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
> >>
> >>
> >>> Sent: Tuesday, July 18, 2006 12:33 PM
> >>> To: Victor Fajardo
> >>> Cc: [email-masked]
> >>> Br
> >>> 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.
> >>>
> >>>> 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
> >>>>
> >>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>

---

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Thu, 20 Jul 2006 10:37:43 +0200

>Based on Pasi's historical quotation, I think we can compromise on the app >id of 0 since it seems like such "interpretation" is already heavily >entrenched. Though I agree with Yoshi that we still need to fix the routing >issue as a side effect of this interpretation. In this way, we can agree on >something without endangering existing standards and move forward with >other issues. Would this proposal be sufficient for all interested parties ?

[MSt] I agree. I also agree with Yoshi to fix this routing issue when Destination-Host + app id 0 based routing is used in order to achieve optimal routing of the request (e.g. in the Tolga's configuration example).

> To me it is fine (not preferrable but just fine ;-) ). I just hope that this
> can be rephrased in the bis document so that we don't have interoprability
> issues in the future with people which did not follow this discussion.
>   

[MSt] I proposed some text in this thread. You may want to consider and elaborate on it.

> About routing issue, I think it can be deducted to the generic problem of
> "How can a proxy stay on the path during a session", so I believe this is
> the question to answer (which we already discussed to some extent in the
> context of strict-routing draft review)

[MSt] I agree with this too.

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

Hi Tolga,
> To me it is fine (not preferrable but just fine ;-) ). I just hope that this
> can be rephrased in the bis document so that we don't have interoprability
> issues in the future with people which did not follow this discussion.
>   

I agree :).

> I don't know whether there is already an issue open related with it, but it
> could be an idea to clarify the rules for command code namespace as well. My
> reading of RFC3588 "11.2.1 Command Codes" is that it is flat but it seems
> not everybody agrees with this and I think this is somehow related with the
> issue we are discussing. If the answer to this question is answered in the
> bis document in a clear way, I would feel better.
>   

My reading on the command code is that it is flat as well because of the 
strict allocation process.

> About routing issue, I think it can be deducted to the generic problem of
> "How can a proxy stay on the path during a session", so I believe this is
> the question to answer (which we already discussed to some extent in the
> context of strict-routing draft review)
>   

I agree.

BR,
victor

>> Sent: Wednesday, July 19, 2006 1:00 PM
>> To: Yoshihiro Ohba
>> Cc: STURA, Marco, VF-IT; Tolga Asveren; [email-masked];
>> [email-masked]
>> Hi,
>> Comments inline:
>>> I fully aggree with Marco's statement below as well as Pasi's opinion
>>> based on the discussion happened in the past.  We should use
>>> application identifier 0 for Diameter common messages.
>>>
>>> On the other hand, the routing issue for established sessions with
>>> stateful agents needs to be resolved (this issue is different from
>>> Issue 4).  I'd suggest creating a separate issue on this, which
>>> probably needs explicit routing functionality like Issue 4.
>>>
>>>       
>> Based on Pasi's historical quotation, I think we can compromise on the
>> app id of 0 since it seems like such "interpretation" is already heavily
>> entrenched. Though I agree with Yoshi that we still need to fix the
>> routing issue as a side effect of this interpretation. In this way, we
>> can agree on something without endangering existing standards and move
>> forward with other issues. Would this proposal be sufficient for all
>> interested parties ?
>>
>> best regards,
>> victor
>>
>>     
>>> Yoshihiro Ohba
>>>
>>>
>>>
>>> On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT wrote:
>>>
>>>       
>>>> Tolga,
>>>>
>>>> I agree of course with the Victor's proposed approach on how
>>>>         
>> to proceed.
>>     
>>>> That said I would still comment on some of your statements below and
>>>> feed in some more arguments into this thread.
>>>>
>>>> Regards
>>>> Marco
>>>>
>>>>
>>>>
>>>>         
>>>>> I believe the point is whether it is RFC3588 or the RFCs you quoted
>>>>>
>>>>>           
>>>> needs >to
>>>>
>>>>         
>>>>> violate what is said about Application-ID in RFC3588 3.
>>>>>           
>> Diameter Header
>>     
>>>>> section.
>>>>>
>>>>>           
>>>> [MSt] I think you refer to this text below
>>>>
>>>> Application-ID
>>>>       Application-ID is four octets and is used to identify to which
>>>>       application the message is applicable for.  The
>>>>         
>> application can be
>>     
>>>>       an authentication application, an accounting application or a
>>>>       vendor specific application.  See Section 11.3 for the possible
>>>>       values that the application-id may use.
>>>>
>>>>       The application-id in the header MUST be the same as what is
>>>>       contained in any relevant AVPs contained in the message.
>>>>
>>>> [MSt] If you look in to section 11.3 you find Diameter Common Messages
>>>> with app id 0. Obviously the Diameter Common Messages are those defined
>>>> in the base protocol. The above text, simply means that both
>>>> Application-Id in the message header and the Auth-Application-Id AVP
>>>> have to be set to the same value that is 0 (zero) for common messages.
>>>> So I really don't think that all the existing RFCs violate the base
>>>> protocol since all of them are consistent, rather I think that some
>>>> implementation of RFC 3588 may not be compliant and I don't see why we
>>>> should change all the existing RFCs and application
>>>>         
>> implementations that
>>     
>>>> may be deployed out there (on top of clean base protocol) as opposed to
>>>> someone fixing their bogus RFC 3588 implementations.
>>>>
>>>>
>>>>         
>>>>> Another point is that considering existing few applications you
>>>>>
>>>>>           
>>>> mentioned >is
>>>>
>>>>         
>>>> [MSt] See my comment above.
>>>>
>>>>
>>>>

---

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Thu, 20 Jul 2006 17:55:51 +0200

----- Re-sending -----

Hi Tony,

I thought there was agreement now on this list for app id 0 for several reasons one being that those are common messages.

All your arguments have been discussed already.

Thank you
Marco

-----Original Message-----
From: STURA, Marco, VF-IT 
Sent: giovedì 20 luglio 2006 17.05
To: 'Tony Zhang'; Tolga Asveren; Victor Fajardo; Yoshihiro Ohba
Cc: [email-masked]; [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

Hi Tony,

I thought there was agreement now on this list for app id 0 for several reasons one being that those are common messages.

All your arguments has been discussed already.

Thank you
Marco

-----Original Message-----
From: Tony Zhang [mailto:[email-masked]] 
Sent: giovedì 20 luglio 2006 15.09
To: Tolga Asveren; Victor Fajardo; Yoshihiro Ohba
Cc: [email-masked]; [email-masked]; STURA, Marco, VF-IT
Subject: Re: [Dime] Summary of 3588bis Issues Status

HI All,
     I suggest ASR,ASA,RAR,RAA use specific application  not application 0. now if these command use application 0,it is likely  for address command dictionary,not for identifer application.
     also the application id use for routing,if any message use same,how to assure routing is correct.why should use application id for routing?also when one node support many applications,it is diffcult to address which module process the message.
     actual the base protocol should define,the application id should  how to use. 
     each application document should define which command use which application id,in my opinion is not so good.if i just add one new avp(maybe vendor avp),then should change the application Id,the rule is so complex.
     Base on this discuss,i think nobody think this is good choice,only donnot want change the code or exist RFC.but i am assure if have rfc3588-bis,we will change our code ,why not use this chance,do a better choice.
     rfc3588-bis likely one implement guideline,each appliation should follow it,then in future it is easy to extened application.

Thanks 
Tony

---

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Thu, 20 Jul 2006 17:04:52 +0200

Hi Tony,

Thank you
Marco

-----Original Message-----
From: Tony Zhang [mailto:[email-masked]] 
Sent: giovedì 20 luglio 2006 15.09
To: Tolga Asveren; Victor Fajardo; Yoshihiro Ohba
Cc: [email-masked]; [email-masked]; STURA, Marco, VF-IT
Subject: Re: [Dime] Summary of 3588bis Issues Status

HI All,

Thanks 
Tony

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 26 Jul 2006 18:29:48 -0700

[email-masked] <mailto:[email-masked]> supposedly scribbled:

> Tony,
> 
> During the initial work on Diameter, it was hoped that proxies would
> be a rare occurance.  

Given that Diameter came as a direct result of the work of the roamops WG to try & find a way to make Internet roaming secure & that Internet roaming is based on proxies, I find this statement fairly amazing.  Maybe we were working on different Diameters?

> We assumed all proxies will be stateless. 

>From RFC 3588:

6.2.1.  Processing received Answers

   A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an
   answer received against the list of pending requests.  The
   corresponding message should be removed from the list of pending
   requests.  It SHOULD ignore answers received that do not match a
   known Hop-by-Hop Identifier.

A "list of pending requests" qualifies as "state" in my mind, anyway.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

---

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Thu, 27 Jul 2006 10:04:21 +0200

Pasi Eronen wrote:

>In 3588bis we should clarify this, and probably introduce a new term(s)
>for the software components and their state (this would allow us to
>describe more easily that e.g. when a message referring to an existing
>session is processed, the session state lookup is done by Session-ID,
>not Application-ID+Session-ID).

I think that would be a good thing to clarify, I agree.

Regards
Marco

-----Original Message-----
From: Pasi Eronen [mailto:[email-masked]] 
Sent: giovedì 27 luglio 2006 9.39
To: 'ext Glen Zorn (gwz)'
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

Glen Zorn wrote:
> > I don't think that we should re-open this issue, as it was discussed
> > and decided long ago. 
> 
> I think that this was a fairly serious error, at least WRT the
> session-oriented (including accounting) messages.  If it's not an
> error, tell me this: an application generates an STR & sends it to
> the correct peer with app ID 0.  The Diameter Base terminates the
> session.  So what happens to the state being held by the
> _application_ peer?  Unless the Base protocol module keeps a map of
> session IDs to applications, it doesn't seem that it would know
> which application to notify of the session termination.

Once again: this depends on what is meant by an "application".  
Saying that "an application generates an STR & sends it" or "which
application to notify" makes any sense only if by application you mean
some kind of module or component in a Diameter server (or something
similar)

But at least my reading of RFC3588 (which some others agreed when
this issue was discussed the last time) was that an "application" in
Diameter means a set of specifications (documents). Thus, while you
can send a message defined _in_ an application, an application is not
a thing that sends or receives messages.

However, by now it's quite obvious that most implementors reading the
spec for the first time immediately (and quite naturally) assume the
"software component" interpretation... and that's why we keep having
this discussion every two years (when even the document authors 
might have forgotten why they wrote that :-)

In 3588bis we should clarify this, and probably introduce a new term(s)
for the software components and their state (this would allow us to
describe more easily that e.g. when a message referring to an existing
session is processed, the session state lookup is done by Session-ID,
not Application-ID+Session-ID).

Best regards,
Pasi

---

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Thu, 27 Jul 2006 18:03:43 +0200

>Tony:I donot think , not use app-id 0,it means should use Application->ID+Session-ID lookup session state

All you do with these base common messages is informing of or inferring session termination. A diameter session is identified solely by the session-id, not by Application-Id+Session-id. I strongly agree with Pasi here.

Regards
Marco

-----Original Message-----
From: Tony Zhang [mailto:[email-masked]] 
Sent: giovedì 27 luglio 2006 14.12
To: 'Pasi Eronen'; 'ext Glen Zorn (gwz)'
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

-----Original Message-----
From: Pasi Eronen [mailto:[email-masked]] 
Sent: Thursday, July 27, 2006 3:39 PM
To: 'ext Glen Zorn (gwz)'
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

Tony: so why this time not follow easy understand way.

Tony:I donot think , not use app-id 0,it means should use Application-ID+Session-ID lookup session state

Best regards,
Pasi

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 31 Jul 2006 08:15:20 -0700

Pasi Eronen <mailto:[email-masked]> supposedly scribbled:

> application to notify" makes any sense only if by application you
> mean some kind of module or component in a Diameter server (or
> something   
> similar)
> 

Interesting.  So why are application IDs part of the protocol?  Do we expect Diameter peers to go read the appropriate specification? 
 
> this discussion every two years (when even the document authors might
> have forgotten why they wrote that :-)    
> 
> In 3588bis we should clarify this, and probably introduce a new
> term(s) for the software components and their state (this would allow
> us to describe more easily that e.g. when a message referring to an
> existing session is processed, the session state lookup is done by
> Session-ID, not Application-ID+Session-ID).  

So, apparently the entire software system must be rewritten in order to support a new "application"?

Hope this helps,

~gwz