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

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

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

> Hi all,
> 
> Basically, Pasi is correct here.   The specs say to use app id of
> zero. 
> The
> consensus when standardizing Diameter Base and RFC 4005, 4072, etc.
> is that these messages use app id of 0. 
> 
> 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.

> 
> John
> 
> 
>> -----Original Message-----
>> From: ext [email-masked] [mailto:[email-masked]]
>> Sent: 19 July, 2006 05:39
>> To: [email-masked]; [email-masked]
>> 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
>> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

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

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

---

From: "Pasi Eronen" <[email-masked]>
Date: Thu, 27 Jul 2006 10:38:45 +0300

Glen Zorn wrote:
> 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: Tony Zhang <[email-masked]>
Date: Thu, 27 Jul 2006 19:55:58 +0800

Hi ALL:
   I agree with Glen.  Application id is also use for routing, we cannot requirement the stateless agent will keep the session ID. if Application Id use just for a set of documents, why accounting request not use 0(it define in RFC3588).

Thanks!
Regards
Tony

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Thursday, July 27, 2006 9:04 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

Hope this helps,

~gwz

---

From: Tony Zhang <[email-masked]>
Date: Thu, 27 Jul 2006 20:12:22 +0800

-----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