Subject: [Dime] Summary of 3588bis Issues Status

From: Victor Fajardo <[email-masked]>
Date: Fri, 14 Jul 2006 13:46:29 -0400

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 17 Jul 2006 17:00:47 -0400

Hi Victor,

Thanks a lot for that very useful update.

IMHO, a few of the items listed below have a higher importance than the
other ones:

1) AppId to be used by common diameter messages
2) Grouping of error codes

Especially 1) seem to be a real interop-killer. I hope all people which have
any opinion on this issue would post their ideas so that we can reach a
conclusion ASAP.

     Thanks,
     Tolga

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Friday, July 14, 2006 1:46 PM
> To: [email-masked]
> Subject: [Dime] Summary of 3588bis Issues Status
>
>
> Folks,
>

---

From: [email-masked]
Date: Mon, 17 Jul 2006 22:57:07 -0500

Hi Victor,
 I agree with Tolga. The item (1) is really an interop issue and needs to be 
added to the list.

Thanks
Prasad.

---

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Tue, 18 Jul 2006 12:49:19 +0800

Hi,

My comment on (1) is that all messages which are terminated/handled in
the base FSM (RFC3588/3539) should carry app-id 0 and any other message
should carry the respective other app-ids.

Regards,
Vishnu.

Motorola India Electronics Pvt Ltd
+91 9844178052
[*] Motorola Internal Use Only

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Tuesday, July 18, 2006 9:27 AM
To: Tolga Asveren
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

Hi Victor,
 I agree with Tolga. The item (1) is really an interop issue and needs
to be 
added to the list.

Thanks
Prasad.

Quoting Tolga Asveren <[email-masked]>:

> IMHO, a few of the items listed below have a higher importance than 
> the other ones:
> 
> Especially 1) seem to be a real interop-killer. I hope all people 
> which have any opinion on this issue would post their ideas so that we

> can reach a conclusion ASAP.
> 
>      Thanks,
>      Tolga
> 
> > 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 
> >                 Proposals: Change diameter-message definition in Sec

> > 3.2 to:

---

From: Rajith R <[email-masked]>
Date: Tue, 18 Jul 2006 10:32:07 +0530

By base FSM do you mean only the connection management FSM (which handles
CE/DW/DP) or the Auth./Accounting state machines defined in RFC 3588 as
well?

Regards

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!
>From: Ram O V Vishnu-A14676 [mailto:[email-masked]]
>Sent: Tuesday, July 18, 2006 10:19 AM
>To: [email-masked]; Tolga Asveren
>Cc: [email-masked]
>> > Issue 20     :  Determining an offending/invalid AVP contained

>within

---

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Tue, 18 Jul 2006 13:43:04 +0800

Rajith,

I meant section 5.6 of RFC 3588.

I don't think the auth fsm in section 8.1 can handle messages with appid
0 because it talks about "Service-specific authorization" messages.

I think the section 8.2 should handle messages with appid 3 (as per
section 2.4). Ofcourse it could be something else too (like a 3GPP
accounting appid), but not 0.

Regards,
Vishnu.

-----Original Message-----
From: Rajith R [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2006 10:32 AM
To: Ram O V Vishnu-A14676
Cc: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

By base FSM do you mean only the connection management FSM (which
handles
CE/DW/DP) or the Auth./Accounting state machines defined in RFC 3588 as
well?

Regards

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!

>to be added to the list.

>> >                 "Any Proxy-Info AVPs in the request MUST be added 
>> > to
>the
>> >                  answer message, in the same order they were 
>> > present
>in
>> >                  the request."
>> >

---

From: Rajith R <[email-masked]>
Date: Tue, 18 Jul 2006 11:56:12 +0530

Hi
	I also agree that app Id 0 should be used only for CE, DW & DP
commands.

	However, I could not understand why we have the app Id field in the
DIAMETER header? 

	RFC 3588 specifies that all accounting, auth or experimental
commands MUST have Acct.,Auth. or Vendor Sp. App Id respectively. 
	So, I assume, the app Id field in the header might be for nodes to
quickly identify whether the msg is for the connection management FSM (app
Id = 0) or for some session management logic (like NASREQ, Base-Accounting
or Vendor specific). But this could be achieved by checking the command code
as well.

Regards

Rajith

>Sent: Tuesday, July 18, 2006 11:13 AM
>To: [email-masked]
>Cc: [email-masked]

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 18 Jul 2006 08:14:46 -0400

Hi,
>  I agree with Tolga. The item (1) is really an interop issue and needs to be 
It is on the list as issue #2&5.
victor

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 18 Jul 2006 08:45:09 -0400

Folks,

Just for the clarity. This topic is issue #2&5 and refers to what app id 
should "application session level" messages defined in the base protocol 
(STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the 
meeting and more likely in this list as well is that it MUST carry the 
app id of the application using it. Messages dealing with peer 
connectivity (CER/CEA, DWR/DWA, DPR/DPA) will carry an app id of 0. If 
there are no technical objections to this solution then we can close 
this issue.

> or Vendor specific). But this could be achieved by checking the command code
The app id in the header make's it easier to route messages rather than 
searching for the app id avp's in the message. Relay's does not really 
care about command codes. A more important issue that we should discuss 
is issue#13 (Clarify usage of application id avp's and how they relate 
to the app-id in the header) and consequently issue #1 (Advertising 
relay application id (0xffffffff) in auth-application-id or 
acct-application-id). Pls send your comments.

best regards,
victor

