Subject: RE: Issue 20 (offending AVP inside a Grouped AVP) was:RE:[Dime]Summary of 3588bis Issues Status

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 20 Jul 2006 17:01:45 +0200

The Failed-AVP AVP is used to provide information about missing/offending AVPs. Nothing else. As it is described
What would be the added-value to distinguish problems due to stand-alone AVPs from (sub)AVPs of Grouped AVP?

All the AVPs required to support the base diameter and specific applications are published in a library.
The ABNF description of each supported command is given in base diameter and specific diameter applications specs.
What is missing to handle error report?

About the given examples:

For DIAMETER_INVALID_AVP_VALUE, the Failed-AVP AVP will carry a copy of the offending AVP (stand-alone AVP or (sub)AVP).
It is here possible to check in the library the value allowed for this AVP.

For DIAMETER_MISSING_AVP, the Failed-AVP AVP will carry an example of the missing AVP (stand-alone AVP or (sub) AVP), whit the expected AVP code.
It is here possible to refer to the command ABNF description to discover the problem (e.g. wrong implementation of the command).  

BR,

Lionel

-----Message d'origine-----
De : German Blanco (MI/EEM) [mailto:[email-masked]] 
Envoyé : jeudi 20 juillet 2006 13:01
À : [email-masked]; Victor Fajardo
Cc : [email-masked]
Objet : RE: Issue 20 (offending AVP inside a Grouped AVP) was:RE:[Dime]Summary of 3588bis Issues Status

Hello,

it is not possible.

In the same way, if you report the error with the top level grouped AVP and the DIAMETER_INVALID_AVP_VALUE, it is not possible to know what happened exactly inside the grouped AVP.

So it is a trade off between the two ways to report the error, unless we add something in the Failed-AVP to give more information.  The proposed methods seem to "needlessly extend the length of the Failed-AVP".  To me this sounds a bit strange, given that reporting the error with the grouped AVP and DIAMETER_INVALID_AVP_VALUE means sending the entire grouped AVP.

German.

-----Original Message-----
From: Rajith R [mailto:[email-masked]]
Sent: jueves, 20 de julio de 2006 12:24
To: 'Victor Fajardo'; German Blanco (MI/EEM)
Cc: [email-masked]
Subject: RE: Issue 20 (offending AVP inside a Grouped AVP) was:RE:
[Dime]Summary of 3588bis Issues Status

Hi
	For unsupported AVP, adding the offending (sub) AVP contents to the Failed AVP is ok. A first-occurrence content match will tell you where the error is.

	However for missing AVP, if you put an example of the (sub) AVP in Failed AVP, how would you know/indicate whether it is missing in the command or in a particular group AVP?

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!

>-----Original Message-----
>From: Victor Fajardo [mailto:[email-masked]]
>Sent: Wednesday, July 19, 2006 7:55 PM
>To: German Blanco (MI/EEM)
>Cc: [email-masked]
>Subject: Re: Issue 20 (offending AVP inside a Grouped AVP) was:RE:
>[Dime]Summary of 3588bis Issues Status
>
>Hi German,
>
>Comments inline:
>
>> Victor,
>>
>> Thanks for the summary!
>>
>> When you say:
>>
>>> Issue 20     :  Determining an offending/invalid AVP contained
within
>>>                 the group AVP
>>>                 Proposals: Do nothing. The AVP code should be
enough.
>>>                            Existing proposals may needlessly extend
>>>                            the length of the Failed-AVP.
>>>
>>
>> Is the proposal to indicate in the answer only the code of the 
>> missing AVP inside the Grouped AVP?
>>
>> If that is the case, I would suggest this text additions for RFC 
>> 3558bis (between ">>"s and "<<"s):
>> "
>>    DIAMETER_MISSING_AVP               5005
>>       The request did not contain an AVP that is required by the
Command
>>       Code >>or Grouped AVP <<definition.  If this value is sent in
the
>>       Result-Code AVP, a Failed-AVP AVP SHOULD be included in the 
>> message.
>>       The Failed-AVP AVP MUST contain an example of the missing AVP 
>> complete
>>       with the Vendor-Id if applicable.>>  If the AVP is missing in a

>> Grouped
>>       AVP, only the missing AVP and not the Grouped-AVP will be 
>> included in
>>       the Failed-AVP. <<The value field of the missing AVP should be 
>> of correct
>>       minimum length and contain zeroes.
>> "
>> "
>>    DIAMETER_AVP_NOT_ALLOWED           5008
>>       A message was received with an AVP that MUST NOT be present.
The
>>       Failed-AVP AVP MUST be included and contain a copy of the
>>       offending AVP.>>  If the AVP is present inside a Grouped
>>       AVP, only the offending AVP and not the Grouped-AVP will be 
>> included
>>       in the Failed-AVP. <<
>> "
>>
>> "Do nothing" doesn't seem a good idea to me.  I would prefer that 
>> this is clarified, whatever the conclusion is.  The long list of 
>> error codes will not make sense, if we end up not knowing what
happened.
>>
>
>I don't have any opinion on this topic but I hope some folks will 
>comment on your proposal.
>
>regards,
>victor
>
>> Regards,
>> German.
>>
>> -----Original Message-----
>> From: Victor Fajardo [mailto:[email-masked]]
>> Sent: viernes, 14 de julio de 2006 19:46
>> To: [email-masked]
>> Subject: [Dime] Summary of 3588bis Issues Status
>>
>> Folks,
>>
>> The is a summary of the 3588bis issues discussion during DIME WG 
>> meeting in IETF66. If you have comments on any of the existing issues

