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

["German Blanco \(MI/EEM\)" <german.blanco at ericsson.com>]

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:vfajardo at tari.toshiba.com] 
Sent: viernes, 14 de julio de 2006 19:46
To: dime at ietf.org
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
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime