Subject: [Dime] RE: Issue 20 (offending AVP inside a Grouped AVP)

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Wed, 19 Jul 2006 17:58:00 +0200

Hi all,

I don't see what is the problem with Grouped AVP and Failed-AVP AVP.
A Grouped AVP is just a logical set of individual AVPs. The Failed-AVP AVP will contain information about missing/offending AVPs, whatever the AVP location in a command, (in a Grouped AVP or not).
Therefore the existing text on the Failed-AVP AVP definition and its use seems to be clear enough. Execpet if I missed something...

BR,

Lionel

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

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.

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

---

From: "German Blanco \(MI/EEM\)" <[email-masked]>
Date: Thu, 20 Jul 2006 09:17:31 +0200

Hi Lionel,

I also like that way of working better, but it is probably not that clear when there were several people in this list giving the opinion that the Failed-AVP should contain the grouped AVP ("top level AVP") reporting an invalid value.
It is in a thread with the subject "[Dime] Invalid AVP within a Grouped AVP".

Cheers,

German.

-----Original Message-----
From: MORAND Lionel RD-CORE-ISS [mailto:[email-masked]] 
Sent: miércoles, 19 de julio de 2006 17:58
To: German Blanco (MI/EEM); Victor Fajardo; [email-masked]
Subject: RE: Issue 20 (offending AVP inside a Grouped AVP)

Hi all,

BR,

Lionel

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

Victor, 

Thanks for the summary!

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,

Closed Issues:
-------------

best regards,
victor