Subject: [Dime] Some more Suggestions in 3588-bis-06!!

From: "Arun Santhanam, TLS-Chennai" <[email-masked]>
Date: Mon, 10 Sep 2007 11:30:00 +0530

Hi victor,
         The following are some of my suggestion w.r.t to the draft
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-06.txt

 Suggestion 3)     Redirect-Host can be added to the ACA message
inclusion of this will really help the accounting messages to flow
through redirect agents. Since the relay and redirect are Protocol
Transparent they will be supporting Accounting and all other Diameter
Applications. 
(Let me know your suggestion)

 Suggestion 4)    Section "10.2.  Accounting AVP Table" I find that
Error-Reporting-Host is having "0+" for ACA message .I think It should
be "0-1" (Correct me if I'm wrong).

Thx
-Arun

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 6:48 AM
To: Arun Santhanam, TLS-Chennai
Cc: [email-masked]
Subject: Re: Reg. Failed Avp in ACA Msg.

Hi Arun,

Sorry for the late reply.

>                      I think we can include Failed-Avp for ACA
section, just as we have for rest of the command code. This will help to
report errors of type 
>                      DAMETER_INVALID_AVP_VALUE, DIAMETER_MISSING_AVP
.....& so on

We should add optional Error-Message and Failed-AVP to ACA.

>  
>           Suggestion 2)
>                     Section 6.9. Acct-Application-Id AVP definition
says that the Avp must be present in all the Accounting Messages 
>           Then we can change the present grammar from
[Acct-Application-Id] to {Acct-Application-Id} for ACR and ACA command
code.

I'm guessing that this AVP is optional because it is present either as 
part of the Vendor-Specific-Application-Id or a 'standalone' AVP. And 
only one of them can be present at a time. (See 9.7.1).

regards,
victor

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

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

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 10 Sep 2007 08:30:46 -0400

Hi Arun,

> (Let me know your suggestion)

I don't think we need to update ACA for this. Redirected answers follow 
the ABNF in 7.2. Secondly, sec 6.1.8 already describes when how to do 
redirection.

> be "0-1" (Correct me if I'm wrong).

Ok.

-- victor

---

From: "Arun Santhanam, TLS-Chennai" <[email-masked]>
Date: Mon, 10 Sep 2007 19:25:56 +0530

Hi Victor,
         I agree with your point regarding the processing of the
Redirected Answer Message but as per the section 

" 6.1.8.  Redirecting requests

   When a redirect agent receives a request whose routing entry is set
   to REDIRECT, it MUST reply with an answer message with the 'E' bit
   set, while maintaining the Hop-by-Hop Identifier in the header, and
   include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION.  Each of
   the servers associated with the routing entry are added in separate
   Redirect-Host AVP."

When the Answer "E" bit is set then it will not confirm to the normal
answer message instead it will confirm to "E" bit Grammar

"7.2.  Error Bit

   The 'E' (Error Bit) in the Diameter header is set when the request
   caused a protocol-related error (see Section 7.1.3).  A message with
   the 'E' bit MUST NOT be sent as a response to an answer message.
   Note that a message with the 'E' bit set is still subjected to the
   processing rules defined in Section 6.2.  When set, the answer
   message will not conform to the ABNF specification for the command,
   and will instead conform to the following ABNF:"

If this is the case then we need to include the redirect host in "E" bit
response message which is currently missing in "E" bit response message
                  * [ Redirect-Host ]
                    [ Redirect-Host-Usage ]
                    [ Redirect-Max-Cache-Time ] 

Existing Grammar for "E" bit response Message

    <answer-message> ::= < Diameter Header: code, ERR [PXY] >
                        0*1< Session-Id >
                           { Origin-Host }
                           { Origin-Realm }
                           { Result-Code }
                           [ Origin-State-Id ]
                           [ Error-Message ]
                           [ Error-Reporting-Host ]
                           [ Failed-AVP ]
                         * [ Proxy-Info ]
                         * [ AVP ]

Please let me know you suggestion on this issue.

If the above statement is correct then we don't require having
Redirect-Host Avp's in STA RAA ASA.

Please let me know your suggestion.

Thx
-Arun

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 6:01 PM
To: Arun Santhanam, TLS-Chennai
Cc: [email-masked]
Subject: Re: Some more Suggestions in 3588-bis-06!!

Hi Arun,

Ok.

-- victor

DISCLAIMER:

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 10 Sep 2007 10:08:40 -0400

Hi Arun,

>     <answer-message> ::= < Diameter Header: code, ERR [PXY] >

Sure.

> Redirect-Host Avp's in STA RAA ASA.

I was looking at this a while ago and I was'nt exactly sure why these 
AVPs where there in the first place. Sec 6.1.8 and 7.2 should be enough. 
Unless there are some semantics defined, I think these AVPs should be 
removed from these messages as well. I don't see any backward 
compatibility issue if these AVPs are removed.

regards,
victor