>>>>> 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.
>>>>>
>>>>>                 Proposals: Do nothing. The AVP code should be
>>>>>           
>>> enough.
>>>       
>>>>> Issue 4      :  Proxy agent stay in the path of the request message
>>>>>           
>>> of
>>>       
>>>>>                 a session
>>>>> Issue 12     :  Differing concepts and/or usage of Diameter
>>>>>           
>> Identity
>>     
>>>>> Issue 18     :  Clarify reconnect behavior of peer based on value
>>>>>           
>> of
>>     
>>>>>                 Disconnect-Cause AVP
>>>>>
>>>>> Note: These features should use the extension procedures defined in
>>>>>           
>>> 3588.
>>>       
>>>>>                 Comments: Optimzation techiniques in detecting
>>>>>           
>> loops
>>     
>>>>>                           at the succeeding hops
>>>>>

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 18 Jul 2006 09:47:59 -0400

Hi Victor,

I agree with this.

   Thanks,
   Tolga

> Sent: Tuesday, July 18, 2006 8:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dime] Summary of 3588bis Issues Status
>
>
> Folks,
>

---

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Tue, 18 Jul 2006 22:27:12 +0800

Hi All,

I agree with this too. I guess we can close 2&5.

Also, I have added comments to issue 13 and 1.

Regards,
Vishnu.

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2006 7:18 PM
To: [email-masked]
Subject: RE: [Dime] Summary of 3588bis Issues Status

Hi Victor,

I agree with this.

   Thanks,
   Tolga

> Just for the clarity. This topic is issue #2&5 and refers to what app 
> id should "application session level" messages defined in the base 
> protocol (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current 
> consensus in the meeting and more likely in this list as well is that 
> it MUST carry the app id of the application using it. Messages dealing

> with peer connectivity (CER/CEA, DWR/DWA, DPR/DPA) will carry an app 
> id of 0. If there are no technical objections to this solution then we

> can close this issue.
> The app id in the header make's it easier to route messages rather 
> than searching for the app id avp's in the message. Relay's does not 
> really care about command codes. A more important issue that we should

> discuss is issue#13 (Clarify usage of application id avp's and how 
> they relate to the app-id in the header) and consequently issue #1 
> (Advertising relay application id (0xffffffff) in auth-application-id 
> or acct-application-id). Pls send your comments.
>
> best regards,
> victor
>
>
> > Regards
> >
> > Rajith
> >
> > which is intended only for the person or entity whose address is 
> (including,

> >> CE/DW/DP) or the Auth./Accounting state machines defined in RFC 
> >> 3588 as well?
> >>
> >>
> >> Regards
> >>
> >> Rajith
> >>
> >> listed above. Any use of the information contained herein in any 
> >> way (including, but not limited to, total or partial disclosure, 
> >> reproduction, or
> >>> My comment on (1) is that all messages which are 
> >>> terminated/handled in the base FSM (RFC3588/3539) should carry 
> >>> app-id 0 and any
> other message
> >>>
> >>> I agree with Tolga. The item (1) is really an interop issue and 
> >>> needs to be added to the list.
> >>>
> >>> Thanks
> >>> Prasad.
> >>>
> >>>> IMHO, a few of the items listed below have a higher importance 
> >>>> than the other ones:
> >>>>

> >>>>> 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

> >>>>>                 Comments: interop related problem only. Does not

> >>>>> affect the
> >>>>>                 "Any Proxy-Info AVPs in the request MUST be 
> >>>>> added to
> >>>>>
> >>> the
> >>>
> >>>>>                 Proposals: Change diameter-message definition in

> >>>>> Sec
> >>>>> Note: These features should use the extension procedures defined

> >>>>> If you believe there are some in-accurate info below, pls let us

> >>>>> know.
> >>>>> [email-masked] https://www1.ietf.org/mailman/listinfo/dime
> >>>>>
> >>>> [email-masked] https://www1.ietf.org/mailman/listinfo/dime
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>

---

From: "German Blanco \(MI/EEM\)" <[email-masked]>
Date: Wed, 19 Jul 2006 13:49:00 +0200

Victor, 

Thanks for the summary!

>                            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,

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 17     :  Removal of trailing [*fixed] avp in Sec 3.2
                Proposals: Change diameter-message definition in Sec 3.2
to:

best regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 19 Jul 2006 10:24:42 -0400

Hi German,

> 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

---

From: Rajith R <[email-masked]>
Date: Thu, 20 Jul 2006 15:54:07 +0530

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

>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:
>>

---

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

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:

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

within
enough.
>> 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):
>> "

>> 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
>> "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.
>> 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.

avp
>> 3.2
of
know.

---

From: Tony Zhang <[email-masked]>
Date: Fri, 21 Jul 2006 12:16:54 +0800

HI all:
   i give one Issue for Failed AVP also,for invalid AVP length,it is not easy implement in Failed avp should give the error avp copy back.
   consider below situation :
 (1) the AVP length more than message Length,
(2)the AVP length less than AVP head length,

i suggest only copy the AVP head is enough.

Thanks!
Tony

one problem is
----- Original Message ----- 
From: "German Blanco (MI/EEM)" <[email-masked]>
To: "Victor Fajardo" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 19, 2006 7:49 PM
Subject: 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:
-------------

                the group AVP

best regards,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 21 Jul 2006 07:58:19 -0400

Tony,

I also think so.

   Thanks,
   Tolga

> From: Tony Zhang [mailto:[email-masked]]
> Sent: Friday, July 21, 2006 12:17 AM
> To: German Blanco (MI/EEM); Victor Fajardo; [email-masked]
> [Dime]Summaryof 3588bis Issues Status
> 
> 
> HI all:
>    i give one Issue for Failed AVP also,for invalid AVP length,it 
> is not easy implement in Failed avp should give the error avp copy back.

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 21 Jul 2006 08:29:48 -0400

I've created issue #24 for this.
BR, 
victor