>> pls don't hesitate to post it on the DIME list so we can facilitate 
>> quicker resolution or at least better understanding of the problem.
>> We also need some proposals on the open issues if you believe they
are truly issues.
>> Note that the assigned issue numbers are based on the current tracker

>> which is for historical reasons the diameter-interop tracker 
>> (http://www.tschofenig.priv.at:8080/diameter-interop).
>>
>>
>> Closed Issues:
>> -------------
>>
>> Issue 6      :  TLS version issue
>>                 Comments: interop related problem only. Does not 
>> affect the
>>                           base spec
>>
>> Issue 7      :  Textual IP address qualify as FQDN
>>                 Comments: Consensus that FQDN is defined as "internet

>> name"
>>                           only
>>
>> Issue 11     :  Confusion about use of Proxy-Info AVP for Relay
>>                 Comments: Clarified in Sec 6.2 with the text
>>
>>                 "Any Proxy-Info AVPs in the request MUST be added to
the
>>                  answer message, in the same order they were present
in
>>                  the request."
>>
>> Open Issues with some consensus on proposals:
>> ---------------------------------------------
>>
>> Notes: These issues have some consensus either during the IETF66
>>        meeting and/or in the DIME mailing list.
>>
>> Issue 2 & 5  :  App Ids used by common diameter messages
>>                 Proposals: Use the application id of the current
>>                            application
>>
>> Issue 3 & 16 :  CER/CEA exchange in the open state
>>                 Proposals: Need more consensus on current proposals
>>                            posted in issue 16
>>
>> Issue 10     :  Unclear semantics on multiple vendor-id avp in VSA
avp
>>                 Proposals: The Vendor-Id ABNF should one and only one
>>                            instance, i.e.
>>
>>    <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
>>                                         < Vendor-Id >
>>                                      0*1{ Auth-Application-Id }
>>                                      0*1{ Acct-Application-Id }
>>
>> Issue 20     :  Determining an offending/invalid AVP contained within
>>                 the group AVP
>>                 Proposals: Do nothing. The AVP code should be enough.
>>                            Existing proposals may needlessly extend
>>                            the length of the Failed-AVP.
>>
>> Issue 17     :  Removal of trailing [*fixed] avp in Sec 3.2
>>                 Proposals: Change diameter-message definition in Sec
>> 3.2
>> to:
>>
>>               diameter-message=header[*fixed][*required][*optional]
>>
>> Open Issues with no consensus on proposals:
>> ------------------------------------------
>>
>> Issue 21     :  URI schemes for AAA
>>                 Proposals: draft-garcia-dime-aaa-uri-00.txt
>>
>> Issue 4      :  Proxy agent stay in the path of the request message
of
>>                 a session
>>                 Proposals: draft-tsou-dime-routing-ext-00.txt
>>
>> Open Issues that needs proposals:
>> --------------------------------
>>
>> Notes: These issues did not receive any comments during IETF66 and
>>        have no pending proposals.
>>
>> Issue 1      :  Advertising relay application id (0xffffffff) in
>>                 auth-application-id or acct-application-id
>>
>> Issue 15     :  Duplicate detection requires server side storage of
>>                 e2e id and origin-host avp
>>
>> Issue 13     :  Clarify usage of application id avp's and how they
>>                 relate to the app-id in the header
>>
>> Issue 9 & 19 :  Error codes defined in wrong category
>>
>> Issue 8      :  Setting error flag (e-bit) during CER/CEA exchange
>>
>> Issue 12     :  Differing concepts and/or usage of Diameter Identity
>>                 (FQDN + port or FQDN only)
>>
>> Issue 14     :  Explicit text on which error category should have
>>                 error flag (e-bit) set
>>
>> Issue 18     :  Clarify reconnect behavior of peer based on value of
>>                 Disconnect-Cause AVP
>>
>> Open issues falling into the "New Features" category:
>> ----------------------------------------------------
>>
>> Note: These features should use the extension procedures defined in 
>> 3588.
>>       No comments received in IETF66 meeting.
>>
>> Issue 23     :  Predictive loop detection
>>                 Comments: Optimzation techiniques in detecting loops
>>                           at the succeeding hops
>>
>> Issue 22     :  Fetch data request and location update request.
>>                 Comments: Proposal to include LUR messages into
>>                           base since its reusable in different
>>                           applications
>>
>> If you believe there are some in-accurate info below, pls let us
know.
>>
>> best regards,
>> victor
>>
>> _______________________________________________
>> 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

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