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

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

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

[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
>not really enough. There are also diameter base stack implementations,
>which
>conform to RFC3588 and provide generic capability for any type of
>application.

[MSt] See my comment above.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Jul 2006 11:54:58 -0400

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.

Yoshihiro Ohba

---

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

Hi,

> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Jul 2006 13:00:50 -0400

Hi Victor,

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

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)

    Thanks,
    Tolga

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 1:00 PM
> To: Yoshihiro Ohba
> Cc: STURA, Marco, VF-IT; Tolga Asveren; [email-masked];
> [email-masked]
> Subject: Re: [Dime] Summary of 3588bis Issues Status
>
>
> Hi,
>
> Comments inline:
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 19 Jul 2006 13:57:05 -0400

Hi Tolga,
> issues in the future with people which did not follow this discussion.

I agree :).

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

> context of strict-routing draft review)

I agree.

BR,
victor

>>>> I agree of course with the Victor's proposed approach on how
>>>>         
>> to proceed.
>>     
>>>>> violate what is said about Application-ID in RFC3588 3.
>>>>>           
>> Diameter Header
>>     
>>>>> section.
>>>>>
>>>>>           
>>>>       application the message is applicable for.  The
>>>>         
>> application can be
>>     
>>>> should change all the existing RFCs and application
>>>>         
>> implementations that
>>

---

From: Rajith R <[email-masked]>
Date: Thu, 20 Jul 2006 15:03:57 +0530

Hi
	When you say we should use app Id 0 for Diameter common messages
(say ASR/ASA/RAR/RAA etc.), it is in the context of NASREQ application (RFC
4005), right?
Say, another application, like Gq in IMS, use these messages (i.e. same
command code, may add app. Sp. AVPs), it is not mandatory to use app id 0,
right?

Rajith
****************************************************************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

>Sent: Wednesday, July 19, 2006 10:30 PM
>To: Yoshihiro Ohba
>Cc: [email-masked]; [email-masked]; STURA, Marco, VF-IT

---

From: Tony Zhang <[email-masked]>
Date: Thu, 20 Jul 2006 21:09:02 +0800

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