[Dime] Summary of 3588bis Issues Status

[Victor Fajardo <vfajardo at tari.toshiba.com>]

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