From dime-bounces@ietf.org Sat Jun 02 05:45:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQAk-00011d-9S; Sat, 02 Jun 2007 05:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuQAi-00011P-QD for dime@ietf.org; Sat, 02 Jun 2007 05:45:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuQAh-00055k-9J for dime@ietf.org; Sat, 02 Jun 2007 05:45:20 -0400 Received: (qmail invoked by alias); 02 Jun 2007 09:45:18 -0000 Received: from p54984595.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.69.149] by mail.gmx.net (mp028) with SMTP; 02 Jun 2007 11:45:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19rNAQVZXxrNLoA6+dfgZ1r2IkRvB/vepjGwwo3Yd obJhyQXZwRFc9x Message-ID: <46613C2D.5050108@gmx.net> Date: Sat, 02 Jun 2007 11:45:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [Dime] DIME WG Status Update (June 2007) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1072789781==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1072789781== Content-Type: multipart/alternative; boundary="------------000506040300080700090802" This is a multi-part message in MIME format. --------------000506040300080700090802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, here is a short status update for our work. This write-up can also be found here: http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate Diameter QoS Dong Sun is working on an strawman proposal for the integration of http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-00.txt and http://tools.ietf.org/wg/dime/draft-sun-dime-diameter-resource-control-requirements-01.txt draft-korhonen-dime-qos-parameters-00.txt and draft-korhonen-dime-qos-attributes-00.txt will become working group items. The updated draft will consider the alignment with the ongoing filter rule work in RADEXT. Diameter Mobile IPv6 A new version of the "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" was submitted that addresses the previously open issues. The new draft version is here: http://tools.ietf.org/html/draft-ietf-dime-mip6-integrated-04 An update for the "Diameter Mobile IPv6: HA <-> HAAA Support" document is in progress. It will address the open issues mentioned in the status update of last month. Diameter Base Protocol Update A new draft update is in progress. There are, however, a few tough issue left for discussion. Victor will send an update to the list. Diameter API A new version of the Diameter API was submitted that contain minor editorial fixes and template updates. A PROTO writeup is in progress and the document will be submitted to the IESG soon. TISPAN Liaison ACTION ITEM: Hannes to respond to liaison request ITU-T Liaison ACTION ITEM: Dave to respond to liaison request Charter Update ACTION ITEM: Hannes to check pending charter update. Diameter Application Design Guidelines We need reviews from the DIME WG for the document before we send it to other SDOs for review. Please volunteer! Miscellaneous Glen re-submitted his two MIB documents: http://tools.ietf.org/wg/dime/draft-zorn-dime-diameter-cc-appl-mib-02.txt http://tools.ietf.org/wg/dime/draft-zorn-dime-diameter-base-protocol-mib-02.txt Ciao Hannes --------------000506040300080700090802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

here is a short status update for our work.

This write-up can also be found here:
http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate

Diameter QoS

Dong Sun is working on an strawman proposal for the integration of http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-00.txt and http://tools.ietf.org/wg/dime/draft-sun-dime-diameter-resource-control-requirements-01.txt

draft-korhonen-dime-qos-parameters-00.txt and draft-korhonen-dime-qos-attributes-00.txt will become working group items. The updated draft will consider the alignment with the ongoing filter rule work in RADEXT.

Diameter Mobile IPv6

A new version of the "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" was submitted that addresses the previously open issues. The new draft version is here: http://tools.ietf.org/html/draft-ietf-dime-mip6-integrated-04

An update for the "Diameter Mobile IPv6: HA <-> HAAA Support" document is in progress. It will address the open issues mentioned in the status update of last month.

Diameter Base Protocol Update

A new draft update is in progress. There are, however, a few tough issue left for discussion. Victor will send an update to the list.

Diameter API

A new version of the Diameter API was submitted that contain minor editorial fixes and template updates. A PROTO writeup is in progress and the document will be submitted to the IESG soon.

TISPAN Liaison

ACTION ITEM: Hannes to respond to liaison request

ITU-T Liaison

ACTION ITEM: Dave to respond to liaison request

Charter Update

ACTION ITEM: Hannes to check pending charter update.

Diameter Application Design Guidelines

We need reviews from the DIME WG for the document before we send it to other SDOs for review. Please volunteer!

Miscellaneous

Glen re-submitted his two MIB documents: http://tools.ietf.org/wg/dime/draft-zorn-dime-diameter-cc-appl-mib-02.txt http://tools.ietf.org/wg/dime/draft-zorn-dime-diameter-base-protocol-mib-02.txt



Ciao
Hannes

--------------000506040300080700090802-- --===============1072789781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1072789781==-- From dime-bounces@ietf.org Tue Jun 05 03:06:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT7I-0003Vj-D2; Tue, 05 Jun 2007 03:06:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT7H-0003Va-8L for dime@ietf.org; Tue, 05 Jun 2007 03:06:07 -0400 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvT7F-0003J9-H9 for dime@ietf.org; Tue, 05 Jun 2007 03:06:07 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 776C737C05E; Tue, 5 Jun 2007 12:32:10 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTPid 37E4B37C04B; Tue, 5 Jun 2007 12:32:10 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 12:36:01 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Jun 2007 12:35:30 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AAF95@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg. the Re-Definition of the Command code Thread-Index: AcenPlYuyiZ9pWipRGCWCYghK+0S6QAASs4g From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 05 Jun 2007 07:06:01.0240 (UTC) FILETIME=[F966F180:01C7A73F] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-10.1761 TC:1F TRN:67 TV:3.6.1039(15218.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.6 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: Subject: [Dime] Reg. the Re-Definition of the Command code X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1999323012==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1999323012== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A73F.EF65B9F3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A73F.EF65B9F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I went though the " 3GPP TS 29.209 V6.6.0 (2006-09)" for Gq interface I'm surprised to see that the Base Command code=20 "RAR" and "ASR" has been redefined by the Gq Team. The following is the example of the Redefinition of the ASR Command code By the 3GPP Team. =20 =20 { Base Diameter Definition RFC 3588} =20 ::=3D < Diameter Header: 274, REQ, PXY > =20 < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } [ User-Name ] [ Origin-State-Id ] =20 {3GPP TS 29.209 V6.6.0 (2006-09)} =20 ::=3D < Diameter Header: 274, REQ, PXY >=20 < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Abort-Cause } {Why this AVP is Mandated Here ?} [ Origin-State-Id ] *[ Proxy-Info ] *[ Route-Record ] [ AVP ] Is it correct for the Application to redefine the Base Command code? Thx -Arun DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7A73F.EF65B9F3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Victor,

         &n= bsp;  I went though the “ 3GPP TS 29.209= V6.6.0 (2006-09)” for Gq interface I’m surprised to see that the Base Command code

“RAR” and= “ASR” has been redefined by the Gq Team. The following is the example of the= Redefinition of the ASR Command code

By the 3GPP Team.     

 

       =
 { Base Diameter=
 Definition RFC 3588}
 
     <ASR>  ::=3D <=
 Diameter Header: 274, REQ, PXY > =
             &n=
bsp;    
         =
;        < Session-Id=
 >
         =
;        { Origin-Host=
 }
         =
;        { Origin-Realm=
 }
         =
;        { Destination-Realm=
 }
         =
;        { Destination-Host=
 }
         =
;        { Auth-Application-Id=
 }
         =
;        [ User-Name=
 ]
         =
;        [ Origin-State-Id=
 ]

 

{3GPP TS 29.209 V6.6.0= (2006-09)}

 

<AS-Request>  ::=3D <= Diameter Header: 274, REQ, PXY >

         = ;            &n= bsp;            = ;            &n= bsp;   < Session-Id >

         = ;            &n= bsp;            = ;            &n= bsp;  { Origin-Host }

         = ;            &n= bsp;            = ;            &n= bsp;  { Origin-Realm }

         = ;            &n= bsp;            = ;            &n= bsp;  { Destination-Realm= }

         = ;            &n= bsp;            = ;            &n= bsp;  { Destination-Host }

         = ;            &n= bsp;            = ;            &n= bsp;  { Auth-Application-Id }

         = ;            &n= bsp;           = ;            &n= bsp;   { Abort-Cause }         {Why= this AVP is Mandated Here ?}

         = ;            &n= bsp;            = ;            &n= bsp;  [ Origin-State-Id ]

         = ;            &n= bsp;            = ;            &n= bsp; *[ Proxy-Info ]

         = ;            &n= bsp;            = ;            &n= bsp; *[ Route-Record ]

         = ;            &n= bsp;            = ;            &n= bsp;  [ AVP ]

Is it correct for the Application to redefine= the Base Command code?

Thx

-Arun

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7A73F.EF65B9F3-- --===============1999323012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1999323012==-- From dime-bounces@ietf.org Tue Jun 05 08:06:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXna-0002j1-OL; Tue, 05 Jun 2007 08:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXnZ-0002iw-GS for dime@ietf.org; Tue, 05 Jun 2007 08:06:05 -0400 Received: from gws03.hcl.in ([203.105.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvXnO-0000ZH-7k for dime@ietf.org; Tue, 05 Jun 2007 08:06:05 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 703BC37EFF1; Tue, 5 Jun 2007 17:12:11 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid AE9A537D19C; Tue, 5 Jun 2007 14:46:11 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 14:50:03 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Reg. the Re-Definition of the Command code Date: Tue, 5 Jun 2007 14:49:36 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AB266@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Reg. the Re-Definition of the Command code Thread-Index: AcenPlYuyiZ9pWipRGCWCYghK+0S6QAASs4gAASLsIA= References: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AAF95@CHN-HCLT-EVS02.HCLT.CO RP.HCL.IN> From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 05 Jun 2007 09:20:03.0017 (UTC) FILETIME=[B2ACBB90:01C7A752] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-21.6346 TC:03 TRN:93 TV:3.6.1039(15218.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.6 (/) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1934080872==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1934080872== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A752.AB7F8BB3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A752.AB7F8BB3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I have one more Query. Can the Application Can remove any AVP that has been termed as Mandatory in the Base Command code? For example in the 3GPP TS 29.209 V6.6.0 (2006-09) I find that the "Re-Auth-Request-Type" (Which is mandatory AVP in RAR as per the FRC 3588) has been removed while re-defining the RAR in 3GPP TS 29.209. Is this Approach is Correct? Thx -Arun ________________________________ From: Arun Santhanam, TLS-Chennai=20 Sent: Tuesday, June 05, 2007 12:36 PM To: dime@ietf.org Subject: [Dime] Reg. the Re-Definition of the Command code =20 Hi Victor, I went though the " 3GPP TS 29.209 V6.6.0 (2006-09)" for Gq interface I'm surprised to see that the Base Command code=20 "RAR" and "ASR" has been redefined by the Gq Team. The following is the example of the Redefinition of the ASR Command code By the 3GPP Team. =20 =20 { Base Diameter Definition RFC 3588} =20 ::=3D < Diameter Header: 274, REQ, PXY > =20 < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } [ User-Name ] [ Origin-State-Id ] =20 {3GPP TS 29.209 V6.6.0 (2006-09)} =20 ::=3D < Diameter Header: 274, REQ, PXY >=20 < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Abort-Cause } {Why this AVP is Mandated Here ?} [ Origin-State-Id ] *[ Proxy-Info ] *[ Route-Record ] [ AVP ] Is it correct for the Application to redefine the Base Command code? Thx -Arun DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- =09 ------_=_NextPart_001_01C7A752.AB7F8BB3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Victor,

      =       I have one more Query. Can the Application Can remove any AVP that has = been termed as Mandatory in the Base Command = code?

      =       For example in the 3GPP TS 29.209 V6.6.0 (2006-09) I find that the “Re-Auth-Request-Type” (Which is mandatory AVP in RAR as per = the FRC 3588) has been removed while re-defining the RAR in 3GPP TS 29.209. = Is this Approach is Correct?

Thx

-Arun

From: = Arun Santhanam, TLS-Chennai
Sent: Tuesday, June 05, = 2007 12:36 PM
To: dime@ietf.org
Subject: [Dime] Reg. the Re-Definition of the Command code

 

Hi Victor,

         =    I went though the “ 3GPP TS 29.209 = V6.6.0 (2006-09)” for Gq interface I’m surprised to see that the = Base Command code

“RAR” and = “ASR” has been redefined by the Gq Team. The following is the example of the = Redefinition of the ASR Command code

By the 3GPP Team.     

 

        =
{ Base =
Diameter Definition RFC =
3588}
 
     <ASR>  =
::=3D < Diameter Header: 274, REQ, PXY >  =
            &=
nbsp;    
       &nbs=
p;         < Session-Id =
>
       &nbs=
p;         { Origin-Host =
}
       &nbs=
p;         { Origin-Realm =
}
       &nbs=
p;         { Destination-Realm =
}
       &nbs=
p;         { Destination-Host =
}
       &nbs=
p;         { Auth-Application-Id =
}
       &nbs=
p;         [ User-Name =
]
       &nbs=
p;         [ Origin-State-Id =
]

 

{3GPP TS 29.209 V6.6.0 = (2006-09)}

 

<AS-Request>  ::=3D = < Diameter Header: 274, REQ, PXY >

       &nbs= p;            = ;            =             &= nbsp;     < Session-Id >

       &nbs= p;            = ;            =             &= nbsp;    { Origin-Host }

       &nbs= p;            = ;            =             &= nbsp;    { Origin-Realm }

       &nbs= p;            = ;            =             &= nbsp;    { Destination-Realm = }

       &nbs= p;            = ;            =             &= nbsp;    { Destination-Host }

       &nbs= p;            = ;            =             &= nbsp;    { Auth-Application-Id }

       &nbs= p;            = ;           &nbs= p;            = ;     { Abort-Cause }         = {Why this AVP is Mandated Here ?}

       &nbs= p;            = ;            =             &= nbsp;    [ Origin-State-Id ]

       &nbs= p;            = ;            =             &= nbsp;   *[ Proxy-Info ]

       &nbs= p;            = ;            =             &= nbsp;   *[ Route-Record ]

       &nbs= p;            = ;            =             &= nbsp;    [ AVP ]

Is it correct for the Application to redefine = the Base Command code?

Thx

-Arun

DISCLAIMER:
-------------------------------------------------------------------------= ----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and = intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its = affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily = reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, = modification, distribution and / or publication of
this message without the prior written consent of the author of this = e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender = immediately. Before opening any mail and
attachments please check them for viruses and defect.

-------------------------------------------------------------------------= ----------------------------------------------
------_=_NextPart_001_01C7A752.AB7F8BB3-- --===============1934080872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1934080872==-- From dime-bounces@ietf.org Tue Jun 05 08:17:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXyD-0007vh-N4; Tue, 05 Jun 2007 08:17:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXxp-0007gh-OG for dime@ietf.org; Tue, 05 Jun 2007 08:16:41 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvXu0-0001li-Ig for dime@ietf.org; Tue, 05 Jun 2007 08:12:45 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l55CCAGP021813; Tue, 5 Jun 2007 08:12:10 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4665531A.4000501@tari.toshiba.com> Date: Tue, 05 Jun 2007 08:12:10 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" Subject: Re: [Dime] Reg. the Re-Definition of the Command code References: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AAF95@CHN-HCLT-EVS02.HCLT.CO RP.HCL.IN> <66E8AEE9980BB44CA5FCAD39EBA56AC6017AB266@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AB266@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l55CCAGP021813 X-Spam-Score: -2.4 (--) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Arun, In general, a command can be re-used and specialized as long as it=20 follows diameter extensibility rules. You can read through=20 http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00.t= xt=20 which hopefully explains this a little clearer. Also, it would be good=20 if you can review this document as well and send us comments. regards, victor > Hi Victor, > > I have one more Query. Can the Application Can remove any AVP that has=20 > been termed as Mandatory in the Base Command code? > > For example in the 3GPP TS 29.209 V6.6.0 (2006-09) I find that the=20 > =93Re-Auth-Request-Type=94 (Which is mandatory AVP in RAR as per the FR= C=20 > 3588) has been removed while re-defining the RAR in 3GPP TS 29.209. Is=20 > this Approach is Correct? > > Thx > > -Arun > > -----------------------------------------------------------------------= - > > *From:* Arun Santhanam, TLS-Chennai > *Sent:* Tuesday, June 05, 2007 12:36 PM > *To:* dime@ietf.org > *Subject:* [Dime] Reg. the Re-Definition of the Command code > > Hi Victor, > > I went though the =93 3GPP TS 29.209 V6.6.0 (2006-09)=94 for Gq interfa= ce=20 > I=92m surprised to see that the Base Command code > > =93RAR=94 and =93ASR=94 has been redefined by the Gq Team. The followin= g is=20 > the example of the Redefinition of the ASR Command code > > By the 3GPP Team. > > *{ Base Diameter Definition RFC 3588}* > * * > ::=3D < Diameter Header: 274, REQ, PXY > =20 > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Destination-Host } > { Auth-Application-Id } > [ User-Name ] > [ Origin-State-Id ] > > *{**3GPP TS 29.209 V6.6.0 (2006-09)}* > > ::=3D < Diameter Header: 274, REQ, PXY > > > < Session-Id > > > { Origin-Host } > > { Origin-Realm } > > { Destination-Realm } > > { Destination-Host } > > { Auth-Application-Id } > > * { Abort-Cause } {Why this AVP is Mandated Here ?}* > > [ Origin-State-Id ]** > > *[ Proxy-Info ] > > *[ Route-Record ] > > [ AVP ] > > Is it correct for the Application to redefine the Base Command code? > > Thx > > -Arun > > DISCLAIMER: > -----------------------------------------------------------------------= ------------------------------------------------ > > The contents of this e-mail and any attachment(s) are confidential and=20 > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its=20 > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily=20 > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of > this message without the prior written consent of the author of this=20 > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender=20 > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > -----------------------------------------------------------------------= ------------------------------------------------ > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 05 12:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvc0n-0007lH-1d; Tue, 05 Jun 2007 12:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvc0l-0007lC-IW for dime@ietf.org; Tue, 05 Jun 2007 12:35:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvc0k-0003Cr-0Y for dime@ietf.org; Tue, 05 Jun 2007 12:35:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2007 09:35:57 -0700 X-IronPort-AV: i="4.16,386,1175497200"; d="scan'208,217"; a="161033787:sNHT92542752" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l55GZvni009299; Tue, 5 Jun 2007 09:35:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l55GZt06019963; Tue, 5 Jun 2007 16:35:57 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:35:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Reg. the Re-Definition of the Command code Date: Tue, 5 Jun 2007 09:35:53 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504147EB1@xmb-sjc-215.amer.cisco.com> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AAF95@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Reg. the Re-Definition of the Command code Thread-Index: AcenPlYuyiZ9pWipRGCWCYghK+0S6QAASs4gABNttVA= References: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AAF95@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> From: "Glen Zorn \(gwz\)" To: "Arun Santhanam, TLS-Chennai" X-OriginalArrivalTime: 05 Jun 2007 16:35:55.0239 (UTC) FILETIME=[969D1F70:01C7A78F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5327; t=1181061357; x=1181925357; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Reg.=20the=20Re-Definition=20of=20the=20Comm and=20code |Sender:=20; bh=m82uNlUPfPILp4gFuo9ZIYYAsJlrU2yXDLVVKM1CfVY=; b=YCZTuWacOJY7JuQ8tkmty92mofbvw7ztfxCIf6dz2LgwXqaaP2kB1LfhjuHnf8Mgm+aS47PM vJlOeoHs65QScM4NwNCGMWBkVKx+tyzWK/R2ZdOHLikxzZhWbPj5kG0V; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360720605==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1360720605== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A78F.9676C871" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A78F.9676C871 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I went though the " 3GPP TS 29.209 V6.6.0 (2006-09)" for Gq interface I'm surprised to see that the Base Command code=20 "RAR" and "ASR" has been redefined by the Gq Team. The following is the example of the Redefinition of the ASR Command code By the 3GPP Team. =20 =20 ... =20 Is it correct for the Application to redefine the Base Command code? =20 No. =20 =20 ... ------_=_NextPart_001_01C7A78F.9676C871 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Victor,

           = =20 I went though the “ 3GPP TS 29.209 V6.6.0 = (2006-09)” for=20 Gq interface I’m surprised to see that the Base Command code=20

“RAR” = and “ASR” has been=20 redefined by the Gq Team. The following is the example of the = Redefinition of=20 the ASR Command code

By the 3GPP=20 Team.      

 
...
 
 Is it =
correct for the Application to redefine the Base Command code?  <=
/SPAN>

 No.  

 

...

------_=_NextPart_001_01C7A78F.9676C871-- --===============1360720605== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1360720605==-- From dime-bounces@ietf.org Tue Jun 05 12:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcG4-0007SO-Rm; Tue, 05 Jun 2007 12:51:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcG4-0007SJ-6m for dime@ietf.org; Tue, 05 Jun 2007 12:51:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcG3-0007Nh-1n for dime@ietf.org; Tue, 05 Jun 2007 12:51:48 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2007 09:51:46 -0700 X-IronPort-AV: i="4.16,386,1175497200"; d="scan'208,217"; a="161042218:sNHT138486762" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l55Gpkpl015815; Tue, 5 Jun 2007 09:51:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l55GpXth027490; Tue, 5 Jun 2007 16:51:46 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:51:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Reg. the Re-Definition of the Command code Date: Tue, 5 Jun 2007 09:51:39 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504147ED2@xmb-sjc-215.amer.cisco.com> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AB266@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Reg. the Re-Definition of the Command code Thread-Index: AcenPlYuyiZ9pWipRGCWCYghK+0S6QAASs4gAASLsIAAD7SwgA== References: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AAF95@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <66E8AEE9980BB44CA5FCAD39EBA56AC6017AB266@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> From: "Glen Zorn \(gwz\)" To: "Arun Santhanam, TLS-Chennai" X-OriginalArrivalTime: 05 Jun 2007 16:51:41.0314 (UTC) FILETIME=[CA84B620:01C7A791] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=22034; t=1181062306; x=1181926306; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Reg.=20the=20Re-Definition=20of=20the=20Comm and=20code |Sender:=20; bh=qGV/8vJcDwDiQGo+Xx1vdUl60GoWU/22JnPuVX6va7M=; b=CU8/jxRfBebaEYsMEG5kCq81fgwKO+5az1GgbRzRKm/DR8NmIvkLsUv+V9B8n1/FdnDcB/LM QUo4NAHurVky8Ap01UT99iS7oBGfCqbhZedu8o9+QCH7E73kwD+MCGEd; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 3419f078334bcda4102d3d704cee11c6 Cc: dime@ietf.org, gonzalo.camarillo@ericsson.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2101311493==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2101311493== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A791.CA54634A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A791.CA54634A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I have one more Query. Can the Application Can remove any AVP that has been termed as Mandatory in the Base Command code? For example in the 3GPP TS 29.209 V6.6.0 (2006-09) I find that the "Re-Auth-Request-Type" (Which is mandatory AVP in RAR as per the FRC 3588) has been removed while re-defining the RAR in 3GPP TS 29.209. Is this Approach is Correct?=20 No. The mandatory AVPs are, in part, what define a command: adding or removing them defines a new command. It is unfortunate that 3GPP apparently finds the task of appropriately requesting the allocation of a new command code and documenting it too onerous to complete. One might expect that this would be the subject of a liaison from the IETF to 3GPP... Thx -Arun ________________________________ From: Arun Santhanam, TLS-Chennai=20 Sent: Tuesday, June 05, 2007 12:36 PM To: dime@ietf.org Subject: [Dime] Reg. the Re-Definition of the Command code =20 Hi Victor, I went though the " 3GPP TS 29.209 V6.6.0 (2006-09)" for Gq interface I'm surprised to see that the Base Command code=20 "RAR" and "ASR" has been redefined by the Gq Team. The following is the example of the Redefinition of the ASR Command code By the 3GPP Team. =20 =20 { Base Diameter Definition RFC 3588} =20 ::=3D < Diameter Header: 274, REQ, PXY > =20 < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } [ User-Name ] [ Origin-State-Id ] =20 {3GPP TS 29.209 V6.6.0 (2006-09)} =20 ::=3D < Diameter Header: 274, REQ, PXY >=20 < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Abort-Cause } {Why this AVP is Mandated Here ?} [ Origin-State-Id ] *[ Proxy-Info ] *[ Route-Record ] [ AVP ] Is it correct for the Application to redefine the Base Command code? Thx -Arun DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- =09 ------_=_NextPart_001_01C7A791.CA54634A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Victor,

           = =20 I have one more Query. Can the Application Can remove any AVP that has = been=20 termed as Mandatory in the Base Command = code?

           = =20 For example in the 3GPP TS 29.209 V6.6.0 (2006-09) I find that the=20 “Re-Auth-Request-Type” (Which is mandatory AVP in RAR as per = the FRC 3588) has=20 been removed while re-defining the RAR in 3GPP TS 29.209. Is this = Approach is=20 Correct? 

No.  The = mandatory AVPs=20 are, in part, what define a command: adding or removing them defines = a new=20 command.  It is unfortunate that 3GPP apparently finds the = task of=20 appropriately requesting the allocation of a new command code and=20 documenting it too onerous to complete.  One might expect that = this=20 would be the subject of a liaison from the IETF to=20 3GPP...

Thx

-Arun

From:=20 Arun Santhanam, TLS-Chennai =
Sent: Tuesday, June = 05, 2007=20 12:36 PM
To:=20 dime@ietf.org
Subject: [Dime]=20 Reg. the Re-Definition of the Command = code

 

Hi=20 Victor,

           = =20 I went though the “ 3GPP TS 29.209 V6.6.0 = (2006-09)” for=20 Gq interface I’m surprised to see that the Base Command code=20

“RAR” = and “ASR” has been=20 redefined by the Gq Team. The following is the example of the = Redefinition of=20 the ASR Command code

By the 3GPP=20 Team.     

 

        { Base =
Diameter Definition RFC =
3588}
 
     <ASR>  ::=3D < Diameter =
Header: 274, REQ, PXY >  =
            &=
nbsp;    
           &=
nbsp;     < Session-Id =
>
           &=
nbsp;     { Origin-Host =
}
           &=
nbsp;     { Origin-Realm =
}
           &=
nbsp;     { Destination-Realm =
}
           &=
nbsp;     { Destination-Host =
}
           &=
nbsp;     { Auth-Application-Id =
}
           &=
nbsp;     [ User-Name =
]
           &=
nbsp;     [ Origin-State-Id =
]

 

{3GPP=20 TS 29.209 V6.6.0 (2006-09)}

 

<AS-Request>  ::=3D=20 < Diameter Header: 274, REQ, PXY >

           &= nbsp;           &n= bsp;           &nb= sp;           =20   < Session-Id >

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Origin-Host }

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Origin-Realm }

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Destination-Realm = }

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Destination-Host }

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Auth-Application-Id }

           &= nbsp;           =20            &= nbsp;           =20  { Abort-Cause }         = {Why this=20 AVP is Mandated Here ?}

           &= nbsp;           &n= bsp;           &nb= sp;           =20  [ Origin-State-Id ]

           &= nbsp;           &n= bsp;           &nb= sp;           =20 *[ Proxy-Info ]

           &= nbsp;           &n= bsp;           &nb= sp;           =20 *[ Route-Record ]

           &= nbsp;           &n= bsp;           &nb= sp;           =20  [ AVP ]

Is it correct for the = Application to=20 redefine the Base Command code?

Thx

-Arun

DISCLAIMER:
------------------------------------------= -------------------------------------------------------------------------= ----

The=20 contents of this e-mail and any attachment(s) are confidential and = intended for the named recipient(s) only.
It shall not attach = any=20 liability on the originator or HCL or its affiliates. Any views or = opinions presented in
this email are solely those of the = author and=20 may not necessarily reflect the opinions of HCL or its = affiliates.
Any=20 form of reproduction, dissemination, copying, disclosure, = modification,=20 distribution and / or publication of
this message without the = prior=20 written consent of the author of this e-mail is strictly = prohibited. If=20 you have
received this email in error please delete it and = notify the=20 sender immediately. Before opening any mail and
attachments = please=20 check them for viruses and=20 = defect.

----------------------------------------------------------= -------------------------------------------------------------
<= /TD>
------_=_NextPart_001_01C7A791.CA54634A-- --===============2101311493== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2101311493==-- From dime-bounces@ietf.org Tue Jun 05 13:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcW6-0003li-CE; Tue, 05 Jun 2007 13:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcW5-0003ld-GW for dime@ietf.org; Tue, 05 Jun 2007 13:08:21 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcW4-0001V5-Bl for dime@ietf.org; Tue, 05 Jun 2007 13:08:21 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l55H80sP021151; Tue, 5 Jun 2007 20:08:07 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 20:08:05 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 12:08:02 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Reg. the Re-Definition of the Command code Date: Tue, 5 Jun 2007 12:07:59 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4FA7A0F4@daebe103.NOE.Nokia.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504147ED2@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Reg. the Re-Definition of the Command code Thread-Index: AcenPlYuyiZ9pWipRGCWCYghK+0S6QAASs4gAASLsIAAD7SwgAAA2iYg References: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AAF95@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN><66E8AEE9980BB44CA5FCAD39EBA56AC6017AB266@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <4C0FAAC489C8B74F96BEAD85EAEB262504147ED2@xmb-sjc-215.amer.cisco.com> From: To: , X-OriginalArrivalTime: 05 Jun 2007 17:08:02.0498 (UTC) FILETIME=[13598220:01C7A794] X-Nokia-AV: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Cc: dime@ietf.org, gonzalo.camarillo@ericsson.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577811957==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0577811957== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A794.12F9FD60" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A794.12F9FD60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd side with Glen on this. I think using new command codes is right thing to do. Reusing but redefining existing command codes will create a long term mess, IMO. =20 John ________________________________ From: ext Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: 05 June, 2007 09:52 To: Arun Santhanam, TLS-Chennai Cc: dime@ietf.org; gonzalo.camarillo@ericsson.com Subject: RE: [Dime] Reg. the Re-Definition of the Command code =09 =09 Hi Victor, I have one more Query. Can the Application Can remove any AVP that has been termed as Mandatory in the Base Command code? For example in the 3GPP TS 29.209 V6.6.0 (2006-09) I find that the "Re-Auth-Request-Type" (Which is mandatory AVP in RAR as per the FRC 3588) has been removed while re-defining the RAR in 3GPP TS 29.209. Is this Approach is Correct?=20 No. The mandatory AVPs are, in part, what define a command: adding or removing them defines a new command. It is unfortunate that 3GPP apparently finds the task of appropriately requesting the allocation of a new command code and documenting it too onerous to complete. One might expect that this would be the subject of a liaison from the IETF to 3GPP... Thx -Arun =09 ________________________________ From: Arun Santhanam, TLS-Chennai=20 Sent: Tuesday, June 05, 2007 12:36 PM To: dime@ietf.org Subject: [Dime] Reg. the Re-Definition of the Command code =20 Hi Victor, I went though the " 3GPP TS 29.209 V6.6.0 (2006-09)" for Gq interface I'm surprised to see that the Base Command code=20 "RAR" and "ASR" has been redefined by the Gq Team. The following is the example of the Redefinition of the ASR Command code By the 3GPP Team. =20 =20 { Base Diameter Definition RFC 3588} =20 ::=3D < Diameter Header: 274, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } [ User-Name ] [ Origin-State-Id ] =20 {3GPP TS 29.209 V6.6.0 (2006-09)} =20 ::=3D < Diameter Header: 274, REQ, PXY >=20 < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Abort-Cause } {Why this AVP is Mandated Here ?} [ Origin-State-Id ] *[ Proxy-Info ] *[ Route-Record ] [ AVP ] Is it correct for the Application to redefine the Base Command code? Thx -Arun DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- =09 ------_=_NextPart_001_01C7A794.12F9FD60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'd side with Glen on this.  I think using = new command=20 codes is right thing to do.  Reusing but redefining existing = command codes=20 will create a long term mess, IMO.
 
John

From: ext Glen Zorn (gwz)=20 [mailto:gwz@cisco.com]
Sent: 05 June, 2007 = 09:52
To: Arun=20 Santhanam, TLS-Chennai
Cc: dime@ietf.org;=20 gonzalo.camarillo@ericsson.com
Subject: RE: [Dime] Reg. the=20 Re-Definition of the Command code

Hi=20 Victor,

           = =20 I have one more Query. Can the Application Can remove any AVP that has = been=20 termed as Mandatory in the Base Command = code?

           = =20 For example in the 3GPP TS 29.209 V6.6.0 (2006-09) I find that the=20 “Re-Auth-Request-Type” (Which is mandatory AVP in RAR as = per the FRC 3588) has=20 been removed while re-defining the RAR in 3GPP TS 29.209. Is this = Approach is=20 Correct? 

No.  The = mandatory AVPs=20 are, in part, what define a command: adding or removing them defines=20 a new command.  It is unfortunate that 3GPP = apparently finds=20 the task of appropriately requesting the allocation of a new command=20 code and documenting it too onerous to complete.  One = might=20 expect that this would be the subject of a liaison from the IETF to=20 3GPP...

Thx

-Arun

From:=20 Arun Santhanam, = TLS-Chennai=20
Sent: Tuesday, = June 05, 2007=20 12:36 PM
To:=20 dime@ietf.org
Subject: [Dime]=20 Reg. the Re-Definition of the Command = code

 

Hi=20 Victor,

           = =20 I went though the “ 3GPP TS 29.209 V6.6.0 = (2006-09)”=20 for Gq interface I’m surprised to see that the Base Command code =

“RAR” and “ASR” has been=20 redefined by the Gq Team. The following is the example of the = Redefinition of=20 the ASR Command code

By the 3GPP=20 Team.     

 

        { Base =
Diameter Definition RFC =
3588}
 
     <ASR>  ::=3D < Diameter =
Header: 274, REQ, PXY >  =
            &=
nbsp;    
           &=
nbsp;     < Session-Id =
>
           &=
nbsp;     { Origin-Host =
}
           &=
nbsp;     { Origin-Realm =
}
           &=
nbsp;     { Destination-Realm =
}
           &=
nbsp;     { Destination-Host =
}
           &=
nbsp;     { Auth-Application-Id =
}
           &=
nbsp;     [ User-Name =
]
           &=
nbsp;     [ Origin-State-Id =
]

 

{3GPP=20 TS 29.209 V6.6.0 (2006-09)}

 

<AS-Request>  ::=3D=20 < Diameter Header: 274, REQ, PXY >

           &= nbsp;           &n= bsp;           &nb= sp;           =20   < Session-Id >

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Origin-Host }

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Origin-Realm }

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Destination-Realm = }

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Destination-Host }

           &= nbsp;           &n= bsp;           &nb= sp;           =20  { Auth-Application-Id }

           &= nbsp;           =20            &= nbsp;           =20  { Abort-Cause }         = {Why=20 this AVP is Mandated = Here ?}

           &= nbsp;           &n= bsp;           &nb= sp;           =20  [ Origin-State-Id ]

           &= nbsp;           &n= bsp;           &nb= sp;           =20 *[ Proxy-Info ]

           &= nbsp;           &n= bsp;           &nb= sp;           =20 *[ Route-Record ]

           &= nbsp;           &n= bsp;           &nb= sp;           =20  [ AVP ]

Is it correct for the = Application to=20 redefine the Base Command code?

Thx

-Arun

DISCLAIMER:
------------------------------------------= -------------------------------------------------------------------------= ----

The=20 contents of this e-mail and any attachment(s) are confidential = and=20 intended for the named recipient(s) only.
It shall not attach = any=20 liability on the originator or HCL or its affiliates. Any views = or=20 opinions presented in
this email are solely those of the = author and=20 may not necessarily reflect the opinions of HCL or its=20 affiliates.
Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication of =
this=20 message without the prior written consent of the author of this = e-mail=20 is strictly prohibited. If you have
received this email in = error=20 please delete it and notify the sender immediately. Before = opening any=20 mail and
attachments please check them for viruses and=20 = defect.

----------------------------------------------------------= -------------------------------------------------------------
<= /TD>
------_=_NextPart_001_01C7A794.12F9FD60-- --===============0577811957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0577811957==-- From dime-bounces@ietf.org Tue Jun 05 13:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcmM-0006Pt-KX; Tue, 05 Jun 2007 13:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcmM-0006Po-8p for dime@ietf.org; Tue, 05 Jun 2007 13:25:10 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcmL-0002x6-NM for dime@ietf.org; Tue, 05 Jun 2007 13:25:10 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l55HO68L023163; Tue, 5 Jun 2007 13:24:06 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46659C36.8040309@tari.toshiba.com> Date: Tue, 05 Jun 2007 13:24:06 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Dime] Reg. the Re-Definition of the Command code References: <66E8AEE9980BB44CA5FCAD39EBA56AC6017AAF95@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN><66E8AEE9980BB44CA5FCAD39EBA56AC6017AB266@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> <4C0FAAC489C8B74F96BEAD85EAEB262504147ED2@xmb-sjc-215.amer.cisco.com> <071568CA7B789D4AA170CEF8C9613B4FA7A0F4@daebe103.NOE.Nokia.com> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4FA7A0F4@daebe103.NOE.Nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l55HO68L023163 X-Spam-Score: -2.4 (--) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: dime@ietf.org, gwz@cisco.com, gonzalo.camarillo@ericsson.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Ok. Sounds reasonable. We can update the guidelines doc to reflect this. regards, victor > I'd side with Glen on this. I think using new command codes is right=20 > thing to do. Reusing but redefining existing command codes will create=20 > a long term mess, IMO. > John > > -------------------------------------------------------------------= ----- > *From:* ext Glen Zorn (gwz) [mailto:gwz@cisco.com] > *Sent:* 05 June, 2007 09:52 > *To:* Arun Santhanam, TLS-Chennai > *Cc:* dime@ietf.org; gonzalo.camarillo@ericsson.com > *Subject:* RE: [Dime] Reg. the Re-Definition of the Command code > > Hi Victor, > > I have one more Query. Can the Application Can remove any AVP that > has been termed as Mandatory in the Base Command code? > > For example in the 3GPP TS 29.209 V6.6.0 (2006-09) I find that the > =93Re-Auth-Request-Type=94 (Which is mandatory AVP in RAR as per th= e > FRC 3588) has been removed while re-defining the RAR in 3GPP TS > 29.209. Is this Approach is Correct? > > No. The mandatory AVPs are, in part, what define a command: adding > or removing them defines a new command. It is unfortunate that > 3GPP apparently finds the task of appropriately requesting the > allocation of a new command code and documenting it too onerous to > complete. One might expect that this would be the subject of a > liaison from the IETF to 3GPP... > > Thx > > -Arun > > -------------------------------------------------------------------= ----- > > *From:* Arun Santhanam, TLS-Chennai > *Sent:* Tuesday, June 05, 2007 12:36 PM > *To:* dime@ietf.org > *Subject:* [Dime] Reg. the Re-Definition of the Command code > > Hi Victor, > > I went though the =93 3GPP TS 29.209 V6.6.0 (2006-09)=94 for Gq > interface I=92m surprised to see that the Base Command code > > =93RAR=94 and =93ASR=94 has been redefined by the Gq Team. The foll= owing > is the example of the Redefinition of the ASR Command code > > By the 3GPP Team. > > *{ Base Diameter Definition RFC 3588}* > > * * > > ::=3D < Diameter Header: 274, REQ, PXY > = =20 > > < Session-Id > > > { Origin-Host } > > { Origin-Realm } > > { Destination-Realm } > > { Destination-Host } > > { Auth-Application-Id } > > [ User-Name ] > > [ Origin-State-Id ] > > *{**3GPP TS 29.209 V6.6.0 (2006-09)}* > > ::=3D < Diameter Header: 274, REQ, PXY > > > < Session-Id > > > { Origin-Host } > > { Origin-Realm } > > { Destination-Realm } > > { Destination-Host } > > { Auth-Application-Id } > > * { Abort-Cause } {Why this AVP is Mandated Here ?}* > > [ Origin-State-Id ]** > > *[ Proxy-Info ] > > *[ Route-Record ] > > [ AVP ] > > Is it correct for the Application to redefine the Base Command code= ? > > Thx > > -Arun > > DISCLAIMER: > -------------------------------------------------------------------= ---------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of > this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the > sender immediately. Before opening any mail and > attachments please check them for viruses and defect. > > -------------------------------------------------------------------= ---------------------------------------------------- > > -----------------------------------------------------------------------= - > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 05 18:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvhrO-0000NK-Cl; Tue, 05 Jun 2007 18:50:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvhrF-00009X-OQ; Tue, 05 Jun 2007 18:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HvhrE-0000XC-By; Tue, 05 Jun 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 41F3B2AC98; Tue, 5 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hvhqk-0006ub-0V; Tue, 05 Jun 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 05 Jun 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-04.txt Pages : 159 Date : 2007-6-5 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-rfc3588bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-rfc3588bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-5150534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-5150534.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jun 06 08:03:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuEr-0004oV-UR; Wed, 06 Jun 2007 08:03:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuEr-0004lo-2x for dime@ietf.org; Wed, 06 Jun 2007 08:03:45 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HvuEo-0000Lp-M0 for dime@ietf.org; Wed, 06 Jun 2007 08:03:45 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l56BwIqS026426 for ; Wed, 6 Jun 2007 07:58:18 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4666A15A.30305@tari.toshiba.com> Date: Wed, 06 Jun 2007 07:58:18 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: dime@ietf.org Subject: [Dime] rfc3588bis document update Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, The latest version of rfc3588bis is now available: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt As a short summary, the change history of this document are as follows: * 00 and rfc3588 are identical * 01 incorporates the changes proposed in http://tools.ietf.org/id/draft-fajardo-dime-diameter-errata-00.txt * 02 includes proposals for 32, 36, 44, 49, 41, 40, 31, 26 * 03 includes proposals for 28, 33, 37, 38, 51, 52, 50 (partially) * 04 includes proposals for 34, 50, 54, 53 * Open issues remain: 35, 39 Suggested approaches for open issues: #35 - Representation/Encoding of diameter identities (FQDN's). We may need to consult with DNS folks on how to properly support internationalization etc for FQDN names (if needed). This is in addition to the default ascii representation. #39 - How to do TLS certificate validation against peer names. We may need to consult with security folks on how to properly support sanity checks on certificates; i.e, use of CN, SN etc against a diameter identity. For easier reading the relevant diffs are: * between 01 from 3588: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-01-from-rfc3588.diff.html * between 02 from 01: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-02-from-1.diff.html * between 03 from 02: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-03-from-2.diff.html * between 04 from 03: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-04-from-3.diff.html The issue tracker can be found in: http://www.tschofenig.priv.at:8080/diameter-interop/index regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 06 08:21:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuW0-0001o9-7W; Wed, 06 Jun 2007 08:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuVz-0001jC-2o for dime@ietf.org; Wed, 06 Jun 2007 08:21:27 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvuVs-0003Xm-Tv for dime@ietf.org; Wed, 06 Jun 2007 08:21:27 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ700FPDRM81K@szxga04-in.huawei.com> for dime@ietf.org; Wed, 06 Jun 2007 20:20:33 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ70040FRM8X3@szxga04-in.huawei.com> for dime@ietf.org; Wed, 06 Jun 2007 20:20:32 +0800 (CST) Received: from huawei1515 ([10.18.4.137]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JJ7009ORRM44K@szxml03-in.huawei.com> for dime@ietf.org; Wed, 06 Jun 2007 20:20:32 +0800 (CST) Date: Wed, 06 Jun 2007 17:50:27 +0530 From: Rajith R Subject: RE: [Dime] rfc3588bis document update In-reply-to: <4666A15A.30305@tari.toshiba.com> To: 'Victor Fajardo' , dime@ietf.org Message-id: <004401c7a835$11bd2510$8904120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceoMsMxomFEU5sZQiOhJKGf/sJ3SAAAYrpA X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I have some comments on RAR handling added to this draft: Client is at liberty to / not to comply to an RAR (alike ASR). So I think the behaviour of client sending an RAA with UNABLE_TO_COMPLY should be similar to sending an ASA with similar result code i.e. client remains in Open state where as Server State machine on receiving this RAA will change to Idle state. I think the ASA with UNABLE_TO_COMPLY behaviour specifically addresses some proxy initiated ASR scenario, though I am not sure how. Can any one throw some light? May be same consideration should be applied to (stateful) proxy initiated RARs also. Regards Rajith >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Wednesday, June 06, 2007 5:28 PM >To: dime@ietf.org >Subject: [Dime] rfc3588bis document update > >Hi all, > >The latest version of rfc3588bis is now available: >http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt > >As a short summary, the change history of this document are as follows: > >* 00 and rfc3588 are identical >* 01 incorporates the changes proposed in >http://tools.ietf.org/id/draft-fajardo-dime-diameter-errata-00.txt >* 02 includes proposals for 32, 36, 44, 49, 41, 40, 31, 26 >* 03 includes proposals for 28, 33, 37, 38, 51, 52, 50 (partially) >* 04 includes proposals for 34, 50, 54, 53 >* Open issues remain: 35, 39 > >Suggested approaches for open issues: > >#35 - Representation/Encoding of diameter identities (FQDN's). >We may need to consult with DNS folks on how to properly >support internationalization etc for FQDN names (if needed). >This is in addition to the default ascii representation. > >#39 - How to do TLS certificate validation against peer names. >We may need to consult with security folks on how to properly >support sanity checks on certificates; i.e, use of CN, SN etc >against a diameter identity. > >For easier reading the relevant diffs are: > >* between 01 from 3588: >http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-0 >1-from-rfc3588.diff.html >* between 02 from 01: >http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-0 >2-from-1.diff.html >* between 03 from 02: >http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-0 >3-from-2.diff.html >* between 04 from 03: >http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-0 >4-from-3.diff.html > >The issue tracker can be found in: >http://www.tschofenig.priv.at:8080/diameter-interop/index > >regards, >victor > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 06 08:40:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuoT-0005TC-1Q; Wed, 06 Jun 2007 08:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuoR-0005Rg-5n for dime@ietf.org; Wed, 06 Jun 2007 08:40:31 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvuoP-00087B-Sv for dime@ietf.org; Wed, 06 Jun 2007 08:40:31 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l56Ce7do026521; Wed, 6 Jun 2007 08:40:07 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4666AB27.5030008@tari.toshiba.com> Date: Wed, 06 Jun 2007 08:40:07 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] rfc3588bis document update References: <004401c7a835$11bd2510$8904120a@china.huawei.com> In-Reply-To: <004401c7a835$11bd2510$8904120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Rajith, > I have some comments on RAR handling added to this draft: > Client is at liberty to / not to comply to an RAR (alike ASR). So I think > the behaviour of client sending an RAA with UNABLE_TO_COMPLY should be > similar to sending an ASA with similar result code i.e. client remains in > Open state where as Server State machine on receiving this RAA will change > to Idle state. > This maybe the case but I'm not sure. The semantics of aborting a sessions is different from a non-compliance of re-authorization so their repercussions are probably different. It maybe best if we get more opinion on this. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 06 15:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1Wn-0008Cu-P5; Wed, 06 Jun 2007 15:50:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1Wb-00089e-Ni; Wed, 06 Jun 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hw1Wb-0005kp-Dp; Wed, 06 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AE51D175D8; Wed, 6 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hw1W6-0003yD-Dz; Wed, 06 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 06 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-app-design-guide-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-01.txt Pages : 16 Date : 2007-6-6 The Diameter Base protocol provides rules on how to extend Diameter and to create new Diameter applications. This is a companion document to clarify these rules. This document does not intended to add, remove or change these rules, rather it helps protocol designers to extend Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-app-design-guide-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-app-design-guide-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-6125223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-app-design-guide-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-6125223.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Fri Jun 08 11:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwgr0-00047v-7p; Fri, 08 Jun 2007 11:58:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwgqz-00047a-FG for dime@ietf.org; Fri, 08 Jun 2007 11:58:21 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwgqy-0002d7-LP for dime@ietf.org; Fri, 08 Jun 2007 11:58:21 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l58FwDLr016133 for ; Fri, 8 Jun 2007 17:58:13 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Jun 2007 17:58:11 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401590C17@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter auditing - PART 1 Thread-Index: Acep5dCmWImxFqp+QR20+AFV7RfBYA== From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Fri, 08 Jun 2007 17:58:13 +0200 (CEST) X-Spam-Status: No, score=-152.2 required=4.7 tests=ALL_TRUSTED,BAYES_00, HTML_30_40, HTML_MESSAGE, USER_IN_BLACKLIST, USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3380/Fri Jun 8 14:34:26 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Subject: [Dime] Diameter auditing - PART 1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1556063484==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1556063484== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9E5.D180A133" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A9E5.D180A133 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All,=20 I've been looking in whether the original work on Diameter resource management extensions now captured in http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.tx t [RM-ext] would meet the demands identified in http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01 .txt [SR] on Diameter state recovery considerations. Comments on this analyze are very wellcome.=20 Going through section 5.2.1 and 5.2.2 (PART 1) of [SR] and matching against [RM-ext] I noted the following (remaing sections/PARTs in following mail):=20 1) Having a standby node informing remote peers of the failure of an active instance (i.e. 5.2.1 in [SR]) is not covered by [RM-ext], not in any other spec (as far as I know). I'm not sure what kind of message would be appropriate for this purpose (i.e. a new mesage or an existing one such as CER). Any views on this?=20 2) Synchronizing state (i.e. 5.2.2, first paragraph in [SR]) is not natively supported by [RM-ext], but could be suppored with a small change/addition I beleive. E.g. through a flag in the SRQ saying whether all session information is requested for all active sessions (all information on all sessions is requested when no Session-Id is provided in the SRQ), or just the session-Id of all active sesisons (i.e. an SRR without any Resource-bag AVPs).=20 3) Reconstructing session state using application messages (i.e. 5.2.2, Using Application Messages in [SR]) is generally not supported by Diameter nor in [RM-ext]. As I understand the protocol a AAR updating an existing session is identified by that the Session-Id is known by the server (i.e. is active), while an AAR establishing a new session provides a new Session-Id not currently being used for any active session. Hence, a flag indicating that the message is for an existing sesison (or a separate message) would be needed to facilitate state reconstruction using mid-session messages.=20 4) Reconstructing session state using generic messages (i.e. 5.2.2, Using a Generic Message in [SR]) is indeed supported by [RM-ext] (i.e. through SRQ and SRR in which state information for several sessions can be requested and provided respectively).=20 Best regards,=20 Ulf=20 ------_=_NextPart_001_01C7A9E5.D180A133 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Diameter auditing - PART 1

All,

I've been looking in = whether the original work on Diameter resource management extensions now = captured in http://www.ietf.org/internet-drafts/draft-bodin-dime-audit= ing-reqs-02.txt [RM-ext] would meet the demands identified in = http://www.ietf.org/internet-drafts/draft-asveren-dime-sta= te-recovery-01.txt [SR] on Diameter state recovery considerations. Comments = on this analyze are very wellcome.

Going through section = 5.2.1 and 5.2.2 (PART 1) of [SR] and matching against [RM-ext] I noted = the following (remaing sections/PARTs in following mail): =

1) Having a standby = node informing remote peers of the failure of an active instance (i.e. = 5.2.1 in [SR]) is not covered by [RM-ext], not in any other spec (as far = as I know). I'm not sure what kind of message would be appropriate for = this purpose (i.e. a new mesage or an existing one such as CER). Any = views on this?

2) Synchronizing = state (i.e. 5.2.2, first paragraph in [SR]) is not natively supported by = [RM-ext], but could be suppored with a small change/addition I beleive. = E.g. through a flag in the SRQ saying whether all session information is = requested for all active sessions (all information on all sessions is = requested when no Session-Id is provided in the SRQ), or just the = session-Id of all active sesisons (i.e. an SRR without any Resource-bag = AVPs).

3) Reconstructing = session state using application messages (i.e. 5.2.2, Using Application = Messages in [SR]) is generally not supported by Diameter nor in = [RM-ext]. As I understand the protocol a AAR updating an existing = session is identified by that the Session-Id is known by the server = (i.e. is active), while an AAR establishing a new session provides a new = Session-Id not currently being used for any active session. Hence, a = flag indicating that the message is for an existing sesison (or a = separate message) would be needed to facilitate state reconstruction = using mid-session messages.

4) Reconstructing = session state using generic messages (i.e. 5.2.2, Using a Generic = Message in [SR]) is indeed supported by [RM-ext] (i.e. through SRQ and = SRR in which state information for several sessions can be requested and = provided respectively).

Best regards,
Ulf



------_=_NextPart_001_01C7A9E5.D180A133-- --===============1556063484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1556063484==-- From dime-bounces@ietf.org Mon Jun 11 06:29:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxh9A-0001Te-1p; Mon, 11 Jun 2007 06:29:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxh98-0001TZ-Kg for dime@ietf.org; Mon, 11 Jun 2007 06:29:14 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxh97-0007zp-Dl for dime@ietf.org; Mon, 11 Jun 2007 06:29:14 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 0CDC536004D for ; Mon, 11 Jun 2007 15:57:44 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTP id D65C0360035for ; Mon, 11 Jun 2007 15:57:43 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 15:59:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Jun 2007 15:58:08 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC60186219B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg. the uasge of the E2E-SequenceAVp thread-index: AcesBY53lkyPmnLiR5OxjInCE82+vQADItyA From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 11 Jun 2007 10:29:08.0691 (UTC) FILETIME=[582AE230:01C7AC13] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-5.8125 TC:1F TRN:59 TV:3.6.1039(15226.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.4 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Subject: [Dime] FW: Reg. the uasge of the E2E-SequenceAVp X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026323079==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1026323079== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AC13.3CCB8784" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AC13.3CCB8784 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi All, Can any one clarify my doubt in the E2E-Sequence AVP=20 a) In the RFC 3588 the E2E-Sequence AVP is termed as Grouped but I don't find any rule governing the AVP. b) If the E2E-Sequence AVP will carry the Counter and a random number, then which AVP will carry Counter and Random number Value? Thx -Arun DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7AC13.3CCB8784 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi All,

         &n= bsp;  Can any one clarify my doubt in the E2E-Sequence AVP=

a)      = In= the RFC 3588 the E2E-Sequence AVP is termed as Grouped but I don’t find any= rule governing the AVP.

b)      = If= the E2E-Sequence AVP will carry the Counter and a random number, then which AVP= will carry Counter and Random number Value?

Thx

-Arun

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7AC13.3CCB8784-- --===============1026323079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1026323079==-- From dime-bounces@ietf.org Mon Jun 11 07:07:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxhjg-00068A-8v; Mon, 11 Jun 2007 07:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxhjf-00066D-27 for dime@ietf.org; Mon, 11 Jun 2007 07:06:59 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxhje-0003Hd-O9 for dime@ietf.org; Mon, 11 Jun 2007 07:06:59 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1146279nzd for ; Mon, 11 Jun 2007 04:06:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=e1Tjotgmh+Rgg8AJ8ahpywzZnly//7QK5NGxKBrbztpa/7f7UAczHOGi0n5CMYmNyijVEv80Gk6kJ00luvPcw/oJK1LEyZYLx7sAIc41AJnrdRMU3U80WCjA2ZT5Q//xxBqhFRWyWkCdXp6bTKxYrljQq2Vyqfpyiq7ljjqok0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=nzGVYcmnuLzcwj3p4LIXd/WJ6wY1g6UIfiEtc0usk2NCPa/iHEJiaYgrvy7qQmvP4HfSKbCgk8aVT4Od/o6kjUwjoY36pCAKDBj3eS4kO/2hHtoxqOrkUVRKbWCmSSjLLznTFxaN/bx7I1PtrbGqr86iysdIie+hAnX7E9mwdn4= Received: by 10.114.14.1 with SMTP id 1mr5372972wan.1181560017887; Mon, 11 Jun 2007 04:06:57 -0700 (PDT) Received: by 10.115.75.5 with HTTP; Mon, 11 Jun 2007 04:06:57 -0700 (PDT) Message-ID: Date: Mon, 11 Jun 2007 13:06:57 +0200 From: "Thomas Lindgren" To: dime@ietf.org Subject: Re: [Dime] FW: Reg. the uasge of the E2E-SequenceAVp In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC60186219B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> MIME-Version: 1.0 References: <66E8AEE9980BB44CA5FCAD39EBA56AC60186219B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1839085459==" Errors-To: dime-bounces@ietf.org --===============1839085459== Content-Type: multipart/alternative; boundary="----=_Part_94243_30361024.1181560017862" ------=_Part_94243_30361024.1181560017862 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/11/07, Arun Santhanam, TLS-Chennai wrote: > > > > Hi All, > > Can any one clarify my doubt in the E2E-Sequence AVP > > a) In the RFC 3588 the E2E-Sequence AVP is termed as Grouped but I > don't find any rule governing the AVP. > > b) If the E2E-Sequence AVP will carry the Counter and a random > number, then which AVP will carry Counter and Random number Value? > As far as I know, E2E-Sequence is poorly defined and never explicitly used. In the greater picture, there seems to be a vaguely defined end-to-end security framework lurking in the background of RFC 3588, with P-bits, HMACs, proxying, the E2E-Security AVP, references to a dead internet draft on "CMS" and so on. I think this part needs to get more solid to be truly useful, and that it probably would be best to move it, as far as possible, off to a fresh RFC for a proper treatment. Best, Thomas -- Thomas Lindgren, Millpond Services Ltd ------=_Part_94243_30361024.1181560017862 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/11/07, Arun Santhanam, TLS-Chennai <arunsanthanam@hcl.in> wrote:

 

Hi All,

            Can any one clarify my doubt in the E2E-Sequence AVP

a)       In the RFC 3588 the E2E-Sequence AVP is termed as Grouped but I don't find any rule governing the AVP.

b)       If the E2E-Sequence AVP will carry the Counter and a random number, then which AVP will carry Counter and Random number Value?


As far as I know, E2E-Sequence is poorly defined and never explicitly used.

In the greater picture, there seems to be a vaguely defined end-to-end security framework lurking in the background of RFC 3588, with P-bits, HMACs, proxying, the E2E-Security AVP, references to a dead internet draft on "CMS" and so on. I think this part needs to get more solid to be truly useful, and that it probably would be best to move it, as far as possible, off to a fresh RFC for a proper treatment.

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd



------=_Part_94243_30361024.1181560017862-- --===============1839085459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1839085459==-- From dime-bounces@ietf.org Mon Jun 11 15:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxptx-0001J6-6Z; Mon, 11 Jun 2007 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxptq-0000yP-Uz; Mon, 11 Jun 2007 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxptq-0007VW-IM; Mon, 11 Jun 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4A73926E82; Mon, 11 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00056g-6M; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-qos-parameters-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Parameters for Usage with the AAA Framework Author(s) : J. Korhonen, H. Tschofenig Filename : draft-ietf-dime-qos-parameters-00.txt Pages : 19 Date : 2007-6-11 This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-qos-parameters-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-qos-parameters-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11102657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-parameters-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-parameters-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11102657.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Jun 12 11:17:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy884-0005Tb-DW; Tue, 12 Jun 2007 11:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy883-0005TT-1c for dime@ietf.org; Tue, 12 Jun 2007 11:17:55 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy881-00048v-TS for dime@ietf.org; Tue, 12 Jun 2007 11:17:55 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 701B937C01F for ; Tue, 12 Jun 2007 20:43:41 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTP id 4D9B637C00Cfor ; Tue, 12 Jun 2007 20:43:41 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 20:47:50 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Jun 2007 20:44:28 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601893453@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing [Redirect-Host-Cache-Time] to [ Redirect-Max-Cache-Time ] thread-index: AcetBF7qDFieiPv0TbuzfZe9jxtiEw== From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 12 Jun 2007 15:17:50.0318 (UTC) FILETIME=[D71328E0:01C7AD04] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.5213 TC:1F TRN:53 TV:3.6.1039(15232.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.4 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [Dime] Changing [Redirect-Host-Cache-Time] to [ Redirect-Max-Cache-Time ] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1764502551==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1764502551== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AD04.67D4BCB9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AD04.67D4BCB9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I went through the updated 3588 draft in http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt=20 I find [Redirect-Host-Cache-Time] AVP used for the RAA I think it should be=20 [Redirect-Max-Cache-Time](Correct me if I'm wrong) Please update the new draft removing the typo Error. Thx -Arun =20 =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7AD04.67D4BCB9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi=
 Victor,
        I went=
 through the updated 3588 draft in http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt=
 
        I=
 find [Redirect-Host-Cache-Time] AVP used for the RAA I think it should be=
 
        [Redi=
rect-Max-Cache-Time](Correct me if I’m=
 wrong)
        Please=
 update the new draft removing the typo=
 Error.
Thx
-Arun
      =

 

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7AD04.67D4BCB9-- --===============1764502551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1764502551==-- From dime-bounces@ietf.org Tue Jun 12 14:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBOe-0001YI-RQ; Tue, 12 Jun 2007 14:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyBOe-0001Qy-1b for dime@ietf.org; Tue, 12 Jun 2007 14:47:16 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyBOc-0007ZF-Ks for dime@ietf.org; Tue, 12 Jun 2007 14:47:16 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5CIkijH051922; Tue, 12 Jun 2007 14:46:44 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <466EEA13.9080302@tari.toshiba.com> Date: Tue, 12 Jun 2007 14:46:43 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: "Arun Santhanam, TLS-Chennai" Subject: Re: [Dime] Changing [Redirect-Host-Cache-Time] to [ Redirect-Max-Cache-Time ] References: <66E8AEE9980BB44CA5FCAD39EBA56AC601893453@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601893453@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l5CIkijH051922 X-Spam-Score: -2.4 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Arun, > Hi Victor, > I went through the updated 3588 draft in http://www.ietf.org/in= ternet-drafts/draft-ietf-dime-rfc3588bis-04.txt =20 > I find [Redirect-Host-Cache-Time] AVP used for the RAA I think = it should be=20 > [Redirect-Max-Cache-Time](Correct me if I=92m wrong) > Please update the new draft removing the typo Error. Ok. Thanks. - victor > Thx > -Arun > =20 > > DISCLAIMER: > -----------------------------------------------------------------------= ------------------------------------------------ > > The contents of this e-mail and any attachment(s) are confidential and=20 > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its=20 > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily=20 > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure,=20 > modification, distribution and / or publication of > this message without the prior written consent of the author of this=20 > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender=20 > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > -----------------------------------------------------------------------= ------------------------------------------------ > > -----------------------------------------------------------------------= - > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 13 06:30:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyQ7k-0004Yw-AQ; Wed, 13 Jun 2007 06:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyQ7i-0004YO-Rj for dime@ietf.org; Wed, 13 Jun 2007 06:30:46 -0400 Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyQ7g-0002Td-OU for dime@ietf.org; Wed, 13 Jun 2007 06:30:46 -0400 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id l5DAXthe001406 for dime@ietf.org; Wed, 13 Jun 2007 13:33:55 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id l5DAXtBw001400 for ; Wed, 13 Jun 2007 13:33:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Jun 2007 13:30:09 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: delete request action in PendingE Thread-Index: AcetpdFXbGFLPtpMSNeBz1h6Qk1yBA== From: "Dmitriy Mermelstein" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Subject: [Dime] delete request action in PendingE X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1201181038==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1201181038== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ADA5.E2B9E4D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADA5.E2B9E4D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I implement the Diameter Credit-Control Application state machine (RFC 4006). My question is related to CLIENT, EVENT BASED use case, specially to the delete request action in PendingE is described below. =20 PendingE Failed CC event answer Indicate Idle received; requested service action REFUND_ACCOUNT error and delete request =20 In order to delete the request it is needed to be stored previously. Each time when the request is being to store, the state is changing to IDLE. Therefore the request is not to be deleted in PendingE. Along with it the delete request may be executed in PendingB state after sending of the stored request. =20 Please comment. =20 Thanks in advance, Dmitriy =20 =20 ------_=_NextPart_001_01C7ADA5.E2B9E4D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I implement the Diameter Credit-Control Application state machine (RFC = 4006).

My question is related to = CLIENT, EVENT BASED use case, specially to the delete request action in PendingE = is described below.

 

PendingE   &n= bsp;  Failed CC event answer         = Indicate      Idle

    &nbs= p;         =       received; requested   =             s= ervice

    &nbs= p; =             &= nbsp; action REFUND_ACCOUNT   error and

    &nbs= p;            = ;  =             &= nbsp;           &n= bsp;           &nb= sp;        delete request

 

In order to delete the = request it is needed to be stored previously.

Each time when the request = is being to store, the state is changing to IDLE.

Therefore the request is = not to be deleted in PendingE.

Along with it the delete = request may be executed in PendingB state after sending of the stored = request.

 

Please = comment.

 

Thanks in = advance,

Dmitriy

 

 

------_=_NextPart_001_01C7ADA5.E2B9E4D0-- --===============1201181038== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1201181038==-- From dime-bounces@ietf.org Wed Jun 13 11:48:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyV55-0007Ie-DY; Wed, 13 Jun 2007 11:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyV54-0007IN-5y for dime@ietf.org; Wed, 13 Jun 2007 11:48:22 -0400 Received: from us-wkf-fwmain.comverse.com ([63.64.185.250] helo=us-wkf-interscan1.comverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyV53-0007ml-FJ for dime@ietf.org; Wed, 13 Jun 2007 11:48:22 -0400 Received: from us-nj-mail1.comverse.com (localhost.localdomain [127.0.0.1]) by us-wkf-interscan1.comverse.com (8.13.1/8.13.1) with ESMTP id l5DFmJBQ007551 for ; Wed, 13 Jun 2007 11:48:20 -0400 X-Authentication-Warning: us-wkf-interscan1.comverse.com: iscan owned process doing -bs X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Jun 2007 11:48:13 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on rfc3588bis ACR definition Thread-Index: Acet0kAwUmsXLDsSTmyVu9G0h6t6/Q== From: "Daily William" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Subject: [Dime] Comment on rfc3588bis ACR definition X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1428177919==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1428177919== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ADD2.6687E73D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADD2.6687E73D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Victor Fajardo, First, thank you for all your efforts in shepherding the rfc3588 bis project and please excuse me for not making this observation earlier. I would like to ask about an apparent inconsistency in the rfc3855bis, which also happens to exist in the original RFC 3588. =20 For reference, I have included the definition of the Account-Request ABNF in section 9.7.1 is as follows: ::=3D < Diameter Header: 271, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Accounting-Record-Type } { Accounting-Record-Number } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Accounting-Sub-Session-Id ] [ Acct-Session-Id ] [ Acct-Multi-Session-Id ] [ Acct-Interim-Interval ] [ Accounting-Realtime-Required ] [ Origin-State-Id ] [ Event-Timestamp ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] The AVP table for ACR from section 10.2 includes an entry for the AVP Destination-Host and states that zero or one occurrence for ACR is supported, however the ABNF for the ACR message does not include the same AVP as optional. Likewise the AVP Terminate-Cause is also listed in the table from 10.2 as 0-1 and it does not appear in the ABNF for neither ACR nor ACA. Would you consider this correct? Perhaps someone could provide some clarification?=20 For what it is worth I would like to propose that the ABNF for ACR and ACA be updated to be consistent with the table. I believe Destination-Host is a useful AVP when the Accounting session extends over several Diameter transactions. Adding it as an optional AVP would be backward compatible and consistent with the original specification because ACR and ACA includes the any AVP syntax (*[AVP]). Best regards, Bill Daily Comverse, Inc; ------_=_NextPart_001_01C7ADD2.6687E73D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comment on rfc3588bis ACR definition

Dear Victor Fajardo,

First, thank you for all your = efforts in shepherding the rfc3588 bis = project and please excuse me for = not making this observation earlier.

I would like to ask about an apparent = inconsistency in the rfc3855bis, which also happens to exist = in the original RFC 3588. 

For reference, I have = included the definition of the Account-Request = ABNF = in section 9.7.1 is as follows:

         = <ACR> ::=3D < Diameter Header: 271, REQ, PXY = >

         &nbs= p;         < Session-Id = >

         &nbs= p;         { Origin-Host = }

         &nbs= p;         { Origin-Realm = }

         &nbs= p;         { Destination-Realm = }

         &nbs= p;         { = Accounting-Record-Type }

         &nbs= p;         { = Accounting-Record-Number }

         &nbs= p;         [ Acct-Application-Id = ]

         &nbs= p;         [ = Vendor-Specific-Application-Id ]

         &nbs= p;         [ User-Name = ]

         &nbs= p;         [ = Accounting-Sub-Session-Id ]

         &nbs= p;         [ Acct-Session-Id = ]

         &nbs= p;         [ = Acct-Multi-Session-Id ]

         &nbs= p;         [ = Acct-Interim-Interval ]

         &nbs= p;         [ = Accounting-Realtime-Required ]

         &nbs= p;         [ Origin-State-Id = ]

         &nbs= p;         [ Event-Timestamp = ]

         &nbs= p;       * [ Proxy-Info = ]

         &nbs= p;       * [ Route-Record = ]

         &nbs= p;       * [ AVP ]

The AVP table for ACR = from = section 10.2 includes an = entry for the AVP Destination-Host and states that zero or = one occurrence for ACR is supported, however the ABNF for the ACR message does not = include = the same AVP as optional.  Likewise the AVP = Terminate-Cause is also listed in the table from 10.2 as 0-1 and it does not appear in the ABNF = for neither ACR nor = ACA.

Would = you consider this correct?  Perhaps someone could provide some = clarification?

For what it is worth I would like to propose = that the ABNF for ACR and ACA be updated to be consistent with the = table.  I believe = Destination-Host is a useful AVP when the Accounting session extends = over several Diameter transactions.  Adding it as an optional AVP would be backward compatible = and consistent with the original specification because ACR and ACA includes the any AVP syntax = (*[AVP]).

Best = regards,

Bill = Daily

Comverse, Inc;

------_=_NextPart_001_01C7ADD2.6687E73D-- --===============1428177919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1428177919==-- From dime-bounces@ietf.org Wed Jun 13 12:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVWX-00074o-58; Wed, 13 Jun 2007 12:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVWW-00074j-Uf for dime@ietf.org; Wed, 13 Jun 2007 12:16:44 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyVWV-00058G-LU for dime@ietf.org; Wed, 13 Jun 2007 12:16:44 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5DGGLxh056331; Wed, 13 Jun 2007 12:16:21 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46701855.30801@tari.toshiba.com> Date: Wed, 13 Jun 2007 12:16:21 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Daily William Subject: Re: [Dime] Comment on rfc3588bis ACR definition References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Daily, > The AVP table for ACR from section 10.2 includes an entry for the AVP > Destination-Host and states that zero or one occurrence for ACR is > supported, however the ABNF for the ACR message does not include the > same AVP as optional. Likewise the AVP Terminate-Cause is also listed > in the table from 10.2 as 0-1 and it does not appear in the ABNF for > neither ACR nor ACA. > > Would you consider this correct? Perhaps someone could provide some > clarification? > > For what it is worth I would like to propose that the ABNF for ACR and > ACA be updated to be consistent with the table. I believe > Destination-Host is a useful AVP when the Accounting session extends > over several Diameter transactions. Adding it as an optional AVP > would be backward compatible and consistent with the original > specification because ACR and ACA includes the any AVP syntax (*[AVP]). > Thanks for noticing this. For Destination-Host, the AVP should be added as an optional to the ABNF of ACR. For Terminate-Cause, this maybe tied to STRs more than anything else so it might best just to fix the occurrence table in this case. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 13 12:42:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVuz-0001v9-Sr; Wed, 13 Jun 2007 12:42:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVuz-0001v3-CD for dime@ietf.org; Wed, 13 Jun 2007 12:42:01 -0400 Received: from us-wkf-fwmain.comverse.com ([63.64.185.250] helo=us-wkf-interscan1.comverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyVuz-0001wc-4P for dime@ietf.org; Wed, 13 Jun 2007 12:42:01 -0400 Received: from us-nj-mail1.comverse.com (localhost.localdomain [127.0.0.1]) by us-wkf-interscan1.comverse.com (8.13.1/8.13.1) with ESMTP id l5DGfwE7009407; Wed, 13 Jun 2007 12:41:59 -0400 X-Authentication-Warning: us-wkf-interscan1.comverse.com: iscan owned process doing -bs X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Comment on rfc3588bis ACR definition Date: Wed, 13 Jun 2007 12:41:52 -0400 Message-ID: In-Reply-To: <46701855.30801@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comment on rfc3588bis ACR definition Thread-Index: Acet1lrSOsrAqqe4RDO3bUaBq32FqQAACrsw References: <46701855.30801@tari.toshiba.com> From: "Daily William" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, I am glad you agree that the Destination-Host AVP should be added to the ABNF for ACR. I believe that this is quite useful. For the Terminate-Cause AVP I have no real opinion about the nature of this AVP and defer to your suggestion to update the table. =20 I would, however, like to make the following observation. I think that it is reasonable for accounting systems to capture session information similar to the cause of termination in call records, along with lots of other data. As an example, the 3GPP Accounting application solves this with the use of Vender specific AVPs.=20 So, perhaps, this is the best practice going forward and tends to support the suggestion that there is no need for the Termination-Cause AVP in ACR. Many thanks, Bill -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Wednesday, June 13, 2007 12:16 PM To: Daily William Cc: dime@ietf.org Subject: Re: [Dime] Comment on rfc3588bis ACR definition Hi Daily, > The AVP table for ACR from section 10.2 includes an entry for the AVP=20 > Destination-Host and states that zero or one occurrence for ACR is=20 > supported, however the ABNF for the ACR message does not include the=20 > same AVP as optional. Likewise the AVP Terminate-Cause is also listed > in the table from 10.2 as 0-1 and it does not appear in the ABNF for=20 > neither ACR nor ACA. > > Would you consider this correct? Perhaps someone could provide some=20 > clarification? > > For what it is worth I would like to propose that the ABNF for ACR and > ACA be updated to be consistent with the table. I believe=20 > Destination-Host is a useful AVP when the Accounting session extends=20 > over several Diameter transactions. Adding it as an optional AVP=20 > would be backward compatible and consistent with the original=20 > specification because ACR and ACA includes the any AVP syntax (*[AVP]). > Thanks for noticing this. For Destination-Host, the AVP should be added=20 as an optional to the ABNF of ACR. For Terminate-Cause, this maybe tied=20 to STRs more than anything else so it might best just to fix the=20 occurrence table in this case. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 13 17:35:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaVO-0001tY-UE; Wed, 13 Jun 2007 17:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaVO-0001tT-2m for dime@ietf.org; Wed, 13 Jun 2007 17:35:54 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HyaVM-0006kd-Gb for dime@ietf.org; Wed, 13 Jun 2007 17:35:54 -0400 Received: (qmail invoked by alias); 13 Jun 2007 21:35:51 -0000 Received: from p54985540.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.85.64] by mail.gmx.net (mp001) with SMTP; 13 Jun 2007 23:35:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xx/l5wrEx73dZI8oHIepIR472AY0acTJhSjzrnr /iVG5ZAmeXg7eZ Message-ID: <46706335.7000507@gmx.net> Date: Wed, 13 Jun 2007 23:35:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Dime] Registering new Command Codes with IANA based on "Expert Review" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, RFC 3588 describes that "IETF Consensus" is needed when registering a new Command Code with IANA. That's fine if you develop a specification in the IETF. It is, however, challenging when another SDOs extend Diameter but don't want todo this within the IETF itself. What they then do is to avoid creating a command code (and applications in general) but re-using existing applications, such as Diameter NASREQ, and adding vendor-specific AVPs. As one might guess the consequence is a hack. This can lead to interoperability problems. Now, in a chat between Dan, Victor and myself we thought about ways how to change the current situation. We would like to have other SDOs to extend Diameter in such a way that it does not cause interoperability problems. One way is to improve the current situation is to change the policy for registering Command Codes from "IETF Consensus" to "Expert Review" (as part of the work on http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt). This would obviously require that we setup a expert review team in order to actually handle the incoming review requests. What do people think about the suggested change? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 13 17:43:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyaco-0000OY-2J; Wed, 13 Jun 2007 17:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyacn-0000OQ-An for dime@ietf.org; Wed, 13 Jun 2007 17:43:33 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyacn-0000HO-24 for dime@ietf.org; Wed, 13 Jun 2007 17:43:33 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l5DLhVd1016704; Wed, 13 Jun 2007 17:43:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Registering new Command Codes with IANA based on "ExpertReview" Date: Wed, 13 Jun 2007 17:43:30 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7187F90@sonusmail04.sonusnet.com> In-Reply-To: <46706335.7000507@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Registering new Command Codes with IANA based on "ExpertReview" Thread-Index: AceuAtVFvI8HVpvuSByYxOK84JNqiwAAHAmA References: <46706335.7000507@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I think it really would be useful to prevent people hacking existing commands. It may be also considered to signal that a command code is not from IANA assigned name space with a new AVP (whose values are controlled by IANA, and is assigned per organization). The absence of this AVP would mean that the command code is from IANA name space. Organizations would be able to assign new command codes the way they want in their own name space. This would be similar to the Vendor-Id field in an AVP. Just a thought .... Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, June 13, 2007 5:36 PM > To: dime@ietf.org > Subject: [Dime] Registering new Command Codes with IANA based on > "ExpertReview" >=20 > Hi all, >=20 > RFC 3588 describes that "IETF Consensus" is needed when registering a > new Command Code with IANA. That's fine if you develop a specification > in the IETF. > It is, however, challenging when another SDOs extend Diameter but don't > want todo this within the IETF itself. What they then do is to avoid > creating a command code (and applications in general) but re-using > existing applications, such as Diameter NASREQ, and adding > vendor-specific AVPs. As one might guess the consequence is a hack. This > can lead to interoperability problems. >=20 > Now, in a chat between Dan, Victor and myself we thought about ways how > to change the current situation. We would like to have other SDOs to > extend Diameter in such a way that it does not cause interoperability > problems. One way is to improve the current situation is to change the > policy for registering Command Codes from "IETF Consensus" to "Expert > Review" (as part of the work on > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt). > This would obviously require that we setup a expert review team in order > to actually handle the incoming review requests. >=20 > What do people think about the suggested change? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 13 18:08:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyb0w-00019L-49; Wed, 13 Jun 2007 18:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyb0v-00019B-I0 for dime@ietf.org; Wed, 13 Jun 2007 18:08:29 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hyb0t-0006fi-K2 for dime@ietf.org; Wed, 13 Jun 2007 18:08:29 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1181772506!1556539!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3341 invoked from network); 13 Jun 2007 22:08:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 13 Jun 2007 22:08:26 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5DM8QIc016964 for ; Wed, 13 Jun 2007 15:08:26 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5DM8PXF005945 for ; Wed, 13 Jun 2007 17:08:26 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5DM8O0G005936 for ; Wed, 13 Jun 2007 17:08:25 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2007 18:08:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: First draft on the integration of QoS application thread-index: AcetISvGTMneLoT9RHySt6sElj/kSQADAwBAAAQSw0AAIhfZoAAA/rRwAAA4YPAAALX/UAAEvulgAAHFv2AAAzbrgAAEo/mQ From: "McCann Peter-A001034" To: X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Subject: [Dime] FW: First draft on the integration of QoS application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Below is a discussion thread that has been taking place among authors of the diameter-qos draft. We thought it important that the mailing list have some visibility to the discussion. Comments welcome. -Pete McCann Peter-A001034 wrote: > Hi, Dong, >=20 > I guess I don't see why we need two separate interfaces. They are > each transporting roughly the same information and doing the same > sort of job. =20 >=20 > The current document in my mind has always been an inter-domain > interface. See the abstract:=20 >=20 > ...Clients that implement the Diameter QoS application contact an > authorizing entity/application server that is located somewhere in > the network, allowing for a wide variety of flexible deployment > models. >=20 > And the following text in Section 3.2: >=20 > Inter-domain support >=20 > In particular, users may roam outside their home network, > leading to a situation where the network element and > authorizing entity are in different administrative domains. >=20 > -Pete >=20 > Sun, Dong (Dong) wrote: >> Hi Pete, >> I have no doubt about the importance of inter-domain policy >> communications, and it might be better to use the Diameter broker >> instead of SIP proxy to deal with inter-domain resource management. >> In fact, I think 3GPP does use the similar model as you described, >> that a Diameter broker (client) is embedded in the AF (e.g. P-CSCF), >> and the interface between AF and underlying Policy engine (e.g. PCRF) >> is an inter-domain interface per se. certainly, since they (SIP and >> Diameter brokers) are grouped together, it is less flexible and >> scalable for the implementation. >>=20 >> However, I think this interface (named as Rx in 3GPP, Gq' in TISPAN, >> Rs in ITU) is not for the control of policy enforcement directly. In >> my view, this interface (Rx) is a peering interface between policy >> servers rather than between policy server and enforcement point as >> described in the current QoS application, and I believe it is more >> appropriate to model the inter-domain interface as the policy server >> to policy server (PDF-PDF) peering interface. >>=20 >> I have no problem to develop a doc to address this inter-domain >> application, however, if you look around the current document, I did >> not see any indication from that perspective. >>=20 >> Dong >>=20 >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Wednesday, June 13, 2007 2:11 PM >> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina TSOU; >> Avri Doria Cc: Victor Fajardo >> Subject: RE: First draft on the integration of QoS application >>=20 >> Hi, Dong, >>=20 >> Sun, Dong (Dong) wrote: >>> Hi Pete, >>>=20 >>> Thanks for clarification. Just wondering if you can give an example >>> who will use the "inter-domain" model for policy enforcement >>> control, i.e. PDP and PEP reside in the different operator's >>> administrative domains. Since the inter-domain is to serve for the >>> operator's domain, I don't know how to create an application >>> without considering their need. (BTW, I have no strong view to >>> limit it to intra-domain only if the use case can be identified). >>=20 >> Arbitrary third parties should be allowed to deploy application >> servers and interface to the Diameter cloud to get QoS from the >> network. The Diameter QoS Application should play this role. >> In the extreme case, I should be allowed to put a SIP server in my >> basement, sign up with a Diameter broker, and run my application >> end-to-end.=20 >>=20 >>> I agree that this application should support "a generic mediator >>> that can handle many applications". However, Given the integrated >>> AS and AE, it makes the AE has to be collocated with the >>> application content providers rather than the network itself, I >>> feel it is also too limited and not the common case in reality. (As >>> far as I know, all deployed or emerging network infrastructures >>> such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view this solution as >>> the main trend). I am wondering who will use this application >>> eventually.=20 >>=20 >> I am not ruling out a PDP in the network local to the PEP. I am just >> saying that this PDP should be viewed as a Diameter proxy on the path >> to the Authorizing Entity, which itself may be either a static >> subscriber database or an active application server. >> I don't want to work only on the localized protocol, I want to define >> the inter-domain one. If you insist on separating the AE from the AS >> then I would say that the important Diameter interface is the one >> between AE and AS. It is much more important to standardize the >> inter-domain interface because this is the one that will be used >> between operators.=20 >>=20 >> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they are >> going down the path of using SIP proxies as the inter-domain >> interface. I think this architecture is bad for the Internet, and >> will limit the kinds of applications that can be deployed. >> The Internet model is that applications should be deployable without >> modifying the middleboxes. Tying SIP servers to the network traffic >> path also doesn't work well with Mobile IP. >>=20 >>> In addition, the scalable roaming agreements sound like a general >>> algorithm that may be applicable for any inter-domain issue in the >>> context of Diameter applications, or it is only the fundament to >>> this application? >>=20 >> The Diameter NASREQ application (similar to the basic RADIUS >> protocol) has always been about inter-domain operation. Diameter is >> used as the mediating protocol between different operator domains. I >> think we should be following the same model with the Diameter QoS >> application.=20 >>=20 >> -Pete >>=20 >>> Dong >>>=20 >>> -----Original Message----- >>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>> Sent: Wednesday, June 13, 2007 11:06 AM >>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the >>> integration of QoS application=20 >>>=20 >>> Hi, Dong, >>>=20 >>> An "Autonomous System" has a very specific meaning in the context of >>> routing protocols; I would not want to say that they correspond >>> one-to-one with the "domains" that exist when I talk about >>> "inter-domain" in the context of diameter-qos. I would say that >>> "operator's administrative domain" is a better term. >>>=20 >>> In any case, I think that the Diameter cloud from the figure 1 >>> should be a generic inter-domain mediator that can handle many >>> applications, of which Diameter QoS is one. The scalable roaming >>> agreements embodied in this cloud should allow the Authorizing >>> Entity to be anywhere in the network. There may be proxies in the >>> Diameter cloud that enforce their own policy decisions, some of >>> which will be local to the Network Element's administrative domain. >>> However, that should not impact the specification of the Diameter >>> QoS Application. This inter-domain operation has been at the core >>> of the document since I started it: see Section 3.2 in the -00 >>> version.=20 >>>=20 >>> -Pete >>>=20 >>> Sun, Dong (Dong) wrote: >>>> Hi Pete, >>>>=20 >>>> Before making any conclusion, I'd like to clarify some terms: >>>> Since you mentioned this is IETF, Internet and such, the domain you >>>> refer to is in the context of the "Autonomous System" or >>>> "operator's administrative domain".=20 >>>>=20 >>>> Dong >>>>=20 >>>> -----Original Message----- >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>> Sent: Wednesday, June 13, 2007 10:27 AM >>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the >>>> integration of QoS application >>>>=20 >>>> Hi, Dong, >>>>=20 >>>> I think you and I have a fundamental disagreement on the scope and >>>> purpose of this document. I really don't see the need to >>>> standardize >>=20 >>>> an intra-domain localized solution to the problem. This is IETF we >>>> should be solving the problem for the whole Internet, which means >>>> inter-domain is the target. I understand that some operators might >>>> not want to open their networks, but we should not be defining >>>> standards for these closed architectures. >>>>=20 >>>> I also feel strongly that we should have adequate discovery >>>> mechanisms >>>=20 >>>> for all modes of operation specified in this document; otherwise it >>>> could lead to inter-operability problems. >>>>=20 >>>> Hannes, I would like to note this as a serious issue that should be >>>> resolved before we proceed any further. I would like to check with >>>> the mailing list and the ADs on their preferences. What do you >>>> think >>=20 >>>> would be the appropriate way to introduce the issue? Would you >>>> like to introduce the question to the mailing list? >>>>=20 >>>> -Pete >>>>=20 >>>> Sun, Dong (Dong) wrote: >>>>> Hi Pete, >>>>>=20 >>>>> First of all, Thanks for the review and comments. >>>>>=20 >>>>> 1. Concerning the split of Application Server and Authorizing >>>>> Entity, >>>=20 >>>>> which is somewhat related to another main comment you brought up >>>>> i.e. the relationship between Authorizing Entity and NE - >>>>> inter-domain Vs. intra-domain, the rationale in my mind is as >>>>> follow: - In the real network (or the vision of NGN, or somewhat >>>>> the >>=20 >>>>> net neutrality perspective), the packet (transport) network should >>>>> support >>>>=20 >>>>> a variety of applications which may belong to different SPs i.e. >>>>> in different domain. The PDP (i.e. Authorizing entity in the >>>>> context of >>=20 >>>>> QoS application) can act as the arbitrator to isolate the >>>>> diversity of application attributes from the speciality of network >>>>> functionality. The authorizing entity is typically part of >>>>> transport >>=20 >>>>> network domain along with the NEs since the network operators are >>>>> commonly willing to >>>>=20 >>>>> neither rely on the third party to control the use of their >>>>> network resources nor disclose the network details (e.g. >>>>> topology, resource usage and policies) to other carriers/SPs. >>>>> Therefore, the common case is that the interface between >>>>> Authorizing entity and NE (enforcement point) should be >>>>> intra-domain in nature.=20 >>>>>=20 >>>>> - On the other hand, the interface between AS and AE can be >>>>> inter-domain, which also makes the life easier concerning the >>>>> inter-domain enforcement interface. >>>>>=20 >>>>> - The policy communications between different domains is quite >>>>> important, for example, for the roaming scenario. However, it is >>>>> outside the scope of this application if my understanding is >>>>> correct. I feel it is better to be solved through >>>>> inter-Authorizing Entity interface rather than this interface. >>>>> Certainly, the command and AVPs >>>=20 >>>>> might be shared, but I would rather not mix them together for the >>>>> time being.=20 >>>>>=20 >>>>> 2. Concerning the discovery mechanism for Push mode, I agree that >>>>> it >>=20 >>>>> is a tricky issue and also support to describe the issue in the >>>>> document. However, I'd like to point out, this document should >>>>> concentrate on the protocol related issue and allow the >>>>> flexibility to use the other discovery mechanism beyond the >>>>> Diameter protocol capability. In other words, we mainly need to >>>>> define some mechanism based on Diameter protocol's capability, >>>>> such as the realm based routing, and leave the door open for >>>>> other advanced discovery schemes.=20 >>>>>=20 >>>>> See additional comment in line... >>>>>=20 >>>>> Regards, >>>>> Dong >>>>>=20 >>>>> -----Original Message----- >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>> Sent: Tuesday, June 12, 2007 5:26 PM >>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina >>>>> TSOU; >>=20 >>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the >>>>> integration of QoS application >>>>>=20 >>>>> Hi, all, >>>>>=20 >>>>> Please see my comments in line. >>>>>=20 >>>>> Hannes Tschofenig wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> could you please take a look at the proposal by Dong? >>>>>>=20 >>>>>> They are available here: >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >> http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft >> -i >>>>> etf-dime-diameter-qos-01-ds.txt >>>>>>=20 >>>>>> The XML file is in the same directory, as usual. >>>>>>=20 >>>>>> Ciao >>>>>> Hannes >>>>>>=20 >>>>>> Sun, Dong (Dong) wrote: >>>>>>> Hi Hannes et al, >>>>>>>=20 >>>>>>> Attached is the first cut to integrate two I-Ds. The change is a >>>>>>> minimum set based on the comments from the exploder (Tina, >>>>>>> Christian >>>>=20 >>>>>>> and Tolga). There are some open issues to be done, I'd like to >>>>>>> get >>=20 >>>>>>> your comments on changes first and discuss how to proceed on >>>>>>> those >>=20 >>>>>>> open items before making any further editings. Main changes: >>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push modes >>>>>=20 >>>>> In the definition of Pull mode, the following sentence >>>>> The Authorizing Entity then installs the QoS >>>>> authorization decision to the Network Element initiatively. >>>>> needs work. "initiatively" is not a word. >>>>>=20 >>>>> [DS] ok. Any good word? Basically I don't like some words such as >>>>> unsolicited since it is used by 3GPP for different meaning. Maybe >>>>> "directly" instead?=20 >>>>>=20 >>>>>>> 2. section 3.1/2: modify the architecture diagram to separate >>>>>>> the Authorizing Entity from AS (further alignment is needed in >>>>>>> the context); and add new subsections to addressing the endpoint >>>>>>> features >>>>>=20 >>>>>>> and push/pull modes. >>>>>=20 >>>>> Breaking up the AS and AE implies that there will be another >>>>> interface >>>>=20 >>>>> yet to be defined. I would rather not open up this possibility. >>>>> The >>>=20 >>>>> Diameter QoS application should be usable all the way from network >>>>> element to application server, perhaps passing through an >>>>> arbitrary number of proxies that enforce their own policies, but >>>>> there should be >>>>=20 >>>>> 1 interface not 2. Also, it is important to note that the AS need >>>>> not >>>>=20 >>>>> be present at all in some >>>>> scenarios: for example, when authorizing requests from a static >>>>> subscriber database.=20 >>>>>=20 >>>>> [DS] First of all, I don't intend to standardize the interface >>>>> between >>>>=20 >>>>> AS and AE in this application. Second, I am not sure why the >>>>> separate >>>=20 >>>>> of AS and AE prevents the AE access to a static subscriber >>>>> database. The basic rationale is address as aforementioned. >>>>>=20 >>>>>>> 3. section 3.3: minor revision on the models for pull; rewrite >>>>>>> the >>=20 >>>>>>> push model (Tina, pls take a look) >>>>>=20 >>>>> 3.2 looks new. It seems to be overly weighted in favor of the >>>>> push model. I would like to point out that there is a big >>>>> discovery problem with the push model, especially when the AE and >>>>> NE are in different administrative domains. The push model is >>>>> only applicable >>=20 >>>>> to the case where the AE and the NE are in the same administrative >>>>> domain and therefore it is a special case. >>>>>=20 >>>>> [DS] I think in reality the operators mainly look at the >>>>> intra-domain >>>=20 >>>>> policy enforcement interface, whatever pull or push models. I am >>>>> not >>=20 >>>>> in favor of any specific models, just analyze the impact of >>>>> endpoint's >>>>=20 >>>>> capability. If you have any words that can enhance the pull model, >>>>> it >>>=20 >>>>> is very welcome :-). >>>>>=20 >>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section >>>>>>> 7.4 and >>>>>=20 >>>>>>> table. But the name still remains in some texts. >>>>>>>=20 >>>>>>> To be done: >>>>>>> 1. state mechanism for Push mode: server initiated policy >>>>>>> installation 2. should section 4.4 be merged with section 4.2 >>>>>>> since >>>=20 >>>>>>> both them discuss how to initiate a new Diameter session? In >>>>>>> addition, the text needs to be beefed up for server initiated >>>>>>> session.=20 >>>>>>> 3. authorization schemes/models for Pull: inter-domain >>>>>>> authorization >>>>=20 >>>>>>> between authorizing entity and NE is not envisaged as the basic >>>>>>> model, should be revised in the context; Token based approach is >>>>>>> not >>>>=20 >>>>>>> the main trend, should be shortened. >>>>>=20 >>>>> We need to have inter-domain authorization as the basic scenario; >>>>> local authorization should be treated as a special case. The >>>>> whole point is to leverage the inter-domain capability of >>>>> Diameter to mediate between network elements and authorizing >>>>> entities, whether the AEs are application servers or static >>>>> subscriber databases.=20 >>>>>=20 >>>>> [DS] I agree that inter-domain authorization/policy communication >>>>> is >>=20 >>>>> important, but the mechanism and scope of this document is >>>>> inappropriate to solve that issue, since it is not the right way >>>>> forward envisioned by the industry and operators. >>>>>=20 >>>>> If we only solve the local case it will mean that an application >>>>> server has to be co-located in the local domain. This is not the >>>>> way >>>=20 >>>>> the Internet is supposed to work: services should be deployable >>>>> end-to-end, without modifying elements of the network along the >>>>> path. It should be possible for the application server to be >>>>> located >>=20 >>>>> anywhere in the network and the AAA part should just work. >>>>>=20 >>>>> [DS] as I said, the AS and AE can be in different domains. On the >>>>> other hand, if we integrate the AS with AE together, it impose a >>>>> tight >>>>=20 >>>>> coupled service model, i.e. AS and AE always have to be in the >>>>> same domain. Exactly the issue you are concerned. >>>>>=20 >>>>>>> 4. The current doc mainly talks about the QoS, should add some >>>>>>> tint >>>=20 >>>>>>> on the policy control side. >>>>>>>=20 >>>>>>> Please let me know your opinion and how to proceed. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Dong >>>>>=20 >>>>> -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 14 03:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyk2z-00069j-L5; Thu, 14 Jun 2007 03:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyk2x-00069R-Et for dime@ietf.org; Thu, 14 Jun 2007 03:47:11 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyk2x-0000hD-3z for dime@ietf.org; Thu, 14 Jun 2007 03:47:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Registering new Command Codes with IANA based on "ExpertReview" Date: Thu, 14 Jun 2007 03:47:06 -0400 Message-ID: In-Reply-To: <46706335.7000507@gmx.net> References: <46706335.7000507@gmx.net> From: "Mark Jones" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, I agree with your assessment of the SDO situation and that we need to revisit the assignment rules. Why are vendor-specific application ids assigned on a 'First Come First Served' basis whereas new vendor-specific commands within that application require 'IETF Consensus'? Why not subdivide the Command Code namespace (like the application id) to allow a vendor-specific range that is also allocated by IANA on a 'First Come First Served' basis? Thanks Mark > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: June 14, 2007 04:36 > To: dime@ietf.org > Subject: [Dime] Registering new Command Codes with IANA based=20 > on "ExpertReview" >=20 > Hi all, >=20 > RFC 3588 describes that "IETF Consensus" is needed when registering a=20 > new Command Code with IANA. That's fine if you develop a=20 > specification=20 > in the IETF. > It is, however, challenging when another SDOs extend Diameter=20 > but don't=20 > want todo this within the IETF itself. What they then do is to avoid=20 > creating a command code (and applications in general) but re-using=20 > existing applications, such as Diameter NASREQ, and adding=20 > vendor-specific AVPs. As one might guess the consequence is a=20 > hack. This=20 > can lead to interoperability problems. >=20 > Now, in a chat between Dan, Victor and myself we thought=20 > about ways how=20 > to change the current situation. We would like to have other SDOs to=20 > extend Diameter in such a way that it does not cause interoperability=20 > problems. One way is to improve the current situation is to=20 > change the=20 > policy for registering Command Codes from "IETF Consensus" to "Expert=20 > Review" (as part of the work on=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis > -04.txt).=20 > This would obviously require that we setup a expert review=20 > team in order=20 > to actually handle the incoming review requests. >=20 > What do people think about the suggested change? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 14 04:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HykRW-0007vF-Uf; Thu, 14 Jun 2007 04:12:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HykRV-0007tg-AS for dime@ietf.org; Thu, 14 Jun 2007 04:12:33 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HykRS-0007PF-OL for dime@ietf.org; Thu, 14 Jun 2007 04:12:33 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l5E8CQxf024866; Thu, 14 Jun 2007 10:12:27 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l5E8CPcC009587; Thu, 14 Jun 2007 10:12:26 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 10:12:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] Registering new Command Codes with IANA based on"ExpertReview" Date: Thu, 14 Jun 2007 10:11:16 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A4075802148F01@MCHP7IDA.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Registering new Command Codes with IANA based on"ExpertReview" Thread-Index: AceuWD9nClmsSz2mRIGBjP2ZBlQ2nwAAsLiw From: "Tschofenig, Hannes" To: "ext Mark Jones" , "Hannes Tschofenig" X-OriginalArrivalTime: 14 Jun 2007 08:12:14.0216 (UTC) FILETIME=[B732B880:01C7AE5B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mark,=20 It is somewhat strange that the application ids and the command codes have a different policy.=20 I would, however, like to have a model where some Diameter experts could do a brief (e.g., 2 weeks time) review of the suggested extension to check whether the chosen design approach is not violating the Diameter extensibility concept.=20 This review would be based on Diameter extensiblity and not on the actual content of the extension.=20 Ciao Hannes > Hannes, >=20 > I agree with your assessment of the SDO situation and that we need to > revisit the assignment rules. >=20 > Why are vendor-specific application ids assigned on a 'First=20 > Come First > Served' basis whereas new vendor-specific commands within that > application require 'IETF Consensus'? >=20 > Why not subdivide the Command Code namespace (like the application id) > to allow a vendor-specific range that is also allocated by IANA on a > 'First Come First Served' basis? >=20 > Thanks > Mark >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: June 14, 2007 04:36 > > To: dime@ietf.org > > Subject: [Dime] Registering new Command Codes with IANA based=20 > > on "ExpertReview" > >=20 > > Hi all, > >=20 > > RFC 3588 describes that "IETF Consensus" is needed when=20 > registering a=20 > > new Command Code with IANA. That's fine if you develop a=20 > > specification=20 > > in the IETF. > > It is, however, challenging when another SDOs extend Diameter=20 > > but don't=20 > > want todo this within the IETF itself. What they then do is=20 > to avoid=20 > > creating a command code (and applications in general) but re-using=20 > > existing applications, such as Diameter NASREQ, and adding=20 > > vendor-specific AVPs. As one might guess the consequence is a=20 > > hack. This=20 > > can lead to interoperability problems. > >=20 > > Now, in a chat between Dan, Victor and myself we thought=20 > > about ways how=20 > > to change the current situation. We would like to have=20 > other SDOs to=20 > > extend Diameter in such a way that it does not cause=20 > interoperability=20 > > problems. One way is to improve the current situation is to=20 > > change the=20 > > policy for registering Command Codes from "IETF Consensus"=20 > to "Expert=20 > > Review" (as part of the work on=20 > > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis > > -04.txt).=20 > > This would obviously require that we setup a expert review=20 > > team in order=20 > > to actually handle the incoming review requests. > >=20 > > What do people think about the suggested change? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 14 04:33:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyklc-0003cF-I6; Thu, 14 Jun 2007 04:33:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyklb-0003c7-Im for dime@ietf.org; Thu, 14 Jun 2007 04:33:19 -0400 Received: from web90412.mail.mud.yahoo.com ([216.252.100.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HyklZ-0002af-VQ for dime@ietf.org; Thu, 14 Jun 2007 04:33:19 -0400 Received: (qmail 6447 invoked by uid 60001); 14 Jun 2007 08:33:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=v6B3PDtLr0S0wNipS+0h6ksijESEiqCRwbKu/PE7UhpePWeb6thopc9qVReNmXHOyIIwC66HNe8hWGcq1U1Eogfum5oKgGZYFwUPWF/oRhUy5VIdeB0hNww9OwRHUvVpaSXO/LRnGXDtj5i8aWq/o+6ZaBWwfY2KpAKLUIszMi0=; X-YMail-OSG: F0iDDBIVM1k5_AOe6XvxnHSbVlpi6gVWrzSX0Lw7jek2sx77ovyqH1PzB6w.B3sBjmwCpuIQoXdb92JZWHZtZPrX4Jq.8hq48ZGkP_DLNo9_VzVobaGKAOlCksxcZA-- Received: from [125.19.62.252] by web90412.mail.mud.yahoo.com via HTTP; Thu, 14 Jun 2007 01:33:17 PDT Date: Thu, 14 Jun 2007 01:33:17 -0700 (PDT) From: himanshu bahl To: dime@ietf.org, vfajardo@tari.toshiba.com, tasveren@sonusnet.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <576389.5969.qm@web90412.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Dime] Diameter Gk interface. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Can anyone throw some light on the diameter Gk interface ? for example, where it is used and where can one find its specifications ? NOTE : I am not refering to Gq interface. Sincerely, Himanshu. ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 14 06:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HymoQ-0006YP-7y; Thu, 14 Jun 2007 06:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HymoN-0006Uy-Es for dime@ietf.org; Thu, 14 Jun 2007 06:44:20 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HymoM-0004Ti-W9 for dime@ietf.org; Thu, 14 Jun 2007 06:44:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Registering new Command Codes with IANA based on"ExpertReview" Date: Thu, 14 Jun 2007 06:42:39 -0400 Message-ID: In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A4075802148F01@MCHP7IDA.ww002.siemens.net> References: <0D22E3C1A7D7A843B12BF8C6F0A4075802148F01@MCHP7IDA.ww002.siemens.net> From: "Mark Jones" To: "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes,=20 The inconsistency in the assignment rules may be the result of the removal of some vendor-specific features late in the Diameter base protocol design. Once upon a time, the Diameter header contained a vendor id to allow a vendor-specific namespace for commands. I suspect the 'IETF Consensus' rule was originally intended just for the IETF commands. I have concerns about the effectiveness of the 'Expert Review' given the limited success in getting other SDOs to submit to 'IETF Consensus' for new commands. The DIME group may find it can achieve the same interoperability goals by giving the SDOs (and vendors) the tools they need to police their own specifications. The Diameter Applications Design Guidelines draft is an key deliverable in this regard. Once this draft is complete, SDOs creating Diameter applications can encourage/require their working groups to review their specifications against it for compliance. If the Expert Review is the preferred route of this group, we should recognize the importance of effective socialization with the other SDOs to ensure they appreciate its value and understand where it fits in their specification process. Regards Mark > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com]=20 > Sent: June 14, 2007 15:11 > To: Mark Jones; Hannes Tschofenig > Cc: dime@ietf.org > Subject: AW: [Dime] Registering new Command Codes with IANA=20 > based on"ExpertReview" >=20 > Hi Mark,=20 >=20 > It is somewhat strange that the application ids and the command codes > have a different policy.=20 > I would, however, like to have a model where some Diameter=20 > experts could > do a brief (e.g., 2 weeks time) review of the suggested extension to > check whether the chosen design approach is not violating the Diameter > extensibility concept.=20 > This review would be based on Diameter extensiblity and not on the > actual content of the extension.=20 >=20 > Ciao > Hannes >=20 > > Hannes, > >=20 > > I agree with your assessment of the SDO situation and that=20 > we need to > > revisit the assignment rules. > >=20 > > Why are vendor-specific application ids assigned on a 'First=20 > > Come First > > Served' basis whereas new vendor-specific commands within that > > application require 'IETF Consensus'? > >=20 > > Why not subdivide the Command Code namespace (like the=20 > application id) > > to allow a vendor-specific range that is also allocated by IANA on a > > 'First Come First Served' basis? > >=20 > > Thanks > > Mark > >=20 > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > > Sent: June 14, 2007 04:36 > > > To: dime@ietf.org > > > Subject: [Dime] Registering new Command Codes with IANA based=20 > > > on "ExpertReview" > > >=20 > > > Hi all, > > >=20 > > > RFC 3588 describes that "IETF Consensus" is needed when=20 > > registering a=20 > > > new Command Code with IANA. That's fine if you develop a=20 > > > specification=20 > > > in the IETF. > > > It is, however, challenging when another SDOs extend Diameter=20 > > > but don't=20 > > > want todo this within the IETF itself. What they then do is=20 > > to avoid=20 > > > creating a command code (and applications in general) but=20 > re-using=20 > > > existing applications, such as Diameter NASREQ, and adding=20 > > > vendor-specific AVPs. As one might guess the consequence is a=20 > > > hack. This=20 > > > can lead to interoperability problems. > > >=20 > > > Now, in a chat between Dan, Victor and myself we thought=20 > > > about ways how=20 > > > to change the current situation. We would like to have=20 > > other SDOs to=20 > > > extend Diameter in such a way that it does not cause=20 > > interoperability=20 > > > problems. One way is to improve the current situation is to=20 > > > change the=20 > > > policy for registering Command Codes from "IETF Consensus"=20 > > to "Expert=20 > > > Review" (as part of the work on=20 > > > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis > > > -04.txt).=20 > > > This would obviously require that we setup a expert review=20 > > > team in order=20 > > > to actually handle the incoming review requests. > > >=20 > > > What do people think about the suggested change? > > >=20 > > > Ciao > > > Hannes > > >=20 > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 14 14:53:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyuS9-00012P-T7; Thu, 14 Jun 2007 14:53:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyuS8-00011e-Og for dime@ietf.org; Thu, 14 Jun 2007 14:53:52 -0400 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyuS6-0000lC-Rm for dime@ietf.org; Thu, 14 Jun 2007 14:53:52 -0400 Received: by nz-out-0506.google.com with SMTP id z31so630049nzd for ; Thu, 14 Jun 2007 11:53:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Naoo4a9a/mJHD21VCpW+eyg2iJ4ZvZF7wUmxYRWSCic2uQUUIrFhJzTTl2NAvw5V1lVIlo/hPsV/DG7lkLZZ0bI74tVox9eczTys2pTDhWVURG/Vd2HqCGx7HiO7VSgCuYICz/nb/wbG5u1EnjQlcgRUvvEa48gaNtjhyFUoggA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=VuF79mABl8bawHyUOid8L6Rc1FAGgzNk3hghZ7ZB8IkT6DArlBJSlWOCyYbRtEmC4X0tWYAy9jyQzpEhSDLGeed886GahoKzqUV+4RHmSHBeNf23ljWwKGQ6OlyoFjtN6y9fTzMP+G9H4nEd+jx8xnplYwkYclO8KYNA0TbWdp4= Received: by 10.143.45.8 with SMTP id x8mr113000wfj.1181847230081; Thu, 14 Jun 2007 11:53:50 -0700 (PDT) Received: by 10.142.87.10 with HTTP; Thu, 14 Jun 2007 11:53:50 -0700 (PDT) Message-ID: <9b0e41640706141153g677d33e7o6ddb3f53da606939@mail.gmail.com> Date: Thu, 14 Jun 2007 15:53:50 -0300 From: "Christian Esteve" To: dime@ietf.org In-Reply-To: <9b0e41640706141150i640dd29cy89ad225881907627@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9b0e41640706141150i640dd29cy89ad225881907627@mail.gmail.com> X-Google-Sender-Auth: 6ccebf347979f414 X-Spam-Score: 0.0 (/) X-Scan-Signature: e9eeacd7fe925d5f7faae01ed8f85b97 Subject: [Dime] Re: FW: First draft on the integration of QoS application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi folks, the discussion thread reflects once again the confrontation between the operator SDO and the IETF worlds, and as it usually happens, disagreements are not only motivated by network engineering issues but by scope and nomenclature divergences. > > I guess I don't see why we need two separate interfaces. They are > > each transporting roughly the same information and doing the same > > sort of job. It is true that the job and type of infomation are similar, however the separation of the interfaces makes sense to me. While one interface is used only to request QoS, the other is expected to carry and install QoS policy information (with different QoS descriptors). The AF-PDP-PEP model (also referred to as AS-AE-NE) reflects the architecture evolution of the SDOs that introduce policy-based resource control functions. It has been said that: > >>> There may be proxies in the > >>> Diameter cloud that enforce their own policy decisions, some of > >>> which will be local to the Network Element's administrative domain. To my understanding that is why the separated interfaces make sense. An intermediate PDP (also referred to as PDF) may enforce further policies (network type specific, user profile related, operator-based) in conjunction with other network elements (resource information, user database). Furthermore, the QoS description over the AF-PDP interface is likely to differ from the QoS information describing the policy to be instaslled in the NE, harmonizing and easing AF QoS requests and enabling the QoS policy installation mechanism to evolve separately in accordance to the transport network specifics. The PDP would certainly have an inter-domain interface to AFs and other inter- an intra PDPs. I bnelieve that the Diameter QoS application running between the AF and the PDP could be defined in a way that it could be applied for the inter-domain PDP-PDP peering interface. Unfortunately my contribution to the discussion at this point is not enriching the discussion regarding the implications to the Diameter functionality (e.g. command and AVPs, realm routing, discovery schemes, etc.). However, I am sharing under http://www.dca.fee.unicamp.br/~pasquini/dime-qos-app/ some figures depicting the abstracted SDOs architectures that could help in the following discussions around the Diameter QoS application. The figures have been extracted from the the paper "A review on policy-based resource and admission control functions in evolving access and next generation networks", recently accepted for publication (draft copy can be provided if interested). Best regards, Christian > > > > ------------------------------ > > > > Message: 5 > > Date: Wed, 13 Jun 2007 18:08:21 -0400 > > From: "McCann Peter-A001034" > > Subject: [Dime] FW: First draft on the integration of QoS application > > To: > > Message-ID: > > > > Content-Type: text/plain; charset="us-ascii" > > > > Below is a discussion thread that has been taking place > > among authors of the diameter-qos draft. We thought it > > important that the mailing list have some visibility > > to the discussion. Comments welcome. > > > > -Pete > > > > McCann Peter-A001034 wrote: > > > Hi, Dong, > > > > > > I guess I don't see why we need two separate interfaces. They are > > > each transporting roughly the same information and doing the same > > > sort of job. > > > > > > The current document in my mind has always been an inter-domain > > > interface. See the abstract: > > > > > > ...Clients that implement the Diameter QoS application contact an > > > authorizing entity/application server that is located somewhere in > > > the network, allowing for a wide variety of flexible deployment > > > models. > > > > > > And the following text in Section 3.2: > > > > > > Inter-domain support > > > > > > In particular, users may roam outside their home network, > > > leading to a situation where the network element and > > > authorizing entity are in different administrative domains. > > > > > > -Pete > > > > > > Sun, Dong (Dong) wrote: > > >> Hi Pete, > > >> I have no doubt about the importance of inter-domain policy > > >> communications, and it might be better to use the Diameter broker > > >> instead of SIP proxy to deal with inter-domain resource management. > > >> In fact, I think 3GPP does use the similar model as you described, > > >> that a Diameter broker (client) is embedded in the AF (e.g. P-CSCF), > > >> and the interface between AF and underlying Policy engine (e.g. PCRF) > > >> is an inter-domain interface per se. certainly, since they (SIP and > > >> Diameter brokers) are grouped together, it is less flexible and > > >> scalable for the implementation. > > >> > > >> However, I think this interface (named as Rx in 3GPP, Gq' in TISPAN, > > >> Rs in ITU) is not for the control of policy enforcement directly. In > > >> my view, this interface (Rx) is a peering interface between policy > > >> servers rather than between policy server and enforcement point as > > >> described in the current QoS application, and I believe it is more > > >> appropriate to model the inter-domain interface as the policy server > > >> to policy server (PDF-PDF) peering interface. > > >> > > >> I have no problem to develop a doc to address this inter-domain > > >> application, however, if you look around the current document, I did > > >> not see any indication from that perspective. > > >> > > >> Dong > > >> > > >> -----Original Message----- > > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > >> Sent: Wednesday, June 13, 2007 2:11 PM > > >> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina TSOU; > > >> Avri Doria Cc: Victor Fajardo > > >> Subject: RE: First draft on the integration of QoS application > > >> > > >> Hi, Dong, > > >> > > >> Sun, Dong (Dong) wrote: > > >>> Hi Pete, > > >>> > > >>> Thanks for clarification. Just wondering if you can give an example > > >>> who will use the "inter-domain" model for policy enforcement > > >>> control, i.e. PDP and PEP reside in the different operator's > > >>> administrative domains. Since the inter-domain is to serve for the > > >>> operator's domain, I don't know how to create an application > > >>> without considering their need. (BTW, I have no strong view to > > >>> limit it to intra-domain only if the use case can be identified). > > >> > > >> Arbitrary third parties should be allowed to deploy application > > >> servers and interface to the Diameter cloud to get QoS from the > > >> network. The Diameter QoS Application should play this role. > > >> In the extreme case, I should be allowed to put a SIP server in my > > >> basement, sign up with a Diameter broker, and run my application > > >> end-to-end. > > >> > > >>> I agree that this application should support "a generic mediator > > >>> that can handle many applications". However, Given the integrated > > >>> AS and AE, it makes the AE has to be collocated with the > > >>> application content providers rather than the network itself, I > > >>> feel it is also too limited and not the common case in reality. (As > > >>> far as I know, all deployed or emerging network infrastructures > > >>> such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view this solution as > > >>> the main trend). I am wondering who will use this application > > >>> eventually. > > >> > > >> I am not ruling out a PDP in the network local to the PEP. I am just > > >> saying that this PDP should be viewed as a Diameter proxy on the path > > >> to the Authorizing Entity, which itself may be either a static > > >> subscriber database or an active application server. > > >> I don't want to work only on the localized protocol, I want to define > > >> the inter-domain one. If you insist on separating the AE from the AS > > >> then I would say that the important Diameter interface is the one > > >> between AE and AS. It is much more important to standardize the > > >> inter-domain interface because this is the one that will be used > > >> between operators. > > >> > > >> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they are > > >> going down the path of using SIP proxies as the inter-domain > > >> interface. I think this architecture is bad for the Internet, and > > >> will limit the kinds of applications that can be deployed. > > >> The Internet model is that applications should be deployable without > > >> modifying the middleboxes. Tying SIP servers to the network traffic > > >> path also doesn't work well with Mobile IP. > > >> > > >>> In addition, the scalable roaming agreements sound like a general > > >>> algorithm that may be applicable for any inter-domain issue in the > > >>> context of Diameter applications, or it is only the fundament to > > >>> this application? > > >> > > >> The Diameter NASREQ application (similar to the basic RADIUS > > >> protocol) has always been about inter-domain operation. Diameter is > > >> used as the mediating protocol between different operator domains. I > > >> think we should be following the same model with the Diameter QoS > > >> application. > > >> > > >> -Pete > > >> > > >>> Dong > > >>> > > >>> -----Original Message----- > > >>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > >>> Sent: Wednesday, June 13, 2007 11:06 AM > > >>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > > >>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > > >>> integration of QoS application > > >>> > > >>> Hi, Dong, > > >>> > > >>> An "Autonomous System" has a very specific meaning in the context of > > >>> routing protocols; I would not want to say that they correspond > > >>> one-to-one with the "domains" that exist when I talk about > > >>> "inter-domain" in the context of diameter-qos. I would say that > > >>> "operator's administrative domain" is a better term. > > >>> > > >>> In any case, I think that the Diameter cloud from the figure 1 > > >>> should be a generic inter-domain mediator that can handle many > > >>> applications, of which Diameter QoS is one. The scalable roaming > > >>> agreements embodied in this cloud should allow the Authorizing > > >>> Entity to be anywhere in the network. There may be proxies in the > > >>> Diameter cloud that enforce their own policy decisions, some of > > >>> which will be local to the Network Element's administrative domain. > > >>> However, that should not impact the specification of the Diameter > > >>> QoS Application. This inter-domain operation has been at the core > > >>> of the document since I started it: see Section 3.2 in the -00 > > >>> version. > > >>> > > >>> -Pete > > >>> > > >>> Sun, Dong (Dong) wrote: > > >>>> Hi Pete, > > >>>> > > >>>> Before making any conclusion, I'd like to clarify some terms: > > >>>> Since you mentioned this is IETF, Internet and such, the domain you > > >>>> refer to is in the context of the "Autonomous System" or > > >>>> "operator's administrative domain". > > >>>> > > >>>> Dong > > >>>> > > >>>> -----Original Message----- > > >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > >>>> Sent: Wednesday, June 13, 2007 10:27 AM > > >>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > > >>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > > >>>> integration of QoS application > > >>>> > > >>>> Hi, Dong, > > >>>> > > >>>> I think you and I have a fundamental disagreement on the scope and > > >>>> purpose of this document. I really don't see the need to > > >>>> standardize > > >> > > >>>> an intra-domain localized solution to the problem. This is IETF we > > >>>> should be solving the problem for the whole Internet, which means > > >>>> inter-domain is the target. I understand that some operators might > > >>>> not want to open their networks, but we should not be defining > > >>>> standards for these closed architectures. > > >>>> > > >>>> I also feel strongly that we should have adequate discovery > > >>>> mechanisms > > >>> > > >>>> for all modes of operation specified in this document; otherwise it > > >>>> could lead to inter-operability problems. > > >>>> > > >>>> Hannes, I would like to note this as a serious issue that should be > > >>>> resolved before we proceed any further. I would like to check with > > >>>> the mailing list and the ADs on their preferences. What do you > > >>>> think > > >> > > >>>> would be the appropriate way to introduce the issue? Would you > > >>>> like to introduce the question to the mailing list? > > >>>> > > >>>> -Pete > > >>>> > > >>>> Sun, Dong (Dong) wrote: > > >>>>> Hi Pete, > > >>>>> > > >>>>> First of all, Thanks for the review and comments. > > >>>>> > > >>>>> 1. Concerning the split of Application Server and Authorizing > > >>>>> Entity, > > >>> > > >>>>> which is somewhat related to another main comment you brought up > > >>>>> i.e. the relationship between Authorizing Entity and NE - > > >>>>> inter-domain Vs. intra-domain, the rationale in my mind is as > > >>>>> follow: - In the real network (or the vision of NGN, or somewhat > > >>>>> the > > >> > > >>>>> net neutrality perspective), the packet (transport) network should > > >>>>> support > > >>>> > > >>>>> a variety of applications which may belong to different SPs i.e. > > >>>>> in different domain. The PDP (i.e. Authorizing entity in the > > >>>>> context of > > >> > > >>>>> QoS application) can act as the arbitrator to isolate the > > >>>>> diversity of application attributes from the speciality of network > > >>>>> functionality. The authorizing entity is typically part of > > >>>>> transport > > >> > > >>>>> network domain along with the NEs since the network operators are > > >>>>> commonly willing to > > >>>> > > >>>>> neither rely on the third party to control the use of their > > >>>>> network resources nor disclose the network details (e.g. > > >>>>> topology, resource usage and policies) to other carriers/SPs. > > >>>>> Therefore, the common case is that the interface between > > >>>>> Authorizing entity and NE (enforcement point) should be > > >>>>> intra-domain in nature. > > >>>>> > > >>>>> - On the other hand, the interface between AS and AE can be > > >>>>> inter-domain, which also makes the life easier concerning the > > >>>>> inter-domain enforcement interface. > > >>>>> > > >>>>> - The policy communications between different domains is quite > > >>>>> important, for example, for the roaming scenario. However, it is > > >>>>> outside the scope of this application if my understanding is > > >>>>> correct. I feel it is better to be solved through > > >>>>> inter-Authorizing Entity interface rather than this interface. > > >>>>> Certainly, the command and AVPs > > >>> > > >>>>> might be shared, but I would rather not mix them together for the > > >>>>> time being. > > >>>>> > > >>>>> 2. Concerning the discovery mechanism for Push mode, I agree that > > >>>>> it > > >> > > >>>>> is a tricky issue and also support to describe the issue in the > > >>>>> document. However, I'd like to point out, this document should > > >>>>> concentrate on the protocol related issue and allow the > > >>>>> flexibility to use the other discovery mechanism beyond the > > >>>>> Diameter protocol capability. In other words, we mainly need to > > >>>>> define some mechanism based on Diameter protocol's capability, > > >>>>> such as the realm based routing, and leave the door open for > > >>>>> other advanced discovery schemes. > > >>>>> > > >>>>> See additional comment in line... > > >>>>> > > >>>>> Regards, > > >>>>> Dong > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > >>>>> Sent: Tuesday, June 12, 2007 5:26 PM > > >>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina > > >>>>> TSOU; > > >> > > >>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > > >>>>> integration of QoS application > > >>>>> > > >>>>> Hi, all, > > >>>>> > > >>>>> Please see my comments in line. > > >>>>> > > >>>>> Hannes Tschofenig wrote: > > >>>>>> Hi all, > > >>>>>> > > >>>>>> could you please take a look at the proposal by Dong? > > >>>>>> > > >>>>>> They are available here: > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft > > >> -i > > >>>>> etf-dime-diameter-qos-01-ds.txt > > >>>>>> > > >>>>>> The XML file is in the same directory, as usual. > > >>>>>> > > >>>>>> Ciao > > >>>>>> Hannes > > >>>>>> > > >>>>>> Sun, Dong (Dong) wrote: > > >>>>>>> Hi Hannes et al, > > >>>>>>> > > >>>>>>> Attached is the first cut to integrate two I-Ds. The change is a > > >>>>>>> minimum set based on the comments from the exploder (Tina, > > >>>>>>> Christian > > >>>> > > >>>>>>> and Tolga). There are some open issues to be done, I'd like to > > >>>>>>> get > > >> > > >>>>>>> your comments on changes first and discuss how to proceed on > > >>>>>>> those > > >> > > >>>>>>> open items before making any further editings. Main changes: > > >>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push modes > > >>>>> > > >>>>> In the definition of Pull mode, the following sentence > > >>>>> The Authorizing Entity then installs the QoS > > >>>>> authorization decision to the Network Element initiatively. > > >>>>> needs work. "initiatively" is not a word. > > >>>>> > > >>>>> [DS] ok. Any good word? Basically I don't like some words such as > > >>>>> unsolicited since it is used by 3GPP for different meaning. Maybe > > >>>>> "directly" instead? > > >>>>> > > >>>>>>> 2. section 3.1/2: modify the architecture diagram to separate > > >>>>>>> the Authorizing Entity from AS (further alignment is needed in > > >>>>>>> the context); and add new subsections to addressing the endpoint > > >>>>>>> features > > >>>>> > > >>>>>>> and push/pull modes. > > >>>>> > > >>>>> Breaking up the AS and AE implies that there will be another > > >>>>> interface > > >>>> > > >>>>> yet to be defined. I would rather not open up this possibility. > > >>>>> The > > >>> > > >>>>> Diameter QoS application should be usable all the way from network > > >>>>> element to application server, perhaps passing through an > > >>>>> arbitrary number of proxies that enforce their own policies, but > > >>>>> there should be > > >>>> > > >>>>> 1 interface not 2. Also, it is important to note that the AS need > > >>>>> not > > >>>> > > >>>>> be present at all in some > > >>>>> scenarios: for example, when authorizing requests from a static > > >>>>> subscriber database. > > >>>>> > > >>>>> [DS] First of all, I don't intend to standardize the interface > > >>>>> between > > >>>> > > >>>>> AS and AE in this application. Second, I am not sure why the > > >>>>> separate > > >>> > > >>>>> of AS and AE prevents the AE access to a static subscriber > > >>>>> database. The basic rationale is address as aforementioned. > > >>>>> > > >>>>>>> 3. section 3.3: minor revision on the models for pull; rewrite > > >>>>>>> the > > >> > > >>>>>>> push model (Tina, pls take a look) > > >>>>> > > >>>>> 3.2 looks new. It seems to be overly weighted in favor of the > > >>>>> push model. I would like to point out that there is a big > > >>>>> discovery problem with the push model, especially when the AE and > > >>>>> NE are in different administrative domains. The push model is > > >>>>> only applicable > > >> > > >>>>> to the case where the AE and the NE are in the same administrative > > >>>>> domain and therefore it is a special case. > > >>>>> > > >>>>> [DS] I think in reality the operators mainly look at the > > >>>>> intra-domain > > >>> > > >>>>> policy enforcement interface, whatever pull or push models. I am > > >>>>> not > > >> > > >>>>> in favor of any specific models, just analyze the impact of > > >>>>> endpoint's > > >>>> > > >>>>> capability. If you have any words that can enhance the pull model, > > >>>>> it > > >>> > > >>>>> is very welcome :-). > > >>>>> > > >>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section > > >>>>>>> 7.4 and > > >>>>> > > >>>>>>> table. But the name still remains in some texts. > > >>>>>>> > > >>>>>>> To be done: > > >>>>>>> 1. state mechanism for Push mode: server initiated policy > > >>>>>>> installation 2. should section 4.4 be merged with section 4.2 > > >>>>>>> since > > >>> > > >>>>>>> both them discuss how to initiate a new Diameter session? In > > >>>>>>> addition, the text needs to be beefed up for server initiated > > >>>>>>> session. > > >>>>>>> 3. authorization schemes/models for Pull: inter-domain > > >>>>>>> authorization > > >>>> > > >>>>>>> between authorizing entity and NE is not envisaged as the basic > > >>>>>>> model, should be revised in the context; Token based approach is > > >>>>>>> not > > >>>> > > >>>>>>> the main trend, should be shortened. > > >>>>> > > >>>>> We need to have inter-domain authorization as the basic scenario; > > >>>>> local authorization should be treated as a special case. The > > >>>>> whole point is to leverage the inter-domain capability of > > >>>>> Diameter to mediate between network elements and authorizing > > >>>>> entities, whether the AEs are application servers or static > > >>>>> subscriber databases. > > >>>>> > > >>>>> [DS] I agree that inter-domain authorization/policy communication > > >>>>> is > > >> > > >>>>> important, but the mechanism and scope of this document is > > >>>>> inappropriate to solve that issue, since it is not the right way > > >>>>> forward envisioned by the industry and operators. > > >>>>> > > >>>>> If we only solve the local case it will mean that an application > > >>>>> server has to be co-located in the local domain. This is not the > > >>>>> way > > >>> > > >>>>> the Internet is supposed to work: services should be deployable > > >>>>> end-to-end, without modifying elements of the network along the > > >>>>> path. It should be possible for the application server to be > > >>>>> located > > >> > > >>>>> anywhere in the network and the AAA part should just work. > > >>>>> > > >>>>> [DS] as I said, the AS and AE can be in different domains. On the > > >>>>> other hand, if we integrate the AS with AE together, it impose a > > >>>>> tight > > >>>> > > >>>>> coupled service model, i.e. AS and AE always have to be in the > > >>>>> same domain. Exactly the issue you are concerned. > > >>>>> > > >>>>>>> 4. The current doc mainly talks about the QoS, should add some > > >>>>>>> tint > > >>> > > >>>>>>> on the policy control side. > > >>>>>>> > > >>>>>>> Please let me know your opinion and how to proceed. > > >>>>>>> > > >>>>>>> Regards, > > >>>>>>> Dong > > >>>>> > > >>>>> -Pete > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > End of DiME Digest, Vol 18, Issue 13 > > ************************************ > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 14 15:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyv3k-0003os-TR; Thu, 14 Jun 2007 15:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyv3k-0003on-EV for dime@ietf.org; Thu, 14 Jun 2007 15:32:44 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyv3i-00077a-Kp for dime@ietf.org; Thu, 14 Jun 2007 15:32:44 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l5EJWe7n020306 for ; Thu, 14 Jun 2007 15:32:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] FW: First draft on the integration of QoS application Date: Thu, 14 Jun 2007 15:32:40 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7187F9F@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: First draft on the integration of QoS application Thread-Index: AcetISvGTMneLoT9RHySt6sElj/kSQADAwBAAAQSw0AAIhfZoAAA/rRwAAA4YPAAALX/UAAEvulgAAHFv2AAAzbrgAAEo/mQACyi5MA= References: From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org IMHO it makes sense to separate AF and PDF functionalities depending on the network topology/business model. It provides a single point of contact for AF, if the service instance requires QoS reservations in multiple networks/devices etc... OTOH, I have no strong opinion in terms of where the inter-domain boundary is going to be. It could be that both AF/PDF and PDF/PEP interfaces are inter-domain for a specific service instance. Probably this is not something for us to decide but we need to have the flexibility to support all models (if possible). I guess IETF QoS work can address both interfaces. PDF can act as a Diameter proxy, Diameter B2BUA type of entity etc... or may not be in the picture at all depending on the business model. What problem do we see with this approach? Thanks, Tolga > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Wednesday, June 13, 2007 6:08 PM > To: dime@ietf.org > Subject: [Dime] FW: First draft on the integration of QoS application >=20 > Below is a discussion thread that has been taking place > among authors of the diameter-qos draft. We thought it > important that the mailing list have some visibility > to the discussion. Comments welcome. >=20 > -Pete >=20 > McCann Peter-A001034 wrote: > > Hi, Dong, > > > > I guess I don't see why we need two separate interfaces. They are > > each transporting roughly the same information and doing the same > > sort of job. > > > > The current document in my mind has always been an inter-domain > > interface. See the abstract: > > > > ...Clients that implement the Diameter QoS application contact an > > authorizing entity/application server that is located somewhere in > > the network, allowing for a wide variety of flexible deployment > > models. > > > > And the following text in Section 3.2: > > > > Inter-domain support > > > > In particular, users may roam outside their home network, > > leading to a situation where the network element and > > authorizing entity are in different administrative domains. > > > > -Pete > > > > Sun, Dong (Dong) wrote: > >> Hi Pete, > >> I have no doubt about the importance of inter-domain policy > >> communications, and it might be better to use the Diameter broker > >> instead of SIP proxy to deal with inter-domain resource management. > >> In fact, I think 3GPP does use the similar model as you described, > >> that a Diameter broker (client) is embedded in the AF (e.g. P-CSCF), > >> and the interface between AF and underlying Policy engine (e.g. PCRF) > >> is an inter-domain interface per se. certainly, since they (SIP and > >> Diameter brokers) are grouped together, it is less flexible and > >> scalable for the implementation. > >> > >> However, I think this interface (named as Rx in 3GPP, Gq' in TISPAN, > >> Rs in ITU) is not for the control of policy enforcement directly. In > >> my view, this interface (Rx) is a peering interface between policy > >> servers rather than between policy server and enforcement point as > >> described in the current QoS application, and I believe it is more > >> appropriate to model the inter-domain interface as the policy server > >> to policy server (PDF-PDF) peering interface. > >> > >> I have no problem to develop a doc to address this inter-domain > >> application, however, if you look around the current document, I did > >> not see any indication from that perspective. > >> > >> Dong > >> > >> -----Original Message----- > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >> Sent: Wednesday, June 13, 2007 2:11 PM > >> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina TSOU; > >> Avri Doria Cc: Victor Fajardo > >> Subject: RE: First draft on the integration of QoS application > >> > >> Hi, Dong, > >> > >> Sun, Dong (Dong) wrote: > >>> Hi Pete, > >>> > >>> Thanks for clarification. Just wondering if you can give an example > >>> who will use the "inter-domain" model for policy enforcement > >>> control, i.e. PDP and PEP reside in the different operator's > >>> administrative domains. Since the inter-domain is to serve for the > >>> operator's domain, I don't know how to create an application > >>> without considering their need. (BTW, I have no strong view to > >>> limit it to intra-domain only if the use case can be identified). > >> > >> Arbitrary third parties should be allowed to deploy application > >> servers and interface to the Diameter cloud to get QoS from the > >> network. The Diameter QoS Application should play this role. > >> In the extreme case, I should be allowed to put a SIP server in my > >> basement, sign up with a Diameter broker, and run my application > >> end-to-end. > >> > >>> I agree that this application should support "a generic mediator > >>> that can handle many applications". However, Given the integrated > >>> AS and AE, it makes the AE has to be collocated with the > >>> application content providers rather than the network itself, I > >>> feel it is also too limited and not the common case in reality. (As > >>> far as I know, all deployed or emerging network infrastructures > >>> such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view this solution as > >>> the main trend). I am wondering who will use this application > >>> eventually. > >> > >> I am not ruling out a PDP in the network local to the PEP. I am just > >> saying that this PDP should be viewed as a Diameter proxy on the path > >> to the Authorizing Entity, which itself may be either a static > >> subscriber database or an active application server. > >> I don't want to work only on the localized protocol, I want to define > >> the inter-domain one. If you insist on separating the AE from the AS > >> then I would say that the important Diameter interface is the one > >> between AE and AS. It is much more important to standardize the > >> inter-domain interface because this is the one that will be used > >> between operators. > >> > >> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they are > >> going down the path of using SIP proxies as the inter-domain > >> interface. I think this architecture is bad for the Internet, and > >> will limit the kinds of applications that can be deployed. > >> The Internet model is that applications should be deployable without > >> modifying the middleboxes. Tying SIP servers to the network traffic > >> path also doesn't work well with Mobile IP. > >> > >>> In addition, the scalable roaming agreements sound like a general > >>> algorithm that may be applicable for any inter-domain issue in the > >>> context of Diameter applications, or it is only the fundament to > >>> this application? > >> > >> The Diameter NASREQ application (similar to the basic RADIUS > >> protocol) has always been about inter-domain operation. Diameter is > >> used as the mediating protocol between different operator domains. I > >> think we should be following the same model with the Diameter QoS > >> application. > >> > >> -Pete > >> > >>> Dong > >>> > >>> -----Original Message----- > >>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>> Sent: Wednesday, June 13, 2007 11:06 AM > >>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > >>> integration of QoS application > >>> > >>> Hi, Dong, > >>> > >>> An "Autonomous System" has a very specific meaning in the context of > >>> routing protocols; I would not want to say that they correspond > >>> one-to-one with the "domains" that exist when I talk about > >>> "inter-domain" in the context of diameter-qos. I would say that > >>> "operator's administrative domain" is a better term. > >>> > >>> In any case, I think that the Diameter cloud from the figure 1 > >>> should be a generic inter-domain mediator that can handle many > >>> applications, of which Diameter QoS is one. The scalable roaming > >>> agreements embodied in this cloud should allow the Authorizing > >>> Entity to be anywhere in the network. There may be proxies in the > >>> Diameter cloud that enforce their own policy decisions, some of > >>> which will be local to the Network Element's administrative domain. > >>> However, that should not impact the specification of the Diameter > >>> QoS Application. This inter-domain operation has been at the core > >>> of the document since I started it: see Section 3.2 in the -00 > >>> version. > >>> > >>> -Pete > >>> > >>> Sun, Dong (Dong) wrote: > >>>> Hi Pete, > >>>> > >>>> Before making any conclusion, I'd like to clarify some terms: > >>>> Since you mentioned this is IETF, Internet and such, the domain you > >>>> refer to is in the context of the "Autonomous System" or > >>>> "operator's administrative domain". > >>>> > >>>> Dong > >>>> > >>>> -----Original Message----- > >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>> Sent: Wednesday, June 13, 2007 10:27 AM > >>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > >>>> integration of QoS application > >>>> > >>>> Hi, Dong, > >>>> > >>>> I think you and I have a fundamental disagreement on the scope and > >>>> purpose of this document. I really don't see the need to > >>>> standardize > >> > >>>> an intra-domain localized solution to the problem. This is IETF we > >>>> should be solving the problem for the whole Internet, which means > >>>> inter-domain is the target. I understand that some operators might > >>>> not want to open their networks, but we should not be defining > >>>> standards for these closed architectures. > >>>> > >>>> I also feel strongly that we should have adequate discovery > >>>> mechanisms > >>> > >>>> for all modes of operation specified in this document; otherwise it > >>>> could lead to inter-operability problems. > >>>> > >>>> Hannes, I would like to note this as a serious issue that should be > >>>> resolved before we proceed any further. I would like to check with > >>>> the mailing list and the ADs on their preferences. What do you > >>>> think > >> > >>>> would be the appropriate way to introduce the issue? Would you > >>>> like to introduce the question to the mailing list? > >>>> > >>>> -Pete > >>>> > >>>> Sun, Dong (Dong) wrote: > >>>>> Hi Pete, > >>>>> > >>>>> First of all, Thanks for the review and comments. > >>>>> > >>>>> 1. Concerning the split of Application Server and Authorizing > >>>>> Entity, > >>> > >>>>> which is somewhat related to another main comment you brought up > >>>>> i.e. the relationship between Authorizing Entity and NE - > >>>>> inter-domain Vs. intra-domain, the rationale in my mind is as > >>>>> follow: - In the real network (or the vision of NGN, or somewhat > >>>>> the > >> > >>>>> net neutrality perspective), the packet (transport) network should > >>>>> support > >>>> > >>>>> a variety of applications which may belong to different SPs i.e. > >>>>> in different domain. The PDP (i.e. Authorizing entity in the > >>>>> context of > >> > >>>>> QoS application) can act as the arbitrator to isolate the > >>>>> diversity of application attributes from the speciality of network > >>>>> functionality. The authorizing entity is typically part of > >>>>> transport > >> > >>>>> network domain along with the NEs since the network operators are > >>>>> commonly willing to > >>>> > >>>>> neither rely on the third party to control the use of their > >>>>> network resources nor disclose the network details (e.g. > >>>>> topology, resource usage and policies) to other carriers/SPs. > >>>>> Therefore, the common case is that the interface between > >>>>> Authorizing entity and NE (enforcement point) should be > >>>>> intra-domain in nature. > >>>>> > >>>>> - On the other hand, the interface between AS and AE can be > >>>>> inter-domain, which also makes the life easier concerning the > >>>>> inter-domain enforcement interface. > >>>>> > >>>>> - The policy communications between different domains is quite > >>>>> important, for example, for the roaming scenario. However, it is > >>>>> outside the scope of this application if my understanding is > >>>>> correct. I feel it is better to be solved through > >>>>> inter-Authorizing Entity interface rather than this interface. > >>>>> Certainly, the command and AVPs > >>> > >>>>> might be shared, but I would rather not mix them together for the > >>>>> time being. > >>>>> > >>>>> 2. Concerning the discovery mechanism for Push mode, I agree that > >>>>> it > >> > >>>>> is a tricky issue and also support to describe the issue in the > >>>>> document. However, I'd like to point out, this document should > >>>>> concentrate on the protocol related issue and allow the > >>>>> flexibility to use the other discovery mechanism beyond the > >>>>> Diameter protocol capability. In other words, we mainly need to > >>>>> define some mechanism based on Diameter protocol's capability, > >>>>> such as the realm based routing, and leave the door open for > >>>>> other advanced discovery schemes. > >>>>> > >>>>> See additional comment in line... > >>>>> > >>>>> Regards, > >>>>> Dong > >>>>> > >>>>> -----Original Message----- > >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>> Sent: Tuesday, June 12, 2007 5:26 PM > >>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina > >>>>> TSOU; > >> > >>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > >>>>> integration of QoS application > >>>>> > >>>>> Hi, all, > >>>>> > >>>>> Please see my comments in line. > >>>>> > >>>>> Hannes Tschofenig wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> could you please take a look at the proposal by Dong? > >>>>>> > >>>>>> They are available here: > >>>>>> > >>>>> > >>>> > >>> > >> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft > >> -i > >>>>> etf-dime-diameter-qos-01-ds.txt > >>>>>> > >>>>>> The XML file is in the same directory, as usual. > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> Sun, Dong (Dong) wrote: > >>>>>>> Hi Hannes et al, > >>>>>>> > >>>>>>> Attached is the first cut to integrate two I-Ds. The change is a > >>>>>>> minimum set based on the comments from the exploder (Tina, > >>>>>>> Christian > >>>> > >>>>>>> and Tolga). There are some open issues to be done, I'd like to > >>>>>>> get > >> > >>>>>>> your comments on changes first and discuss how to proceed on > >>>>>>> those > >> > >>>>>>> open items before making any further editings. Main changes: > >>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push modes > >>>>> > >>>>> In the definition of Pull mode, the following sentence > >>>>> The Authorizing Entity then installs the QoS > >>>>> authorization decision to the Network Element initiatively. > >>>>> needs work. "initiatively" is not a word. > >>>>> > >>>>> [DS] ok. Any good word? Basically I don't like some words such as > >>>>> unsolicited since it is used by 3GPP for different meaning. Maybe > >>>>> "directly" instead? > >>>>> > >>>>>>> 2. section 3.1/2: modify the architecture diagram to separate > >>>>>>> the Authorizing Entity from AS (further alignment is needed in > >>>>>>> the context); and add new subsections to addressing the endpoint > >>>>>>> features > >>>>> > >>>>>>> and push/pull modes. > >>>>> > >>>>> Breaking up the AS and AE implies that there will be another > >>>>> interface > >>>> > >>>>> yet to be defined. I would rather not open up this possibility. > >>>>> The > >>> > >>>>> Diameter QoS application should be usable all the way from network > >>>>> element to application server, perhaps passing through an > >>>>> arbitrary number of proxies that enforce their own policies, but > >>>>> there should be > >>>> > >>>>> 1 interface not 2. Also, it is important to note that the AS need > >>>>> not > >>>> > >>>>> be present at all in some > >>>>> scenarios: for example, when authorizing requests from a static > >>>>> subscriber database. > >>>>> > >>>>> [DS] First of all, I don't intend to standardize the interface > >>>>> between > >>>> > >>>>> AS and AE in this application. Second, I am not sure why the > >>>>> separate > >>> > >>>>> of AS and AE prevents the AE access to a static subscriber > >>>>> database. The basic rationale is address as aforementioned. > >>>>> > >>>>>>> 3. section 3.3: minor revision on the models for pull; rewrite > >>>>>>> the > >> > >>>>>>> push model (Tina, pls take a look) > >>>>> > >>>>> 3.2 looks new. It seems to be overly weighted in favor of the > >>>>> push model. I would like to point out that there is a big > >>>>> discovery problem with the push model, especially when the AE and > >>>>> NE are in different administrative domains. The push model is > >>>>> only applicable > >> > >>>>> to the case where the AE and the NE are in the same administrative > >>>>> domain and therefore it is a special case. > >>>>> > >>>>> [DS] I think in reality the operators mainly look at the > >>>>> intra-domain > >>> > >>>>> policy enforcement interface, whatever pull or push models. I am > >>>>> not > >> > >>>>> in favor of any specific models, just analyze the impact of > >>>>> endpoint's > >>>> > >>>>> capability. If you have any words that can enhance the pull model, > >>>>> it > >>> > >>>>> is very welcome :-). > >>>>> > >>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section > >>>>>>> 7.4 and > >>>>> > >>>>>>> table. But the name still remains in some texts. > >>>>>>> > >>>>>>> To be done: > >>>>>>> 1. state mechanism for Push mode: server initiated policy > >>>>>>> installation 2. should section 4.4 be merged with section 4.2 > >>>>>>> since > >>> > >>>>>>> both them discuss how to initiate a new Diameter session? In > >>>>>>> addition, the text needs to be beefed up for server initiated > >>>>>>> session. > >>>>>>> 3. authorization schemes/models for Pull: inter-domain > >>>>>>> authorization > >>>> > >>>>>>> between authorizing entity and NE is not envisaged as the basic > >>>>>>> model, should be revised in the context; Token based approach is > >>>>>>> not > >>>> > >>>>>>> the main trend, should be shortened. > >>>>> > >>>>> We need to have inter-domain authorization as the basic scenario; > >>>>> local authorization should be treated as a special case. The > >>>>> whole point is to leverage the inter-domain capability of > >>>>> Diameter to mediate between network elements and authorizing > >>>>> entities, whether the AEs are application servers or static > >>>>> subscriber databases. > >>>>> > >>>>> [DS] I agree that inter-domain authorization/policy communication > >>>>> is > >> > >>>>> important, but the mechanism and scope of this document is > >>>>> inappropriate to solve that issue, since it is not the right way > >>>>> forward envisioned by the industry and operators. > >>>>> > >>>>> If we only solve the local case it will mean that an application > >>>>> server has to be co-located in the local domain. This is not the > >>>>> way > >>> > >>>>> the Internet is supposed to work: services should be deployable > >>>>> end-to-end, without modifying elements of the network along the > >>>>> path. It should be possible for the application server to be > >>>>> located > >> > >>>>> anywhere in the network and the AAA part should just work. > >>>>> > >>>>> [DS] as I said, the AS and AE can be in different domains. On the > >>>>> other hand, if we integrate the AS with AE together, it impose a > >>>>> tight > >>>> > >>>>> coupled service model, i.e. AS and AE always have to be in the > >>>>> same domain. Exactly the issue you are concerned. > >>>>> > >>>>>>> 4. The current doc mainly talks about the QoS, should add some > >>>>>>> tint > >>> > >>>>>>> on the policy control side. > >>>>>>> > >>>>>>> Please let me know your opinion and how to proceed. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Dong > >>>>> > >>>>> -Pete >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 15 03:15:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz61S-0004C1-JD; Fri, 15 Jun 2007 03:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz61R-0004Bw-Ty for dime@ietf.org; Fri, 15 Jun 2007 03:15:05 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz61P-0004JJ-DS for dime@ietf.org; Fri, 15 Jun 2007 03:15:05 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5F7ArV6008765 for ; Fri, 15 Jun 2007 12:40:53 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5F7AoT0008740; Fri, 15 Jun 2007 12:40:51 +0530 To: dime@ietf.org, vfajardo@tari.toshiba.com, tasveren@sonusnet.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Nimish Bhargava Date: Fri, 15 Jun 2007 12:47:34 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 15/06/2007 12:48:45 PM, Serialize complete at 15/06/2007 12:48:45 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Dime] Relay supporting application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0144685988==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0144685988== Content-Type: multipart/alternative; boundary="=_alternative 0027CFD5652572FB_=" This is a multipart message in MIME format. --=_alternative 0027CFD5652572FB_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpDYW4gYW55b25lIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJvdXQgd2hldGhlciB0 aGUgcmVsYXkgbm9kZXMgY2FuIHN1cHBvcnQgDQphbnkgYXBwbGljYXRpb24gYWxzbz8gDQoNCkFj Y29yZGluZyB0byBTcGVjaWZpY2F0aW9uIDM1ODggc2VjdGlvbiAyLjguMSBsYXN0IHBhcmENCg0K IlNpbmNlIFJlbGF5cyBkbyBub3QgcGVyZm9ybSBhbnkgYXBwbGljYXRpb24gbGV2ZWwgcHJvY2Vz c2luZywgdGhleQ0KICAgcHJvdmlkZSByZWxheWluZyBzZXJ2aWNlcyBmb3IgYWxsIERpYW1ldGVy IGFwcGxpY2F0aW9ucywgYW5kDQogICB0aGVyZWZvcmUgTVVTVCBhZHZlcnRpc2UgdGhlIFJlbGF5 IEFwcGxpY2F0aW9uIElkZW50aWZpZXIuIg0KDQpEb2VzIHRoaXMgbWVhbiB0aGF0IHJlbGF5IGFn ZW50cyBjYW4gbmV2ZXIgc3VwcG9ydCBhbnkgYXBwbGljYXRpb24gYWJvdmUgDQp0aGVtID8NCg0K UmVnYXJkcywNCk5pbWlzaA0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqICBBcmljZW50LVVu Y2xhc3NpZmllZCAgICoqKioqKioqKioqKioqKioqKioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBt ZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJ dCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQg c2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5 LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVk IHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFs dGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNl bnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcg ZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWls IGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 0027CFD5652572FB_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNhbiBhbnlvbmUgcHJvdmlkZSBp bmZvcm1hdGlvbiBhYm91dA0Kd2hldGhlciB0aGUgcmVsYXkgbm9kZXMgY2FuIHN1cHBvcnQgYW55 IGFwcGxpY2F0aW9uIGFsc28/IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+QWNjb3JkaW5nIHRvIFNwZWNpZmljYXRpb24gMzU4OCBzZWN0aW9uDQoyLjgu MSBsYXN0IHBhcmE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZxdW90OzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlNpbmNlDQpS ZWxheXMgZG8gbm90IHBlcmZvcm0gYW55IGFwcGxpY2F0aW9uIGxldmVsIHByb2Nlc3NpbmcsIHRo ZXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5i c3A7cHJvdmlkZSByZWxheWluZyBzZXJ2aWNlcw0KZm9yIGFsbCBEaWFtZXRlciBhcHBsaWNhdGlv bnMsIGFuZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNw OyAmbmJzcDt0aGVyZWZvcmUgTVVTVCBhZHZlcnRpc2UNCnRoZSBSZWxheSBBcHBsaWNhdGlvbiBJ ZGVudGlmaWVyLjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Eb2VzIHRoaXMg bWVhbiB0aGF0IHJlbGF5IGFnZW50cyBjYW4NCm5ldmVyIHN1cHBvcnQgYW55IGFwcGxpY2F0aW9u IGFib3ZlIHRoZW0gPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KUmVnYXJkcyw8YnI+DQpOaW1pc2g8YnI+DQo8YnI+DQo8YnI+DQoqKioqKioqKioqKioq KioqKioqKioqKiAmbmJzcDtBcmljZW50LVVuY2xhc3NpZmllZCAmbmJzcDsgKioqKioqKioqKioq KioqKioqKioqKio8L2ZvbnQ+DQo8dGFibGU+PHRyPjx0ZCBiZ2NvbG9yPSNmZmZmZmY+PGZvbnQg Y29sb3I9IzAwMDAwMD48cHJlPiJESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRh cnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhl IGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZp bGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJj dWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMg aW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmlj dGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3Np bmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3Bv bnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhl IGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBm cm9tIHZpcnVzLiIKPC9wcmU+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPg== --=_alternative 0027CFD5652572FB_=-- --===============0144685988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0144685988==-- From dime-bounces@ietf.org Fri Jun 15 05:26:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz84e-0007ZF-Ai; Fri, 15 Jun 2007 05:26:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz84c-0007Z4-UH for dime@ietf.org; Fri, 15 Jun 2007 05:26:30 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz84Z-0007PQ-JJ for dime@ietf.org; Fri, 15 Jun 2007 05:26:30 -0400 Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 16 Jun 2007 03:54:28 +0530 X-IronPort-AV: i="4.16,423,1175452200"; d="scan'208,217"; a="82247986:sNHT109737894" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5F9QP8P011884; Fri, 15 Jun 2007 14:56:25 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5F9QMfM003192; Fri, 15 Jun 2007 09:26:22 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:56:23 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Relay supporting application Date: Fri, 15 Jun 2007 14:56:22 +0530 Message-ID: <8EB00AB9BCE95E4DBADDDB25EBCBF95D0356990F@xmb-blr-418.apac.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Relay supporting application Thread-Index: AcevHPJFaBzWrf52RNuMMMQCKfzDMAAD+FMw From: "Satendra Gera (satgera)" To: "Nimish Bhargava" X-OriginalArrivalTime: 15 Jun 2007 09:26:23.0817 (UTC) FILETIME=[3DC7B390:01C7AF2F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6384; t=1181899585; x=1182763585; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=satgera@cisco.com; z=From:=20=22Satendra=20Gera=20(satgera)=22=20 |Subject:=20RE=3A=20[Dime]=20Relay=20supporting=20application |Sender:=20; bh=NYHADQbtlJMSsF8es53972K4EIRztK1dlI1HKTNyvM0=; b=RKUPGuv+jO5sNsHwEmsc70RMOcC8BnNnqIDZnCf+MbdPwRyGJV0SYCbVSZStIpP9VACW122I nek3QcyN+UzZkQatQaBgY4p3InG8NMOM0+Bb6aUjy3Sk3q5lVwtKl5+6; Authentication-Results: ind-dkim-1; header.From=satgera@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331912429==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0331912429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AF2F.3D9BE21F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AF2F.3D9BE21F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Nimish, =20 IMO there is no restriction on support of applications on a relay node (node supporting relay functionality). I remember more than one implementations from last interop supporting application in addition to relay functionality on the same node. It is common to have similar setup where a server serves requests for/from local domain and relays the rest.=20 =20 Regards, Satendra ________________________________ From: Nimish Bhargava [mailto:nimish.bhargava@aricent.com]=20 Sent: Friday, June 15, 2007 12:48 PM To: dime@ietf.org; vfajardo@tari.toshiba.com; tasveren@sonusnet.com Subject: [Dime] Relay supporting application Hi all,=20 Can anyone provide information about whether the relay nodes can support any application also?=20 According to Specification 3588 section 2.8.1 last para=20 "Since Relays do not perform any application level processing, they=20 provide relaying services for all Diameter applications, and=20 therefore MUST advertise the Relay Application Identifier."=20 Does this mean that relay agents can never support any application above them ?=20 Regards, Nimish *********************** Aricent-Unclassified ***********************=20 "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. If you have received this message in error,=20 please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by this email including damage from virus." ------_=_NextPart_001_01C7AF2F.3D9BE21F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Nimish,
 
IMO there is no restriction on support of = applications=20 on a relay node (node supporting relay = functionality).
I remember more than one implementations from = last interop=20 supporting application in addition to relay functionality on the same=20 node.
It is common to have = similar setup where a=20 server serves requests for/from local domain and relays the=20 rest. 
 
Regards,
Satendra

From: Nimish Bhargava=20 [mailto:nimish.bhargava@aricent.com]
Sent: Friday, June 15, = 2007=20 12:48 PM
To: dime@ietf.org; vfajardo@tari.toshiba.com;=20 tasveren@sonusnet.com
Subject: [Dime] Relay supporting=20 application


Hi all, =

Can anyone provide information about whether = the relay=20 nodes can support any application also?

According to Specification 3588 section 2.8.1 last para=20

"Since Relays do not perform any application level processing, = they=20
   provide relaying = services for=20 all Diameter applications, and
 =20  therefore MUST advertise the Relay Application = Identifier."

Does this=20 mean that relay agents can never support any application above them = ?=20

Regards,
Nimish


***********************=20  Aricent-Unclassified   ***********************=20 
"DISCLAIMER: This =
message is proprietary to Aricent  and is intended solely for the use of =

the individual to whom it is addressed. It may contain privileged or =
confidential information and should not be=20
circulated or used for any purpose other than for what it is intended. =
If you have received this message in error,=20
please notify the originator immediately. If you are not the intended =
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of =
this message. Aricent accepts no responsibility for=20
loss or damage arising from the use of the information transmitted by =
this email including damage from virus."
------_=_NextPart_001_01C7AF2F.3D9BE21F-- --===============0331912429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0331912429==-- From dime-bounces@ietf.org Fri Jun 15 05:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8Mm-0001cT-Fl; Fri, 15 Jun 2007 05:45:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8Mm-0001cN-1J for dime@ietf.org; Fri, 15 Jun 2007 05:45:16 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz8Mk-0004FX-JN for dime@ietf.org; Fri, 15 Jun 2007 05:45:16 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5F9f53O016555 for ; Fri, 15 Jun 2007 15:11:05 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5F9f5RT016492; Fri, 15 Jun 2007 15:11:05 +0530 In-Reply-To: <8EB00AB9BCE95E4DBADDDB25EBCBF95D0356990F@xmb-blr-418.apac.cisco.com> To: "Satendra Gera (satgera)" Subject: RE: [Dime] Relay supporting application MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Nimish Bhargava Date: Fri, 15 Jun 2007 15:17:47 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 15/06/2007 03:18:57 PM, Serialize complete at 15/06/2007 03:18:57 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0370688960==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0370688960== Content-Type: multipart/alternative; boundary="=_alternative 00359084652572FB_=" This is a multipart message in MIME format. --=_alternative 00359084652572FB_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgU2F0ZW5kcmENCg0KUGxlYXNlIGZpbmQgbXkgY29tbWVudHMgaW5saW5lLg0KDQpSZWdhcmRz LA0KTmltaXNoDQoNCg0KDQoNCiJTYXRlbmRyYSBHZXJhIChzYXRnZXJhKSIgPHNhdGdlcmFAY2lz Y28uY29tPiANCjA2LzE1LzIwMDcgMDI6NTYgUE0NCg0KDQpUbw0KTmltaXNoIEJoYXJnYXZhL0hT U0BIU1MNCmNjDQo8ZGltZUBpZXRmLm9yZz4NClN1YmplY3QNClJFOiBbRGltZV0gUmVsYXkgc3Vw cG9ydGluZyBhcHBsaWNhdGlvbg0KDQoNCg0KDQoNCg0KSGkgTmltaXNoLA0KIA0KSU1PIHRoZXJl IGlzIG5vIHJlc3RyaWN0aW9uIG9uIHN1cHBvcnQgb2YgYXBwbGljYXRpb25zIG9uIGEgcmVsYXkg bm9kZSANCihub2RlIHN1cHBvcnRpbmcgcmVsYXkgZnVuY3Rpb25hbGl0eSkuDQpJIHJlbWVtYmVy IG1vcmUgdGhhbiBvbmUgaW1wbGVtZW50YXRpb25zIGZyb20gbGFzdCBpbnRlcm9wIHN1cHBvcnRp bmcgDQphcHBsaWNhdGlvbiBpbiBhZGRpdGlvbiB0byByZWxheSBmdW5jdGlvbmFsaXR5IG9uIHRo ZSBzYW1lIG5vZGUuDQoNCjxOaW1pc2g+DQpDb3VsZCB5b3UgcGxlYXNlIHZlcmlmeSB0aGF0IHRo ZSBub2RlIHdhcyBzdXBwb3RpbmcgcmVsYXkgYXBwbGljYXRpb24gYWxzbyANCihhbG9uZyB3aXRo IHJlbGF5IGZ1bmN0aW9uYWxpdHkpLg0KPC9OaW1pc2g+DQoNCkl0IGlzIGNvbW1vbiB0byBoYXZl IHNpbWlsYXIgc2V0dXAgd2hlcmUgYSBzZXJ2ZXIgc2VydmVzIHJlcXVlc3RzIGZvci9mcm9tIA0K bG9jYWwgZG9tYWluIGFuZCByZWxheXMgdGhlIHJlc3QuIA0KDQo8TmltaXNoPg0KSSBkbyBhZ3Jl ZSB0aGF0IGEgbm9kZSBjYW4gc2VydmUgdGhlIHJlcXVlc3RzIGZyb20gc29tZSBkb21haW4gYW5k IHJlbGF5IA0KdGhlIHJlc3QuIA0KV2hhdCBJIHdhbnQgdG8gY29uZmlybSBpcyB3aGV0aGVyIHRo aXMgbm9kZSBzdXBwb3J0cyB0aGUgcmVsYXkgYXBwbGljYXRpb24gDQphbHNvID8NCjwvTmltaXNo Pg0KDQogDQpSZWdhcmRzLA0KU2F0ZW5kcmENCg0KRnJvbTogTmltaXNoIEJoYXJnYXZhIFttYWls dG86bmltaXNoLmJoYXJnYXZhQGFyaWNlbnQuY29tXSANClNlbnQ6IEZyaWRheSwgSnVuZSAxNSwg MjAwNyAxMjo0OCBQTQ0KVG86IGRpbWVAaWV0Zi5vcmc7IHZmYWphcmRvQHRhcmkudG9zaGliYS5j b207IHRhc3ZlcmVuQHNvbnVzbmV0LmNvbQ0KU3ViamVjdDogW0RpbWVdIFJlbGF5IHN1cHBvcnRp bmcgYXBwbGljYXRpb24NCg0KDQpIaSBhbGwsIA0KDQpDYW4gYW55b25lIHByb3ZpZGUgaW5mb3Jt YXRpb24gYWJvdXQgd2hldGhlciB0aGUgcmVsYXkgbm9kZXMgY2FuIHN1cHBvcnQgDQphbnkgYXBw bGljYXRpb24gYWxzbz8gDQoNCkFjY29yZGluZyB0byBTcGVjaWZpY2F0aW9uIDM1ODggc2VjdGlv biAyLjguMSBsYXN0IHBhcmEgDQoNCiJTaW5jZSBSZWxheXMgZG8gbm90IHBlcmZvcm0gYW55IGFw cGxpY2F0aW9uIGxldmVsIHByb2Nlc3NpbmcsIHRoZXkgDQogICBwcm92aWRlIHJlbGF5aW5nIHNl cnZpY2VzIGZvciBhbGwgRGlhbWV0ZXIgYXBwbGljYXRpb25zLCBhbmQgDQogICB0aGVyZWZvcmUg TVVTVCBhZHZlcnRpc2UgdGhlIFJlbGF5IEFwcGxpY2F0aW9uIElkZW50aWZpZXIuIiANCg0KRG9l cyB0aGlzIG1lYW4gdGhhdCByZWxheSBhZ2VudHMgY2FuIG5ldmVyIHN1cHBvcnQgYW55IGFwcGxp Y2F0aW9uIGFib3ZlIA0KdGhlbSA/IA0KDQpSZWdhcmRzLA0KTmltaXNoDQoNCg0KKioqKioqKioq KioqKioqKioqKioqKiogIEFyaWNlbnQtVW5jbGFzc2lmaWVkICAgKioqKioqKioqKioqKioqKioq KioqKiogDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNl bnQgIGFuZCBpcyBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiANCnRoZSBpbmRpdmlk dWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9y IA0KY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIA0KY2lyY3VsYXRl ZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVu ZGVkLiBJZiANCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgDQpwbGVh c2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgDQpyZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmlj dGx5DQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9z aW5nIHRoZSBjb250ZW50cyBvZiANCnRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJl c3BvbnNpYmlsaXR5IGZvciANCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIA0KZW1haWwgaW5jbHVkaW5nIGRh bWFnZSBmcm9tIHZpcnVzLiINCg0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKiogIEFyaWNl bnQtVW5jbGFzc2lmaWVkICAgKioqKioqKioqKioqKioqKioqKioqKioNCiJESVNDTEFJTUVSOiBU aGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNz ZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9u IGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90 aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRp YXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90 aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWlu ZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4g QXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJp c2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMg ZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIK --=_alternative 00359084652572FB_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNhdGVuZHJhPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QbGVhc2UgZmluZCBteSBj b21tZW50cyBpbmxpbmUuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpOaW1pc2g8YnI+DQo8L2Zv bnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7 U2F0ZW5kcmEgR2VyYSAoc2F0Z2VyYSkmcXVvdDsNCiZsdDtzYXRnZXJhQGNpc2NvLmNvbSZndDs8 L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wNi8xNS8yMDA3 IDAyOjU2IFBNPC9mb250Pg0KPGJyPg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+TmltaXNoIEJoYXJnYXZhL0hTU0BIU1M8L2ZvbnQ+DQo8dHI+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48 L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7 ZGltZUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkIHZh bGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbRGltZV0gUmVsYXkg c3VwcG9ydGluZw0KYXBwbGljYXRpb248L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+SGkgTmltaXNoLDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5JTU8gdGhlcmUgaXMgbm8gcmVzdHJpY3Rpb24gb24NCnN1 cHBvcnQgb2YgYXBwbGljYXRpb25zIG9uIGEgcmVsYXkgbm9kZSAobm9kZSBzdXBwb3J0aW5nIHJl bGF5IGZ1bmN0aW9uYWxpdHkpLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+SSByZW1lbWJlciBtb3JlIHRoYW4gb25lIGltcGxlbWVudGF0aW9ucw0KZnJv bSBsYXN0IGludGVyb3Agc3VwcG9ydGluZyBhcHBsaWNhdGlvbiBpbiBhZGRpdGlvbiB0byByZWxh eSBmdW5jdGlvbmFsaXR5DQpvbiB0aGUgc2FtZSBub2RlLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPiZsdDtOaW1pc2gmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+Q291bGQgeW91IHBsZWFzZSB2ZXJpZnkgdGhhdCB0aGUgbm9kZSB3 YXMNCnN1cHBvdGluZyByZWxheSBhcHBsaWNhdGlvbiBhbHNvIChhbG9uZyB3aXRoIHJlbGF5IGZ1 bmN0aW9uYWxpdHkpLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZsdDsv TmltaXNoJmd0OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+SXQgaXMgY29tbW9uIHRvIGhhdmUgc2ltaWxhciBzZXR1cA0Kd2hlcmUgYSBzZXJ2 ZXIgc2VydmVzIHJlcXVlc3RzIGZvci9mcm9tIGxvY2FsIGRvbWFpbiBhbmQgcmVsYXlzIHRoZSBy ZXN0Lg0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jmx0O05p bWlzaCZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5JIGRvIGFncmVl IHRoYXQgYSBub2RlIGNhbiBzZXJ2ZSB0aGUgcmVxdWVzdHMNCmZyb20gc29tZSBkb21haW4gYW5k IHJlbGF5IHRoZSByZXN0LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5X aGF0IEkgd2FudCB0byBjb25maXJtIGlzIHdoZXRoZXIgdGhpcyBub2RlDQpzdXBwb3J0cyB0aGUg cmVsYXkgYXBwbGljYXRpb24gYWxzbyA/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+Jmx0Oy9OaW1pc2gmZ3Q7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPlJlZ2Fy ZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5TYXRl bmRyYTwvZm9udD4NCjxicj4NCjxicj4NCjxocj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48 Yj5Gcm9tOjwvYj4gTmltaXNoIEJoYXJnYXZhIFttYWlsdG86bmltaXNoLmJoYXJnYXZhQGFyaWNl bnQuY29tXQ0KPGI+PGJyPg0KU2VudDo8L2I+IEZyaWRheSwgSnVuZSAxNSwgMjAwNyAxMjo0OCBQ TTxiPjxicj4NClRvOjwvYj4gZGltZUBpZXRmLm9yZzsgdmZhamFyZG9AdGFyaS50b3NoaWJhLmNv bTsgdGFzdmVyZW5Ac29udXNuZXQuY29tPGI+PGJyPg0KU3ViamVjdDo8L2I+IFtEaW1lXSBSZWxh eSBzdXBwb3J0aW5nIGFwcGxpY2F0aW9uPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIGFsbCw8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCkNhbiBhbnlvbmUgcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCB3aGV0aGVyIHRoZSBy ZWxheSBub2RlcyBjYW4gc3VwcG9ydA0KYW55IGFwcGxpY2F0aW9uIGFsc28/IDwvZm9udD48Zm9u dCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQpBY2NvcmRpbmcgdG8gU3BlY2lmaWNhdGlvbiAzNTg4IHNlY3Rpb24gMi44LjEgbGFzdCBwYXJh PC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KJnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+U2luY2UgUmVsYXlzIGRvIG5vdCBwZXJmb3JtDQphbnkgYXBwbGljYXRpb24gbGV2ZWwgcHJv Y2Vzc2luZywgdGhleTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsgcHJvdmlkZSByZWxheWluZyBzZXJ2aWNlcyBm b3IgYWxsIERpYW1ldGVyIGFwcGxpY2F0aW9ucywgYW5kPC9mb250Pjxmb250IHNpemU9Mz4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsgdGhlcmVm b3JlIE1VU1QgYWR2ZXJ0aXNlIHRoZSBSZWxheSBBcHBsaWNhdGlvbiBJZGVudGlmaWVyLjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7PC9mb250Pjxmb250IHNpemU9 Mz4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KRG9l cyB0aGlzIG1lYW4gdGhhdCByZWxheSBhZ2VudHMgY2FuIG5ldmVyIHN1cHBvcnQgYW55IGFwcGxp Y2F0aW9uIGFib3ZlDQp0aGVtID88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KTmltaXNoPGJy Pg0KPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKiogJm5ic3A7QXJpY2VudC1VbmNs YXNzaWZpZWQgJm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqPC9mb250Pjxmb250IHNpemU9 Mz4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyPg0KPHRkIHdpZHRoPTEwMCUgYmdj b2xvcj13aGl0ZT48dHQ+PGZvbnQgc2l6ZT0zPiZxdW90O0RJU0NMQUlNRVI6IFRoaXMgbWVzc2Fn ZQ0KaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAmbmJzcDthbmQgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIDxicj4NCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVz c2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbA0KaW5mb3JtYXRp b24gYW5kIHNob3VsZCBub3QgYmUgPGJyPg0KY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVy cG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCA8YnI+DQpwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LA0KeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHk8YnI+DQpwcm9oaWJpdGVk IGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50 cyBvZg0KdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9y IDxicj4NCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1h dGlvbiB0cmFuc21pdHRlZCBieSB0aGlzDQplbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmly dXMuJnF1b3Q7PGJyPg0KPC9mb250PjwvdHQ+PC90YWJsZT4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKiog Jm5ic3A7QXJpY2VudC1VbmNsYXNzaWZpZWQgJm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioq PC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZmZmZmPjxmb250IGNvbG9yPSMwMDAw MDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNl bnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFs IHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1 c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJp dGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250 ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBm b3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4i CjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 00359084652572FB_=-- --===============0370688960== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0370688960==-- From dime-bounces@ietf.org Fri Jun 15 05:56:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8XQ-000551-Bn; Fri, 15 Jun 2007 05:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8XO-00054r-SD for dime@ietf.org; Fri, 15 Jun 2007 05:56:14 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz8XN-0006or-4j for dime@ietf.org; Fri, 15 Jun 2007 05:56:14 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 16 Jun 2007 04:24:14 +0530 X-IronPort-AV: i="4.16,423,1175452200"; d="scan'208,217"; a="82250821:sNHT140132572" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5F9uAtX012235; Fri, 15 Jun 2007 17:56:10 +0800 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5F9tmqK026075; Fri, 15 Jun 2007 09:56:05 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 15:26:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Relay supporting application Date: Fri, 15 Jun 2007 15:26:03 +0530 Message-ID: <8EB00AB9BCE95E4DBADDDB25EBCBF95D0356991F@xmb-blr-418.apac.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Relay supporting application Thread-Index: AcevMeSDwFCxYp1UTLyahUoMUwxWfQAAT9VA From: "Satendra Gera (satgera)" To: "Nimish Bhargava" X-OriginalArrivalTime: 15 Jun 2007 09:56:04.0707 (UTC) FILETIME=[6345F330:01C7AF33] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11921; t=1181901370; x=1182765370; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=satgera@cisco.com; z=From:=20=22Satendra=20Gera=20(satgera)=22=20 |Subject:=20RE=3A=20[Dime]=20Relay=20supporting=20application |Sender:=20; bh=9CiJGTK7TJKEFd+8BQpUtRPIpTqAKzWGzV0X/Z+F39Y=; b=aJ3Qt3xMB4jvqKgS+jcEryN2IQejV+13VlNyXHio41IVaxMZHmESNRfdp1Q1yMQSJ6GRDsit +YD5lIcZQ6ot1yelCVOh+yr0t/2OESdWqpQAPXAMPlZQNvBDKe7ETPiLbcRp6PyqghkebQgmSW koDpZOolHfvzw2yEQZHx+qCYo=; Authentication-Results: hkg-dkim-1; header.From=satgera@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1541327199==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1541327199== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AF33.62E1D968" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AF33.62E1D968 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I can't name the implementations but yes I know of implementations that do that and IMO its not a violation of the standard. =20 Regards, Satendra ________________________________ From: Nimish Bhargava [mailto:nimish.bhargava@aricent.com]=20 Sent: Friday, June 15, 2007 3:18 PM To: Satendra Gera (satgera) Cc: dime@ietf.org Subject: RE: [Dime] Relay supporting application Hi Satendra=20 Please find my comments inline. Regards, Nimish "Satendra Gera (satgera)" =20 06/15/2007 02:56 PM=20 To Nimish Bhargava/HSS@HSS=20 cc =20 Subject RE: [Dime] Relay supporting application =09 Hi Nimish,=20 =20 IMO there is no restriction on support of applications on a relay node (node supporting relay functionality).=20 I remember more than one implementations from last interop supporting application in addition to relay functionality on the same node.=20 =20 Could you please verify that the node was suppoting relay application also (along with relay functionality).=20 =20 It is common to have similar setup where a server serves requests for/from local domain and relays the rest.=20 =20 I do agree that a node can serve the requests from some domain and relay the rest.=20 What I want to confirm is whether this node supports the relay application also ?=20 =20 =20 Regards,=20 Satendra=20 ________________________________ From: Nimish Bhargava [mailto:nimish.bhargava@aricent.com]=20 Sent: Friday, June 15, 2007 12:48 PM To: dime@ietf.org; vfajardo@tari.toshiba.com; tasveren@sonusnet.com Subject: [Dime] Relay supporting application Hi all,=20 Can anyone provide information about whether the relay nodes can support any application also?=20 According to Specification 3588 section 2.8.1 last para=20 "Since Relays do not perform any application level processing, they=20 provide relaying services for all Diameter applications, and=20 therefore MUST advertise the Relay Application Identifier."=20 Does this mean that relay agents can never support any application above them ?=20 Regards, Nimish *********************** Aricent-Unclassified ***********************=20 "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. If you have received this message in error,=20 please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by this email including damage from virus." *********************** Aricent-Unclassified ***********************=20 "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. If you have received this message in error,=20 please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by this email including damage from virus." ------_=_NextPart_001_01C7AF33.62E1D968 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I can't name the implementations but yes I know = of=20 implementations that do that and IMO its not a violation of the=20 standard.
 
Regards,
Satendra

From: Nimish Bhargava=20 [mailto:nimish.bhargava@aricent.com]
Sent: Friday, June 15, = 2007 3:18=20 PM
To: Satendra Gera (satgera)
Cc:=20 dime@ietf.org
Subject: RE: [Dime] Relay supporting=20 application


Hi Satendra =

Please find my comments=20 inline.

Regards,
Nimish



"Satendra Gera = (satgera)"=20 <satgera@cisco.com>

06/15/2007 02:56 PM =

To
Nimish=20 Bhargava/HSS@HSS=20
cc
<dime@ietf.org>=20
Subject
RE: [Dime] = Relay=20 supporting application

=




Hi Nimish,
  =
IMO there is no restriction on = support of=20 applications on a relay node (node supporting relay = functionality).=20
I remember more than one = implementations=20 from last interop supporting application in addition to relay = functionality on=20 the same node.

<Nimish>=20
Could you please verify that the node = was suppoting=20 relay application also (along with relay functionality). =
</Nimish>

It is common to have similar setup where a server serves = requests=20 for/from local domain and relays the rest.

<Nimish>
I do = agree that a node=20 can serve the requests from some domain and relay the rest. =
What I want to confirm is whether this node = supports the relay=20 application also ?
</Nimish>=20

 
Regards,
Satendra=20

From: Nimish Bhargava=20 [mailto:nimish.bhargava@aricent.com]
Sent: Friday, June 15, = 2007=20 12:48 PM
To: dime@ietf.org; vfajardo@tari.toshiba.com;=20 tasveren@sonusnet.com
Subject: [Dime] Relay supporting=20 application


Hi all,

Can anyone provide information about whether the relay = nodes can=20 support any application also?

According to Specification 3588 section = 2.8.1 last=20 para

"Since Relays do = not perform=20 any application level processing, they =
  provide relaying services for = all Diameter=20 applications, and
  therefore MUST advertise the Relay Application=20 Identifier."=20

Does this mean that = relay agents can=20 never support any application above them ? =

Regards,
Nimish


***********************=20  Aricent-Unclassified   ***********************=20
"DISCLAIMER: = This message=20 is proprietary to Aricent  and is intended solely for the use = of=20
the individual to whom it is addressed. It may contain = privileged or=20 confidential information and should not be
circulated or used = for any=20 purpose other than for what it is intended. If you have received = this=20 message in error,
please notify the originator immediately. If = you are=20 not the intended recipient, you are notified that you are=20 strictly
prohibited from using, copying, altering, or = disclosing the=20 contents of this message. Aricent accepts no responsibility for =
loss=20 or damage arising from the use of the information transmitted by = this=20 email including damage from=20 virus."




***********************  Aricent-Unclassified =  =20 ***********************=20 
"DISCLAIMER: This =
message is proprietary to Aricent  and is intended solely for the use of =

the individual to whom it is addressed. It may contain privileged or =
confidential information and should not be=20
circulated or used for any purpose other than for what it is intended. =
If you have received this message in error,=20
please notify the originator immediately. If you are not the intended =
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of =
this message. Aricent accepts no responsibility for=20
loss or damage arising from the use of the information transmitted by =
this email including damage from virus."
------_=_NextPart_001_01C7AF33.62E1D968-- --===============1541327199== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1541327199==-- From dime-bounces@ietf.org Fri Jun 15 06:12:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8md-000897-VL; Fri, 15 Jun 2007 06:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8mc-00088z-Uy for dime@ietf.org; Fri, 15 Jun 2007 06:11:58 -0400 Received: from webmail.datamat.it ([193.111.46.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hz8mc-0002if-Fw for dime@ietf.org; Fri, 15 Jun 2007 06:11:58 -0400 Received: (qmail 93876 invoked by uid 89); 15 Jun 2007 10:11:55 -0000 Message-ID: <20070615101155.93875.qmail@keycab.com> References: In-Reply-To: From: "marco.carusio" To: Nimish Bhargava Date: Fri, 15 Jun 2007 10:11:55 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: dime@ietf.org Subject: [Dime] Re: Relay supporting application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Nimish and Satendra, from RFC 3588 par. 1.3: "...relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any Diameter application or message type." In my understanding there is no need for implementing application support inside the relay, indeed it is not in charge of providing application functionalities. Anyway I guess there is not any restriction for providing to relays the capabilities of processing application level data. I don't know if I answered your question. Regards, Marco. Nimish Bhargava scrive: > Hi Satendra > > Please find my comments inline. > > Regards, > Nimish > > > > > "Satendra Gera (satgera)" > 06/15/2007 02:56 PM > > > To > Nimish Bhargava/HSS@HSS > cc > > Subject > RE: [Dime] Relay supporting application > > > > > > > Hi Nimish, > > IMO there is no restriction on support of applications on a relay node > (node supporting relay functionality). > I remember more than one implementations from last interop supporting > application in addition to relay functionality on the same node. > > > Could you please verify that the node was suppoting relay application also > (along with relay functionality). > > > It is common to have similar setup where a server serves requests for/from > local domain and relays the rest. > > > I do agree that a node can serve the requests from some domain and relay > the rest. > What I want to confirm is whether this node supports the relay application > also ? > > > > Regards, > Satendra > > From: Nimish Bhargava [mailto:nimish.bhargava@aricent.com] > Sent: Friday, June 15, 2007 12:48 PM > To: dime@ietf.org; vfajardo@tari.toshiba.com; tasveren@sonusnet.com > Subject: [Dime] Relay supporting application > > > Hi all, > > Can anyone provide information about whether the relay nodes can support > any application also? > > According to Specification 3588 section 2.8.1 last para > > "Since Relays do not perform any application level processing, they > provide relaying services for all Diameter applications, and > therefore MUST advertise the Relay Application Identifier." > > Does this mean that relay agents can never support any application above > them ? > > Regards, > Nimish > > > *********************** Aricent-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Aricent and is intended > solely for the use of > the individual to whom it is addressed. It may contain privileged or > confidential information and should not be > circulated or used for any purpose other than for what it is intended. If > you have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of > this message. Aricent accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus." > > > > > *********************** Aricent-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of > the individual to whom it is addressed. It may contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for > loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 15 08:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzB2U-00077o-3d; Fri, 15 Jun 2007 08:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzB2S-00077O-D2 for dime@ietf.org; Fri, 15 Jun 2007 08:36:28 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzB2Q-00065E-Ig for dime@ietf.org; Fri, 15 Jun 2007 08:36:28 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id ADF693600A7; Fri, 15 Jun 2007 18:04:53 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid 9435A3600A1; Fri, 15 Jun 2007 18:04:53 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 18:06:22 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Registering new Command Codes with IANA based on "ExpertReview" Date: Fri, 15 Jun 2007 18:05:39 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC60193CBEB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Registering new Command Codes with IANA based on "ExpertReview" Thread-Index: AceuAuIHOPDt/qI3QaOjXlUr0etQUwBRbszQ References: <46706335.7000507@gmx.net> From: "Arun Santhanam, TLS-Chennai" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 15 Jun 2007 12:36:22.0509 (UTC) FILETIME=[C7EE11D0:01C7AF49] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-10.9677 TC:1F TRN:42 TV:3.6.1039(15240.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, I think this is a good idea the Expert Team can review the request for Creation/Modification of the Command code as per the=20 http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-00. txt Doc. This will also ensures the effective re-usability of the Command codes.=20 Thx -Arun -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, June 14, 2007 3:06 AM To: dime@ietf.org Subject: [Dime] Registering new Command Codes with IANA based on "ExpertReview" Hi all, RFC 3588 describes that "IETF Consensus" is needed when registering a=20 new Command Code with IANA. That's fine if you develop a specification=20 in the IETF. It is, however, challenging when another SDOs extend Diameter but don't=20 want todo this within the IETF itself. What they then do is to avoid=20 creating a command code (and applications in general) but re-using=20 existing applications, such as Diameter NASREQ, and adding=20 vendor-specific AVPs. As one might guess the consequence is a hack. This can lead to interoperability problems. Now, in a chat between Dan, Victor and myself we thought about ways how=20 to change the current situation. We would like to have other SDOs to=20 extend Diameter in such a way that it does not cause interoperability=20 problems. One way is to improve the current situation is to change the=20 policy for registering Command Codes from "IETF Consensus" to "Expert=20 Review" (as part of the work on=20 http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt).=20 This would obviously require that we setup a expert review team in order to actually handle the incoming review requests. What do people think about the suggested change? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 15 08:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzB6u-0005Ko-4c; Fri, 15 Jun 2007 08:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzB6r-0004sb-WE for dime@ietf.org; Fri, 15 Jun 2007 08:41:02 -0400 Received: from mail.telenet-ag.de ([213.188.99.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzB6q-0007KX-HD for dime@ietf.org; Fri, 15 Jun 2007 08:41:01 -0400 Received: from notes.ip3k.de (notes.ip3k.de [193.96.234.114]) by mail.telenet-ag.de (8.12.8/8.12.8) with ESMTP id l5FCexDp016467 for ; Fri, 15 Jun 2007 14:40:59 +0200 To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: m.hillier@telenet-ag.de Date: Fri, 15 Jun 2007 14:40:57 +0200 X-MIMETrack: Serialize by Router on notes-rhm-1/telenet-ag/de(Release 6.5.4|March 27, 2005) at 15.06.2007 14:40:59, Serialize complete at 15.06.2007 14:40:59 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Dime] Route-Record in responses X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, from current work, I had to clarify the presence and use of Route-Record AVPs in Diameter Responses, in particular Credit-Control-Answer messages. Just to make sure, I double checked 3588 and Draft 3588bis-04 and as many AAA WG/DIME messages as I could! And I found no clarification and reference to any recent discussion. I have found text in the original drafts of 3588, but this was later removed - leaving the situation inconsistent (IMHO) Applications like NASREQ and CCA have included Route-Record AVPs in their responses, but say nothing about the values and the processing. And it is unclear to me whether the server reflects the received list of Route-Record AVPs and the relays and proxies on the return path "peel off" the AVPs one by one OR alternatively the server removes all Route-Record AVPs and each agent adds in the identity of the Diameter peer it received the answer from in a new Route-Record, before forwarding the response OR Route-Records are not used in answers. My best guess is that finally the conclusion had been drawn that answers do not include Route-Records (which leaves NASREQ and CCA up the spout) Regards Mike Michael Hillier Vodafone Group Technology Telenet AG Rhein-Main Mobile (Vodafone) +49 170 5454 121 M.Hillier@telenet-ag.de Michael.Hillier@vodafone.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 15 09:20:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBih-0002sX-SD; Fri, 15 Jun 2007 09:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBih-0002sN-1g for dime@ietf.org; Fri, 15 Jun 2007 09:20:07 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBif-0001EM-OD for dime@ietf.org; Fri, 15 Jun 2007 09:20:07 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5FDJmnB044643; Fri, 15 Jun 2007 09:19:48 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <467291F4.5000608@tari.toshiba.com> Date: Fri, 15 Jun 2007 09:19:48 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: m.hillier@telenet-ag.de Subject: Re: [Dime] Route-Record in responses References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Michael, Comments inline: > Hi all, > > from current work, I had to clarify the presence and use of Route-Record > AVPs in Diameter Responses, in particular Credit-Control-Answer messages. > Just to make sure, I double checked 3588 and Draft 3588bis-04 and as many > AAA WG/DIME messages as I could! > > And I found no clarification and reference to any recent discussion. > > I have found text in the original drafts of 3588, but this was later > removed - leaving the situation inconsistent (IMHO) > > Applications like NASREQ and CCA have included Route-Record AVPs in their > responses, but say nothing about the values and the processing. > > And it is unclear to me whether the server reflects the received list of > Route-Record AVPs and the relays and proxies on the return path "peel off" > the AVPs one by one > OR alternatively the server removes all Route-Record AVPs and each agent > adds in the identity of the Diameter peer it received the answer from in a > new Route-Record, before forwarding the response > OR Route-Records are not used in answers. > > My best guess is that finally the conclusion had been drawn that answers > do not include Route-Records (which leaves NASREQ and CCA up the spout) > I agree, assuming nasreq and cca does not use route recs beyond loop detection. Given that, rfc3588bis-04, Sec 2.9, 7th paragraph also state that answers carry route-records which I'm not sure what the purpose was so that may need to get cleaned up as well. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 15 09:35:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBxL-0003WK-DX; Fri, 15 Jun 2007 09:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBxK-0003U5-61 for dime@ietf.org; Fri, 15 Jun 2007 09:35:14 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBxI-0004qn-SI for dime@ietf.org; Fri, 15 Jun 2007 09:35:14 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l5FDZCUI029651 for ; Fri, 15 Jun 2007 09:35:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Route-Record in responses Date: Fri, 15 Jun 2007 09:35:12 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7187FA5@sonusmail04.sonusnet.com> In-Reply-To: <467291F4.5000608@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Route-Record in responses Thread-Index: AcevT+f0/CpMe70JQXG5C7q4K0ZpfAAAF0dQ References: <467291F4.5000608@tari.toshiba.com> From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I guess one possible use of Route-Record in the answers is to act based on the path the request has taken after the message has been sent/relayed by a Diameter entity; for example : ----- ----- +-----+ // \\ // \\ +-----+ | | | Realm | | Realm | | | | A +--------+ B +----+ C +-------+ D | | | | | | | | | +-----+ \\ // \\ // +-----+ ----- ----- A knows that it send the request to B but wouldn't know that it traversed C's network. That potentially may be useful information to A, e.g. sessions which go through C are subject to different policy in terms of recording, charging policy etc... Sometimes, this could be useful for troubleshooting as well. Relying on Route-Record assumes that all entities add it with proper values but this is the best we can get I guess. In terms of whether Route-Record needs to be recreated on the answer path, I would say it is a better approach that answerer includes all Route-Record AVPs received in the answer as well. If we want to use Route-Record only for loop detection, there is of course no need that answers have it. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Friday, June 15, 2007 9:20 AM > To: m.hillier@telenet-ag.de > Cc: dime@ietf.org > Subject: Re: [Dime] Route-Record in responses >=20 > Hi Michael, >=20 > Comments inline: >=20 > > Hi all, > > > > from current work, I had to clarify the presence and use of Route- > Record > > AVPs in Diameter Responses, in particular Credit-Control-Answer > messages. > > Just to make sure, I double checked 3588 and Draft 3588bis-04 and as > many > > AAA WG/DIME messages as I could! > > > > And I found no clarification and reference to any recent discussion. > > > > I have found text in the original drafts of 3588, but this was later > > removed - leaving the situation inconsistent (IMHO) > > > > Applications like NASREQ and CCA have included Route-Record AVPs in > their > > responses, but say nothing about the values and the processing. > > > > And it is unclear to me whether the server reflects the received list > of > > Route-Record AVPs and the relays and proxies on the return path "peel > off" > > the AVPs one by one > > OR alternatively the server removes all Route-Record AVPs and each > agent > > adds in the identity of the Diameter peer it received the answer from in > a > > new Route-Record, before forwarding the response > > OR Route-Records are not used in answers. > > > > My best guess is that finally the conclusion had been drawn that answers > > do not include Route-Records (which leaves NASREQ and CCA up the spout) > > >=20 > I agree, assuming nasreq and cca does not use route recs beyond loop > detection. Given that, rfc3588bis-04, Sec 2.9, 7th paragraph also state > that answers carry route-records which I'm not sure what the purpose was > so that may need to get cleaned up as well. >=20 > regards, > victor >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 15 09:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzC9Q-0004YD-8z; Fri, 15 Jun 2007 09:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzC9O-0004Y2-NF for dime@ietf.org; Fri, 15 Jun 2007 09:47:42 -0400 Received: from mail.telenet-ag.de ([213.188.99.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzC9L-0008An-Q2 for dime@ietf.org; Fri, 15 Jun 2007 09:47:42 -0400 Received: from notes.ip3k.de (notes.ip3k.de [193.96.234.114]) by mail.telenet-ag.de (8.12.8/8.12.8) with ESMTP id l5FDlcDp017392; Fri, 15 Jun 2007 15:47:38 +0200 In-Reply-To: <467291F4.5000608@tari.toshiba.com> To: Victor Fajardo Subject: Re: [Dime] Route-Record in responses MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: m.hillier@telenet-ag.de Date: Fri, 15 Jun 2007 15:47:37 +0200 X-MIMETrack: Serialize by Router on notes-rhm-1/telenet-ag/de(Release 6.5.4|March 27, 2005) at 15.06.2007 15:47:38, Serialize complete at 15.06.2007 15:47:38 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, all. as you say the 7th para of 2.9 would need cleaning up, I suspect it was missed when other text was removed. Also there is an inconsistency for presence of Route-Record in ACA between the AVP table 10.2 (showing 0+) and the ABNF in 9.7.2. (absent) I presume the 0+ should be 0. (even though the table is qualified as being guidelines) regards Mike Victor Fajardo 15.06.2007 15:19 To m.hillier@telenet-ag.de cc dime@ietf.org Subject Re: [Dime] Route-Record in responses Hi Michael, Comments inline: > Hi all, > > from current work, I had to clarify the presence and use of Route-Record > AVPs in Diameter Responses, in particular Credit-Control-Answer messages. > Just to make sure, I double checked 3588 and Draft 3588bis-04 and as many > AAA WG/DIME messages as I could! > > And I found no clarification and reference to any recent discussion. > > I have found text in the original drafts of 3588, but this was later > removed - leaving the situation inconsistent (IMHO) > > Applications like NASREQ and CCA have included Route-Record AVPs in their > responses, but say nothing about the values and the processing. > > And it is unclear to me whether the server reflects the received list of > Route-Record AVPs and the relays and proxies on the return path "peel off" > the AVPs one by one > OR alternatively the server removes all Route-Record AVPs and each agent > adds in the identity of the Diameter peer it received the answer from in a > new Route-Record, before forwarding the response > OR Route-Records are not used in answers. > > My best guess is that finally the conclusion had been drawn that answers > do not include Route-Records (which leaves NASREQ and CCA up the spout) > I agree, assuming nasreq and cca does not use route recs beyond loop detection. Given that, rfc3588bis-04, Sec 2.9, 7th paragraph also state that answers carry route-records which I'm not sure what the purpose was so that may need to get cleaned up as well. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jun 17 07:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzsXO-0002vW-KY; Sun, 17 Jun 2007 07:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzsXN-0002q4-Rc for dime@ietf.org; Sun, 17 Jun 2007 07:03:17 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzsXM-0002OM-3j for dime@ietf.org; Sun, 17 Jun 2007 07:03:17 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 13:02:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter auditing - PART 1 Date: Sun, 17 Jun 2007 13:02:04 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02604A2C3C7@FTRDMEL2.rd.francetelecom.fr> In-Reply-To: <33656995C5C5094A983DE84DA649A92401590C17@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter auditing - PART 1 Thread-Index: Acep5dCmWImxFqp+QR20+AFV7RfBYAFXPKmw References: <33656995C5C5094A983DE84DA649A92401590C17@lulex02.ad.operax.com> From: "MORAND Lionel RD-CORE-ISS" To: "Ulf Bodin" , X-OriginalArrivalTime: 17 Jun 2007 11:02:08.0554 (UTC) FILETIME=[F2BC80A0:01C7B0CE] X-Spam-Score: 0.1 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0374415905==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0374415905== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B0CE.F8938CD8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B0CE.F8938CD8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ulf, =20 Some comments below. =20 BR, =20 Lionel ________________________________ De : Ulf Bodin [mailto:Ulf.Bodin@operax.com]=20 Envoy=E9 : vendredi 8 juin 2007 17:58 =C0 : dime@ietf.org Objet : [Dime] Diameter auditing - PART 1=20 =09 =09 All,=20 I've been looking in whether the original work on Diameter resource = management extensions now captured in = http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.txt= = [RM-ext] would meet the demands identified in = http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01.= txt = [SR] on Diameter state recovery considerations. Comments on this = analyze are very wellcome.=20 Going through section 5.2.1 and 5.2.2 (PART 1) of [SR] and matching = against [RM-ext] I noted the following (remaing sections/PARTs in = following mail):=20 1) Having a standby node informing remote peers of the failure of an = active instance (i.e. 5.2.1 in [SR]) is not covered by [RM-ext], not in = any other spec (as far as I know). I'm not sure what kind of message = would be appropriate for this purpose (i.e. a new mesage or an existing = one such as CER). Any views on this?=20 [Lionel Morand] CER/CEA are used to initiate a transport connection = between diameter peers. In this specific case, we may assume that the = Standby node may actually also indicate the active instance failure by = sending a CER to the remote peers. The transport connection = establishment would be a hint for the remote peers to detect that the = Standby node is now active and that therefore the previous active node = is down. The only problem is that CER/CAA messages can not be proxied, = redirected or relayed i.e. it would be not possible to use this = mechanism if a proxy/redirect/relay agent is present in the Diameter = path between remote peers and Stanby/active node. This can not be = therefore defined as a generic mechanism.=20 2) Synchronizing state (i.e. 5.2.2, first paragraph in [SR]) is not = natively supported by [RM-ext], but could be suppored with a small = change/addition I beleive. E.g. through a flag in the SRQ saying whether = all session information is requested for all active sessions (all = information on all sessions is requested when no Session-Id is provided = in the SRQ), or just the session-Id of all active sesisons (i.e. an SRR = without any Resource-bag AVPs).=20 [Lionel Morand] if needed, I think that this could be easily fulfilled = with an optional AVP in SQR e.g. "State Synchronization AVP" of = Enumarated type, that would clearly indicate the granularity of = requested information about active sessions. 3) Reconstructing session state using application messages (i.e. 5.2.2, = Using Application Messages in [SR]) is generally not supported by = Diameter nor in [RM-ext]. As I understand the protocol a AAR updating an = existing session is identified by that the Session-Id is known by the = server (i.e. is active), while an AAR establishing a new session = provides a new Session-Id not currently being used for any active = session. Hence, a flag indicating that the message is for an existing = sesison (or a separate message) would be needed to facilitate state = reconstruction using mid-session messages. =20 4) Reconstructing session state using generic messages (i.e. 5.2.2, = Using a Generic Message in [SR]) is indeed supported by [RM-ext] (i.e. = through SRQ and SRR in which state information for several sessions can = be requested and provided respectively).=20 Best regards, Ulf=20 ------_=_NextPart_001_01C7B0CE.F8938CD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Diameter auditing - PART 1
Hi Ulf,
 
Some comments below.
 
BR,
 
Lionel

De : Ulf Bodin=20 [mailto:Ulf.Bodin@operax.com]
Envoy=E9 : vendredi 8 = juin 2007=20 17:58
=C0 : dime@ietf.org
Objet : [Dime] = Diameter=20 auditing - PART 1

All,

I've been looking in = whether the=20 original work on Diameter resource management extensions now captured = in=20 http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-re= qs-02.txt [RM-ext] would meet the demands = identified in=20 http://www.ietf.org/internet-drafts/draft-asveren-dime-state-rec= overy-01.txt [SR] on Diameter state recovery = considerations. Comments on this analyze are very wellcome. =

Going through section = 5.2.1 and 5.2.2=20 (PART 1) of [SR] and matching against [RM-ext] I noted the following = (remaing=20 sections/PARTs in following mail):

1) Having a = standby node=20 informing remote peers of the failure of an active instance (i.e. = 5.2.1 in=20 [SR]) is not covered by [RM-ext], not in any other spec (as far as I = know).=20 I'm not sure what kind of message would be appropriate for this = purpose (i.e.=20 a new mesage or an existing one such as CER). Any views on this? =
[Lionel = Morand] CER/CEA are=20 used to initiate a transport connection between diameter peers. In = this=20 specific case, we may assume that the Standby node may = actually also=20 indicate the active instance failure by sending a CER to the remote = peers. The=20 transport connection establishment would be a hint for the remote = peers to=20 detect that the Standby node is now active and that = therefore the=20 previous active node is down. The only problem is that CER/CAA = messages can=20 not be proxied, redirected or relayed i.e. it would be not possible to = use=20 this mechanism if a proxy/redirect/relay agent is present in the = Diameter path=20 between remote peers and Stanby/active node. This can not be = therefore=20 defined as a generic = mechanism. 

2) Synchronizing = state (i.e.=20 5.2.2, first paragraph in [SR]) is not natively supported by [RM-ext], = but=20 could be suppored with a small change/addition I beleive. E.g. through = a flag=20 in the SRQ saying whether all session information is requested for all = active=20 sessions (all information on all sessions is requested when no = Session-Id is=20 provided in the SRQ), or just the session-Id of all active sesisons = (i.e. an=20 SRR without any Resource-bag AVPs).
[Lionel Morand] if needed, I think that this = could be=20 easily fulfilled with an optional AVP in SQR e.g. "State = Synchronization AVP"=20 of Enumarated type, that would clearly indicate the granularity of = requested=20 information about active = sessions.

3) Reconstructing = session state=20 using application messages (i.e. 5.2.2, Using Application Messages in = [SR]) is=20 generally not supported by Diameter nor in [RM-ext]. As I understand = the=20 protocol a AAR updating an existing session is identified by that the=20 Session-Id is known by the server (i.e. is active), while an AAR = establishing=20 a new session provides a new Session-Id not currently being used for = any=20 active session. Hence, a flag indicating that the message is for an = existing=20 sesison (or a separate message) would be needed to facilitate state=20 reconstruction using mid-session messages.  

4) Reconstructing = session state using=20 generic messages (i.e. 5.2.2, Using a Generic Message in [SR]) is = indeed=20 supported by [RM-ext] (i.e. through SRQ and SRR in which state = information for=20 several sessions can be requested and provided respectively).=20

Best regards,
Ulf=20



------_=_NextPart_001_01C7B0CE.F8938CD8-- --===============0374415905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0374415905==-- From dime-bounces@ietf.org Sun Jun 17 23:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08Cv-0006ph-6S; Sun, 17 Jun 2007 23:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08Cu-0006pc-IK for dime@ietf.org; Sun, 17 Jun 2007 23:47:12 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I08Cr-0000eC-5d for dime@ietf.org; Sun, 17 Jun 2007 23:47:12 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5I3gri6021228 for ; Mon, 18 Jun 2007 09:12:54 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5I3gpuf021196; Mon, 18 Jun 2007 09:12:53 +0530 Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 From: Nimish Bhargava To: "marco.carusio" Date: Mon, 18 Jun 2007 09:20:47 +0530 Message-ID: X-Mailer: Lotus Domino Web Server Build V655_10312005 October 31, 2005 X-MIMETrack: Serialize by Notes Server on Presidency/HSS(Build V655_10312005|October 31, 2005) at 06/18/2007 09:20:47 AM, Serialize complete at 06/18/2007 09:20:47 AM, Itemize by Notes Server on Presidency/HSS(Build V655_10312005|October 31, 2005) at 06/18/2007 09:20:47 AM, Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 18/06/2007 09:20:54 AM, Serialize complete at 18/06/2007 09:20:54 AM MIME-Version: 1.0 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: dime@ietf.org Subject: [Dime] Re: Relay supporting application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1159137974==" Errors-To: dime-bounces@ietf.org --===============1159137974== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi=20Marco

I=20have=20a=20concern=20that=20if=20we=20start=20= providing=20application=20support=20at=20a=20node=20supporting=20relay=20= application=20then=20the=20node=20will=20be=20required=20to=20parse=20eve= ry=20message=20that=20it=20receives.=20Then,=20that=20shall=20lead=20to= =20violation=20of=20specifications=20as=20the=20relay=20node=20should=20n= ot=20parse=20the=20message=20it=20receives.

Regards,
Nimis= h



-----"marco.carusio= "=20<marco.carusio@datamat.it>=20wrote:=20-----

To:=20Nimish=20Bhargava/HSS@HSS
From:=20"marco.carusio"=20= <marco.carusio@datamat.it>
Date:=2006/15/2007=2003:41PM
cc:= =20"Satendra=20Gera=20\(satgera\)"=20<satgera@cisco.com>,=20dime@ie= tf.org
Subject:=20Re:=20Relay=20supporting=20application

Hi=20Nimish=20and=20Satendra,

f= rom=20RFC=203588=20par.=201.3:=20

"...relays=20never=20originate= =20messages,=20do=20not=20need=20to
understand=20the=20semantics=20of= =20messages=20or=20non-routing=20AVPs,=20and=20are
capable=20of=20hand= ling=20any=20Diameter=20application=20or=20message=20type."=20

In= =20my=20understanding=20there=20is=20no=20need=20for=20implementing=20app= lication=20support=20
inside=20the=20relay,=20indeed=20it=20is=20not= =20in=20charge=20of=20providing=20application=20
functionalities.
A= nyway=20I=20guess=20there=20is=20not=20any=20restriction=20for=20providin= g=20to=20relays=20the=20
capabilities=20of=20processing=20application= =20level=20data.=20

I=20don't=20know=20if=20I=20answered=20your=20= question.=20

Regards,
Marco.=20


Nimish=20Bhargava=20= scrive:=20

>=20Hi=20Satendra=20
>=20
>=20Please=20f= ind=20my=20comments=20inline.=20
>=20
>=20Regards,
>=20= Nimish=20
>=20
>=20 
>=20
>=20
>=20"Sa= tendra=20Gera=20(satgera)"=20=20
>=2006/15/2007= =2002:56=20PM=20
>=20
>=20
>=20To
>=20Nimish=20Bh= argava/HSS@HSS
>=20cc
>=20
>=20Subject>=20RE:=20[Dime]=20Relay=20supporting=20application=20
>=20>=20 
>=20
>=20 
>=20
>=20
>= =20Hi=20Nimish,
>=20 
>=20IMO=20there=20is=20no=20restri= ction=20on=20support=20of=20applications=20on=20a=20relay=20node=20
&g= t;=20(node=20supporting=20relay=20functionality).
>=20I=20remember= =20more=20than=20one=20implementations=20from=20last=20interop=20supporti= ng=20
>=20application=20in=20addition=20to=20relay=20functionality= =20on=20the=20same=20node.=20
>=20
>=20
>=20Cou= ld=20you=20please=20verify=20that=20the=20node=20was=20suppoting=20relay= =20application=20also=20
>=20(along=20with=20relay=20functionality)= .
>=20=20
>=20
>=20It=20is=20common=20to=20hav= e=20similar=20setup=20where=20a=20server=20serves=20requests=20for/from= =20
>=20local=20domain=20and=20relays=20the=20rest.=20 
>= ;=20
>=20
>=20I=20do=20agree=20that=20a=20node=20can= =20serve=20the=20requests=20from=20some=20domain=20and=20relay=20
>= =20the=20rest.=20
>=20What=20I=20want=20to=20confirm=20is=20whether= =20this=20node=20supports=20the=20relay=20application=20
>=20also= =20?
>=20=20
>=20
>=20 
>=20Regards= ,
>=20Satendra=20
>=20
>=20From:=20Nimish=20Bhargava=20= [mailto:nimish.bhargava@aricent.com]=20
>=20Sent:= =20Friday,=20June=2015,=202007=2012:48=20PM
>=20To:=20dime@ietf.org= ;=20vfajardo@tari.toshiba.com;=20tasveren@sonusnet.com
>=20Subject:= =20[Dime]=20Relay=20supporting=20application=20
>=20
>=20
= >=20Hi=20all,=20 
>=20
>=20Can=20anyone=20provide=20i= nformation=20about=20whether=20the=20relay=20nodes=20can=20support=20
= >=20any=20application=20also?=20 
>=20
>=20According= =20to=20Specification=203588=20section=202.8.1=20last=20para=20 
= >=20
>=20"Since=20Relays=20do=20not=20perform=20any=20applicatio= n=20level=20processing,=20they=20
>=20 =20 provide=20rela= ying=20services=20for=20all=20Diameter=20applications,=20and=20
>= =20 =20 therefore=20MUST=20advertise=20the=20Relay=20Applicatio= n=20Identifier."=20 
>=20
>=20Does=20this=20mean=20that= =20relay=20agents=20can=20never=20support=20any=20application=20above=20<= br>>=20them=20?=20 
>=20
>=20Regards,
>=20Nimis= h=20
>=20
>=20
>=20***********************=20 Aric= ent-Unclassified=20 =20***********************=20
>=20"DISCLAI= MER:=20This=20message=20is=20proprietary=20to=20Aricent=20 and=20is= =20intended=20
>=20solely=20for=20the=20use=20of=20
>=20the= =20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20p= rivileged=20or=20
>=20confidential=20information=20and=20should=20n= ot=20be=20
>=20circulated=20or=20used=20for=20any=20purpose=20other= =20than=20for=20what=20it=20is=20intended.=20If=20
>=20you=20have= =20received=20this=20message=20in=20error,=20
>=20please=20notify= =20the=20originator=20immediately.=20If=20you=20are=20not=20the=20intende= d=20
>=20recipient,=20you=20are=20notified=20that=20you=20are=20str= ictly
>=20prohibited=20from=20using,=20copying,=20altering,=20or=20= disclosing=20the=20contents=20of=20
>=20this=20message.=20Aricent= =20accepts=20no=20responsibility=20for=20
>=20loss=20or=20damage=20= arising=20from=20the=20use=20of=20the=20information=20transmitted=20by=20= this=20
>=20email=20including=20damage=20from=20virus."=20
>= =20
>=20 
>=20
>=20
>=20********************= ***=20 Aricent-Unclassified=20 =20***********************
&g= t;=20"DISCLAIMER:=20This=20message=20is=20proprietary=20to=20Aricent=20&n= bsp;and=20is=20intended=20solely=20for=20the=20use=20of=20
>=20the= =20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20p= rivileged=20or=20confidential=20information=20and=20should=20not=20be=20<= br>>=20circulated=20or=20used=20for=20any=20purpose=20other=20than=20f= or=20what=20it=20is=20intended.=20If=20you=20have=20received=20this=20mes= sage=20in=20error,=20
>=20please=20notify=20the=20originator=20imme= diately.=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are= =20notified=20that=20you=20are=20strictly
>=20prohibited=20from=20u= sing,=20copying,=20altering,=20or=20disclosing=20the=20contents=20of=20th= is=20message.=20Aricent=20accepts=20no=20responsibility=20for=20
>= =20loss=20or=20damage=20arising=20from=20the=20use=20of=20the=20informati= on=20transmitted=20by=20this=20email=20including=20damage=20from=20virus.= "
=20
=0D=0A

*****Aricent-Un= classified=20*****=3D=0D=0A
"DISCLAIMER:=20This=20message=20is=20proprietary=20to=
=20Aricent=20=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0A=
the=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=
=20privileged=20or=20confidential=20information=20and=20should=20not=20be=
=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20for=
=20what=20it=20is=20intended.=20If=20you=20have=20received=20this=20messa=
ge=20in=20error,=20=0Aplease=20notify=20the=20originator=20immediately.=
=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20notif=
ied=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,=
=20altering,=20or=20disclosing=20the=20contents=20of=20this=20message.=20=
Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20a=
rising=20from=20the=20use=20of=20the=20information=20transmitted=20by=20t=
his=20email=20including=20damage=20from=20virus."=0A
--===============1159137974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1159137974==-- From dime-bounces@ietf.org Mon Jun 18 01:03:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09P4-0003iK-VV; Mon, 18 Jun 2007 01:03:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09P4-0003h8-B4 for dime@ietf.org; Mon, 18 Jun 2007 01:03:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I09P3-0006YG-FR for dime@ietf.org; Mon, 18 Jun 2007 01:03:50 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 17 Jun 2007 22:03:49 -0700 X-IronPort-AV: i="4.16,432,1175497200"; d="scan'208,217"; a="380044332:sNHT119337906" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5I53m8F021877; Sun, 17 Jun 2007 22:03:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5I53laI004244; Mon, 18 Jun 2007 05:03:47 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 22:03:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Re: Relay supporting application Date: Sun, 17 Jun 2007 22:03:54 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625042850CD@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Relay supporting application Thread-Index: AcexW2maVi9VDFIrRwyBHvi5NFTlTgACgoUA References: From: "Glen Zorn \(gwz\)" To: "Nimish Bhargava" X-OriginalArrivalTime: 18 Jun 2007 05:03:47.0416 (UTC) FILETIME=[0D78F580:01C7B166] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14038; t=1182143028; x=1183007028; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Re=3A=20Relay=20supporting=20application |Sender:=20; bh=tNVmdtCIeUOmolCP49Mbn+3hDhjfSK9pPfH4Zl0NdXM=; b=RWI7/VnNdcWmsK8fqfjg0YQPI5KNJolF6vJIkaI18OsvWKDW2N032OkJ9B7g3/PdOyiGuzxV 5Y3kPsR2joRONv1eFSZp7dyjbijJPFuOcKESsdk5Qjb+C6PTWBlyERir; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1901479323==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1901479323== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B166.0D391124" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B166.0D391124 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marco I have a concern that if we start providing application support at a node supporting relay application then the node will be required to parse every message that it receives. Then, that shall lead to violation of specifications as the relay node should not parse the message it receives.=20 Would you mind defining the term "node" as you are using it? =20 Regards, Nimish -----"marco.carusio" wrote: ----- To: Nimish Bhargava/HSS@HSS From: "marco.carusio" Date: 06/15/2007 03:41PM cc: "Satendra Gera \(satgera\)" , dime@ietf.org Subject: Re: Relay supporting application =09 Hi Nimish and Satendra, =09 from RFC 3588 par. 1.3:=20 =09 "...relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any Diameter application or message type."=20 =09 In my understanding there is no need for implementing application support=20 inside the relay, indeed it is not in charge of providing application=20 functionalities. Anyway I guess there is not any restriction for providing to relays the=20 capabilities of processing application level data.=20 =09 I don't know if I answered your question.=20 =09 Regards, Marco.=20 =09 =09 Nimish Bhargava scrive:=20 =09 > Hi Satendra=20 >=20 > Please find my comments inline.=20 >=20 > Regards, > Nimish=20 >=20 > =20 >=20 >=20 > "Satendra Gera (satgera)"=20 > 06/15/2007 02:56 PM=20 >=20 >=20 > To > Nimish Bhargava/HSS@HSS > cc >=20 > Subject > RE: [Dime] Relay supporting application=20 >=20 > =20 >=20 > =20 >=20 >=20 > Hi Nimish, > =20 > IMO there is no restriction on support of applications on a relay node=20 > (node supporting relay functionality). > I remember more than one implementations from last interop supporting=20 > application in addition to relay functionality on the same node.=20 >=20 >=20 > Could you please verify that the node was suppoting relay application also=20 > (along with relay functionality). >=20 >=20 > It is common to have similar setup where a server serves requests for/from=20 > local domain and relays the rest. =20 >=20 >=20 > I do agree that a node can serve the requests from some domain and relay=20 > the rest.=20 > What I want to confirm is whether this node supports the relay application=20 > also ? >=20 >=20 > =20 > Regards, > Satendra=20 >=20 > From: Nimish Bhargava [mailto:nimish.bhargava@aricent.com]=20 > Sent: Friday, June 15, 2007 12:48 PM > To: dime@ietf.org; vfajardo@tari.toshiba.com; tasveren@sonusnet.com > Subject: [Dime] Relay supporting application=20 >=20 >=20 > Hi all, =20 >=20 > Can anyone provide information about whether the relay nodes can support=20 > any application also? =20 >=20 > According to Specification 3588 section 2.8.1 last para =20 >=20 > "Since Relays do not perform any application level processing, they=20 > provide relaying services for all Diameter applications, and=20 > therefore MUST advertise the Relay Application Identifier." >=20 > Does this mean that relay agents can never support any application above=20 > them ? =20 >=20 > Regards, > Nimish=20 >=20 >=20 > *********************** Aricent-Unclassified ***********************=20 > "DISCLAIMER: This message is proprietary to Aricent and is intended=20 > solely for the use of=20 > the individual to whom it is addressed. It may contain privileged or=20 > confidential information and should not be=20 > circulated or used for any purpose other than for what it is intended. If=20 > you have received this message in error,=20 > please notify the originator immediately. If you are not the intended=20 > recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of=20 > this message. Aricent accepts no responsibility for=20 > loss or damage arising from the use of the information transmitted by this=20 > email including damage from virus."=20 >=20 > =20 >=20 >=20 > *********************** Aricent-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of=20 > the individual to whom it is addressed. It may contain privileged or confidential information and should not be=20 > circulated or used for any purpose other than for what it is intended. If you have received this message in error,=20 > please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for=20 > loss or damage arising from the use of the information transmitted by this email including damage from virus." =09 =09 *****Aricent-Unclassified *****=3D=20 "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. If you have received this message in error,=20 please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by this email including damage from virus." ------_=_NextPart_001_01C7B166.0D391124 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Marco

I have a concern that if we = start=20 providing application support at a node supporting relay application = then the=20 node will be required to parse every message that it receives. Then, = that shall=20 lead to violation of specifications as the relay node should not parse = the=20 message it receives. 
Would you mind defining the term "node" as = you are=20 using it? =20

Regards,
Nimish



-----"marco.carusio"=20 <marco.carusio@datamat.it> wrote: -----

 To:=20 Nimish Bhargava/HSS@HSS
From: "marco.carusio"=20 <marco.carusio@datamat.it>
Date: 06/15/2007 03:41PM
cc: = "Satendra=20 Gera \(satgera\)" <satgera@cisco.com>, dime@ietf.org
Subject: = Re:=20 Relay supporting application

Hi = Nimish and=20 Satendra,

from RFC 3588 par. 1.3:

"...relays never = originate=20 messages, do not need to
understand the semantics of messages or=20 non-routing AVPs, and are
capable of handling any Diameter = application or=20 message type."

In my understanding there is no need for = implementing=20 application support
inside the relay, indeed it is not in charge = of=20 providing application
functionalities.
Anyway I guess there is = not any=20 restriction for providing to relays the
capabilities of processing = application level data.

I don't know if I answered your = question.=20

Regards,
Marco.


Nimish Bhargava scrive: =

> Hi=20 Satendra
>
> Please find my comments inline.
> =
>=20 Regards,
> Nimish
>
>  
>
> =
>=20 "Satendra Gera (satgera)"
> 06/15/2007 02:56 = PM=20
>
>
> To
> Nimish Bhargava/HSS@HSS
>=20 cc
>
> Subject
> RE: [Dime] Relay = supporting=20 application
>
>  
>
>  
> =
>=20
> Hi Nimish,
>  
> IMO there is no restriction = on=20 support of applications on a relay node
> (node supporting = relay=20 functionality).
> I remember more than one implementations from = last=20 interop supporting
> application in addition to relay = functionality on=20 the same node.
>
>
> Could you please = verify that=20 the node was suppoting relay application also
> (along with = relay=20 functionality).
>
>
> It is common to = have=20 similar setup where a server serves requests for/from
> local = domain=20 and relays the rest.  
>
>
> I do = agree that=20 a node can serve the requests from some domain and relay
> the = rest.=20
> What I want to confirm is whether this node supports the = relay=20 application
> also ?
>
>
> =  
>=20 Regards,
> Satendra
>
> From: Nimish Bhargava=20 [mailto:nimish.bhargava@aricen= t.com]=20
> Sent: Friday, June 15, 2007 12:48 PM
> To: = dime@ietf.org;=20 vfajardo@tari.toshiba.com; tasveren@sonusnet.com
> Subject: = [Dime] Relay=20 supporting application
>
>
> Hi all, =  
>=20
> Can anyone provide information about whether the relay nodes = can=20 support
> any application also?  
>
> = According to=20 Specification 3588 section 2.8.1 last para  
>
> = "Since=20 Relays do not perform any application level processing, they
> =  =20  provide relaying services for all Diameter applications, and =
>=20    therefore MUST advertise the Relay Application = Identifier."=20  
>
> Does this mean that relay agents can never = support any=20 application above
> them ?  
>
> = Regards,
>=20 Nimish
>
>
> ***********************=20  Aricent-Unclassified   ***********************
>=20 "DISCLAIMER: This message is proprietary to Aricent  and is = intended=20
> solely for the use of
> the individual to whom it is=20 addressed. It may contain privileged or
> confidential = information and=20 should not be
> circulated or used for any purpose other than = for what=20 it is intended. If
> you have received this message in error, =
>=20 please notify the originator immediately. If you are not the intended =
>=20 recipient, you are notified that you are strictly
> prohibited = from=20 using, copying, altering, or disclosing the contents of
> this = message.=20 Aricent accepts no responsibility for
> loss or damage arising = from the=20 use of the information transmitted by this
> email including = damage=20 from virus."
>
>  
>
>
>=20 ***********************  Aricent-Unclassified  =20 ***********************
> "DISCLAIMER: This message is = proprietary to=20 Aricent  and is intended solely for the use of
> the = individual to=20 whom it is addressed. It may contain privileged or confidential = information=20 and should not be
> circulated or used for any purpose other = than for=20 what it is intended. If you have received this message in error, =
>=20 please notify the originator immediately. If you are not the intended=20 recipient, you are notified that you are strictly
> prohibited = from=20 using, copying, altering, or disclosing the contents of this message. = Aricent=20 accepts no responsibility for
> loss or damage arising from the = use of=20 the information transmitted by this email including damage from=20 = virus."



*****Aricent-Uncla= ssified=20 *****=3D=20 
"DISCLAIMER: This =
message is proprietary to Aricent  and is intended solely for the use of =

the individual to whom it is addressed. It may contain privileged or =
confidential information and should not be=20
circulated or used for any purpose other than for what it is intended. =
If you have received this message in error,=20
please notify the originator immediately. If you are not the intended =
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of =
this message. Aricent accepts no responsibility for=20
loss or damage arising from the use of the information transmitted by =
this email including damage from virus."
------_=_NextPart_001_01C7B166.0D391124-- --===============1901479323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1901479323==-- From dime-bounces@ietf.org Mon Jun 18 01:14:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09ZG-0006Db-25; Mon, 18 Jun 2007 01:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09ZD-0006DA-6C for dime@ietf.org; Mon, 18 Jun 2007 01:14:19 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I09Yq-0001Rm-ND for dime@ietf.org; Mon, 18 Jun 2007 01:14:18 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5I59fqO008224 for ; Mon, 18 Jun 2007 10:39:41 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5I59eft008204; Mon, 18 Jun 2007 10:39:40 +0530 In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625042850CD@xmb-sjc-215.amer.cisco.com> To: "Glen Zorn \(gwz\)" Subject: RE: [Dime] Re: Relay supporting application MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Nimish Bhargava Date: Mon, 18 Jun 2007 10:47:34 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 18/06/2007 10:47:39 AM, Serialize complete at 18/06/2007 10:47:39 AM X-Spam-Score: 0.2 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1767046409==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1767046409== Content-Type: multipart/alternative; boundary="=_alternative 001D0AAA652572FE_=" This is a multipart message in MIME format. --=_alternative 001D0AAA652572FE_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgR2xlbg0KDQpJIGFtIGRlbm90aW5nIGEgImRpYW1ldGVyIGFnZW50IiBhcyBhIG5vZGUuDQoN ClJlZ2FyZHMsDQpOaW1pc2gNCg0KDQoNCg0KDQoiR2xlbiBab3JuIFwoZ3d6XCkiIDxnd3pAY2lz Y28uY29tPiANCjA2LzE4LzIwMDcgMTA6MzMgQU0NCg0KDQpUbw0KTmltaXNoIEJoYXJnYXZhL0hT U0BIU1MNCmNjDQo8ZGltZUBpZXRmLm9yZz4sICJtYXJjby5jYXJ1c2lvIiA8bWFyY28uY2FydXNp b0BkYXRhbWF0Lml0Pg0KU3ViamVjdA0KUkU6IFtEaW1lXSBSZTogUmVsYXkgc3VwcG9ydGluZyBh cHBsaWNhdGlvbg0KDQoNCg0KDQoNCg0KSGkgTWFyY28NCg0KSSBoYXZlIGEgY29uY2VybiB0aGF0 IGlmIHdlIHN0YXJ0IHByb3ZpZGluZyBhcHBsaWNhdGlvbiBzdXBwb3J0IGF0IGEgbm9kZSANCnN1 cHBvcnRpbmcgcmVsYXkgYXBwbGljYXRpb24gdGhlbiB0aGUgbm9kZSB3aWxsIGJlIHJlcXVpcmVk IHRvIHBhcnNlIGV2ZXJ5IA0KbWVzc2FnZSB0aGF0IGl0IHJlY2VpdmVzLiBUaGVuLCB0aGF0IHNo YWxsIGxlYWQgdG8gdmlvbGF0aW9uIG9mIA0Kc3BlY2lmaWNhdGlvbnMgYXMgdGhlIHJlbGF5IG5v ZGUgc2hvdWxkIG5vdCBwYXJzZSB0aGUgbWVzc2FnZSBpdCByZWNlaXZlcy4gDQoNCldvdWxkIHlv dSBtaW5kIGRlZmluaW5nIHRoZSB0ZXJtICJub2RlIiBhcyB5b3UgYXJlIHVzaW5nIGl0PyAgDQoN ClJlZ2FyZHMsDQpOaW1pc2gNCg0KDQoNCi0tLS0tIm1hcmNvLmNhcnVzaW8iIDxtYXJjby5jYXJ1 c2lvQGRhdGFtYXQuaXQ+IHdyb3RlOiAtLS0tLQ0KDQpUbzogTmltaXNoIEJoYXJnYXZhL0hTU0BI U1MNCkZyb206ICJtYXJjby5jYXJ1c2lvIiA8bWFyY28uY2FydXNpb0BkYXRhbWF0Lml0Pg0KRGF0 ZTogMDYvMTUvMjAwNyAwMzo0MVBNDQpjYzogIlNhdGVuZHJhIEdlcmEgXChzYXRnZXJhXCkiIDxz YXRnZXJhQGNpc2NvLmNvbT4sIGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSZWxheSBzdXBw b3J0aW5nIGFwcGxpY2F0aW9uDQoNCkhpIE5pbWlzaCBhbmQgU2F0ZW5kcmEsDQoNCmZyb20gUkZD IDM1ODggcGFyLiAxLjM6IA0KDQoiLi4ucmVsYXlzIG5ldmVyIG9yaWdpbmF0ZSBtZXNzYWdlcywg ZG8gbm90IG5lZWQgdG8NCnVuZGVyc3RhbmQgdGhlIHNlbWFudGljcyBvZiBtZXNzYWdlcyBvciBu b24tcm91dGluZyBBVlBzLCBhbmQgYXJlDQpjYXBhYmxlIG9mIGhhbmRsaW5nIGFueSBEaWFtZXRl ciBhcHBsaWNhdGlvbiBvciBtZXNzYWdlIHR5cGUuIiANCg0KSW4gbXkgdW5kZXJzdGFuZGluZyB0 aGVyZSBpcyBubyBuZWVkIGZvciBpbXBsZW1lbnRpbmcgYXBwbGljYXRpb24gc3VwcG9ydCANCmlu c2lkZSB0aGUgcmVsYXksIGluZGVlZCBpdCBpcyBub3QgaW4gY2hhcmdlIG9mIHByb3ZpZGluZyBh cHBsaWNhdGlvbiANCmZ1bmN0aW9uYWxpdGllcy4NCkFueXdheSBJIGd1ZXNzIHRoZXJlIGlzIG5v dCBhbnkgcmVzdHJpY3Rpb24gZm9yIHByb3ZpZGluZyB0byByZWxheXMgdGhlIA0KY2FwYWJpbGl0 aWVzIG9mIHByb2Nlc3NpbmcgYXBwbGljYXRpb24gbGV2ZWwgZGF0YS4gDQoNCkkgZG9uJ3Qga25v dyBpZiBJIGFuc3dlcmVkIHlvdXIgcXVlc3Rpb24uIA0KDQpSZWdhcmRzLA0KTWFyY28uIA0KDQoN Ck5pbWlzaCBCaGFyZ2F2YSBzY3JpdmU6IA0KDQo+IEhpIFNhdGVuZHJhIA0KPiANCj4gUGxlYXNl IGZpbmQgbXkgY29tbWVudHMgaW5saW5lLiANCj4gDQo+IFJlZ2FyZHMsDQo+IE5pbWlzaCANCj4g DQo+IA0KPiANCj4gDQo+ICJTYXRlbmRyYSBHZXJhIChzYXRnZXJhKSIgDQo+IDA2LzE1LzIwMDcg MDI6NTYgUE0gDQo+IA0KPiANCj4gVG8NCj4gTmltaXNoIEJoYXJnYXZhL0hTU0BIU1MNCj4gY2MN Cj4gDQo+IFN1YmplY3QNCj4gUkU6IFtEaW1lXSBSZWxheSBzdXBwb3J0aW5nIGFwcGxpY2F0aW9u IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBIaSBOaW1pc2gsDQo+IA0KPiBJTU8gdGhlcmUg aXMgbm8gcmVzdHJpY3Rpb24gb24gc3VwcG9ydCBvZiBhcHBsaWNhdGlvbnMgb24gYSByZWxheSBu b2RlIA0KPiAobm9kZSBzdXBwb3J0aW5nIHJlbGF5IGZ1bmN0aW9uYWxpdHkpLg0KPiBJIHJlbWVt YmVyIG1vcmUgdGhhbiBvbmUgaW1wbGVtZW50YXRpb25zIGZyb20gbGFzdCBpbnRlcm9wIHN1cHBv cnRpbmcgDQo+IGFwcGxpY2F0aW9uIGluIGFkZGl0aW9uIHRvIHJlbGF5IGZ1bmN0aW9uYWxpdHkg b24gdGhlIHNhbWUgbm9kZS4gDQo+IA0KPiANCj4gQ291bGQgeW91IHBsZWFzZSB2ZXJpZnkgdGhh dCB0aGUgbm9kZSB3YXMgc3VwcG90aW5nIHJlbGF5IGFwcGxpY2F0aW9uIA0KYWxzbyANCj4gKGFs b25nIHdpdGggcmVsYXkgZnVuY3Rpb25hbGl0eSkuDQo+IA0KPiANCj4gSXQgaXMgY29tbW9uIHRv IGhhdmUgc2ltaWxhciBzZXR1cCB3aGVyZSBhIHNlcnZlciBzZXJ2ZXMgcmVxdWVzdHMgDQpmb3Iv ZnJvbSANCj4gbG9jYWwgZG9tYWluIGFuZCByZWxheXMgdGhlIHJlc3QuIA0KPiANCj4gDQo+IEkg ZG8gYWdyZWUgdGhhdCBhIG5vZGUgY2FuIHNlcnZlIHRoZSByZXF1ZXN0cyBmcm9tIHNvbWUgZG9t YWluIGFuZCByZWxheSANCg0KPiB0aGUgcmVzdC4gDQo+IFdoYXQgSSB3YW50IHRvIGNvbmZpcm0g aXMgd2hldGhlciB0aGlzIG5vZGUgc3VwcG9ydHMgdGhlIHJlbGF5IA0KYXBwbGljYXRpb24gDQo+ IGFsc28gPw0KPiANCj4gDQo+IA0KPiBSZWdhcmRzLA0KPiBTYXRlbmRyYSANCj4gDQo+IEZyb206 IE5pbWlzaCBCaGFyZ2F2YSBbbWFpbHRvOm5pbWlzaC5iaGFyZ2F2YUBhcmljZW50LmNvbV0gDQo+ IFNlbnQ6IEZyaWRheSwgSnVuZSAxNSwgMjAwNyAxMjo0OCBQTQ0KPiBUbzogZGltZUBpZXRmLm9y ZzsgdmZhamFyZG9AdGFyaS50b3NoaWJhLmNvbTsgdGFzdmVyZW5Ac29udXNuZXQuY29tDQo+IFN1 YmplY3Q6IFtEaW1lXSBSZWxheSBzdXBwb3J0aW5nIGFwcGxpY2F0aW9uIA0KPiANCj4gDQo+IEhp IGFsbCwgDQo+IA0KPiBDYW4gYW55b25lIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJvdXQgd2hldGhl ciB0aGUgcmVsYXkgbm9kZXMgY2FuIHN1cHBvcnQgDQoNCj4gYW55IGFwcGxpY2F0aW9uIGFsc28/ IA0KPiANCj4gQWNjb3JkaW5nIHRvIFNwZWNpZmljYXRpb24gMzU4OCBzZWN0aW9uIDIuOC4xIGxh c3QgcGFyYSANCj4gDQo+ICJTaW5jZSBSZWxheXMgZG8gbm90IHBlcmZvcm0gYW55IGFwcGxpY2F0 aW9uIGxldmVsIHByb2Nlc3NpbmcsIHRoZXkgDQo+ICAgIHByb3ZpZGUgcmVsYXlpbmcgc2Vydmlj ZXMgZm9yIGFsbCBEaWFtZXRlciBhcHBsaWNhdGlvbnMsIGFuZCANCj4gICAgdGhlcmVmb3JlIE1V U1QgYWR2ZXJ0aXNlIHRoZSBSZWxheSBBcHBsaWNhdGlvbiBJZGVudGlmaWVyLiIgDQo+IA0KPiBE b2VzIHRoaXMgbWVhbiB0aGF0IHJlbGF5IGFnZW50cyBjYW4gbmV2ZXIgc3VwcG9ydCBhbnkgYXBw bGljYXRpb24gYWJvdmUgDQoNCj4gdGhlbSA/IA0KPiANCj4gUmVnYXJkcywNCj4gTmltaXNoIA0K PiANCj4gDQo+ICoqKioqKioqKioqKioqKioqKioqKioqICBBcmljZW50LVVuY2xhc3NpZmllZCAg ICoqKioqKioqKioqKioqKioqKioqKioqIA0KPiAiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlz IHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCANCj4gc29sZWx5IGZvciB0 aGUgdXNlIG9mIA0KPiB0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciANCj4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFu ZCBzaG91bGQgbm90IGJlIA0KPiBjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90 aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIA0KSWYgDQo+IHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgDQo+IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCANCj4gcmVjaXBpZW50 LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQ0KPiBwcm9oaWJpdGVkIGZy b20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBv ZiANCj4gdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9y IA0KPiBsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gdHJhbnNtaXR0ZWQgYnkgDQp0aGlzIA0KPiBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20g dmlydXMuIiANCj4gDQo+IA0KPiANCj4gDQo+ICoqKioqKioqKioqKioqKioqKioqKioqICBBcmlj ZW50LVVuY2xhc3NpZmllZCAgICoqKioqKioqKioqKioqKioqKioqKioqDQo+ICJESVNDTEFJTUVS OiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVuZGVk IA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIA0KPiB0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlz IGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciANCmNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSANCj4gY2lyY3VsYXRlZCBvciB1c2VkIGZvciBh bnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiANCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgDQo+IHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCANCnJl Y2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkNCj4gcHJvaGli aXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29u dGVudHMgb2YgDQp0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0 eSBmb3IgDQo+IGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiB0cmFuc21pdHRlZCBieSANCnRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9t IHZpcnVzLiINCg0KDQoNCioqKioqQXJpY2VudC1VbmNsYXNzaWZpZWQgKioqKio9IA0KIkRJU0NM QUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50 ZW5kZWQgDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgDQp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0 IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciANCmNvbmZpZGVudGlh bCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSANCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3Ig YW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgDQp5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIA0KcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIA0KcmVj aXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQ0KcHJvaGliaXRl ZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVu dHMgb2YgDQp0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBm b3IgDQpsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gdHJhbnNtaXR0ZWQgYnkgdGhpcyANCmVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1 cy4iDQoNCg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqICBBcmljZW50LVVuY2xhc3NpZmll ZCAgICoqKioqKioqKioqKioqKioqKioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlz IHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29u dGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5v dCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3 aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4g ZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91 IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBv ciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0 cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUg dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGlu ZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 001D0AAA652572FE_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdsZW48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gZGVub3RpbmcgYSAmcXVv dDtkaWFtZXRlciBhZ2VudCZxdW90Ow0KYXMgYSBub2RlLjxicj4NCjxicj4NClJlZ2FyZHMsPGJy Pg0KTmltaXNoPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0dsZW4gWm9ybiBcKGd3elwpJnF1b3Q7DQombHQ7Z3d6 QGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4wNi8xOC8yMDA3IDEwOjMzIEFNPC9mb250Pg0KPGJyPg0KPHRkIHdpZHRoPTU5JT4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+TmltaXNoIEJoYXJnYXZhL0hTU0BIU1M8L2ZvbnQ+ DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5jYzwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mbHQ7ZGltZUBpZXRmLm9yZyZndDssICZxdW90O21hcmNvLmNhcnVzaW8mcXVv dDsNCiZsdDttYXJjby5jYXJ1c2lvQGRhdGFtYXQuaXQmZ3Q7PC9mb250Pg0KPHRyPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwv Zm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5SRTogW0RpbWVdIFJlOiBSZWxheSBzdXBwb3J0aW5nDQphcHBsaWNhdGlvbjwvZm9udD48L3Rh YmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5IaSBNYXJjbzxicj4N Cjxicj4NCkkgaGF2ZSBhIGNvbmNlcm4gdGhhdCBpZiB3ZSBzdGFydCBwcm92aWRpbmcgYXBwbGlj YXRpb24gc3VwcG9ydCBhdCBhIG5vZGUNCnN1cHBvcnRpbmcgcmVsYXkgYXBwbGljYXRpb24gdGhl biB0aGUgbm9kZSB3aWxsIGJlIHJlcXVpcmVkIHRvIHBhcnNlIGV2ZXJ5DQptZXNzYWdlIHRoYXQg aXQgcmVjZWl2ZXMuIFRoZW4sIHRoYXQgc2hhbGwgbGVhZCB0byB2aW9sYXRpb24gb2Ygc3BlY2lm aWNhdGlvbnMNCmFzIHRoZSByZWxheSBub2RlIHNob3VsZCBub3QgcGFyc2UgdGhlIG1lc3NhZ2Ug aXQgcmVjZWl2ZXMuPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj4N CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+V291bGQg eW91IG1pbmQgZGVmaW5pbmcgdGhlIHRlcm0NCiZxdW90O25vZGUmcXVvdDsgYXMgeW91IGFyZSB1 c2luZyBpdD88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KUmVn YXJkcyw8YnI+DQpOaW1pc2g8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zIGNvbG9yPSNhMTAwOWY+LS0tLS0mcXVvdDttYXJjby5jYXJ1c2lvJnF1b3Q7ICZsdDttYXJj by5jYXJ1c2lvQGRhdGFtYXQuaXQmZ3Q7DQp3cm90ZTogLS0tLS08YnI+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zPlRvOiBOaW1pc2ggQmhhcmdhdmEvSFNTQEhTUzxicj4NCkZyb206ICZxdW90 O21hcmNvLmNhcnVzaW8mcXVvdDsgJmx0O21hcmNvLmNhcnVzaW9AZGF0YW1hdC5pdCZndDs8YnI+ DQpEYXRlOiAwNi8xNS8yMDA3IDAzOjQxUE08YnI+DQpjYzogJnF1b3Q7U2F0ZW5kcmEgR2VyYSBc KHNhdGdlcmFcKSZxdW90OyAmbHQ7c2F0Z2VyYUBjaXNjby5jb20mZ3Q7LCBkaW1lQGlldGYub3Jn PGJyPg0KU3ViamVjdDogUmU6IFJlbGF5IHN1cHBvcnRpbmcgYXBwbGljYXRpb248YnI+DQo8L2Zv bnQ+PHR0Pjxmb250IHNpemU9Mz48YnI+DQpIaSBOaW1pc2ggYW5kIFNhdGVuZHJhLDxicj4NCjxi cj4NCmZyb20gUkZDIDM1ODggcGFyLiAxLjM6IDxicj4NCjxicj4NCiZxdW90Oy4uLnJlbGF5cyBu ZXZlciBvcmlnaW5hdGUgbWVzc2FnZXMsIGRvIG5vdCBuZWVkIHRvPGJyPg0KdW5kZXJzdGFuZCB0 aGUgc2VtYW50aWNzIG9mIG1lc3NhZ2VzIG9yIG5vbi1yb3V0aW5nIEFWUHMsIGFuZCBhcmU8YnI+ DQpjYXBhYmxlIG9mIGhhbmRsaW5nIGFueSBEaWFtZXRlciBhcHBsaWNhdGlvbiBvciBtZXNzYWdl IHR5cGUuJnF1b3Q7IDxicj4NCjxicj4NCkluIG15IHVuZGVyc3RhbmRpbmcgdGhlcmUgaXMgbm8g bmVlZCBmb3IgaW1wbGVtZW50aW5nIGFwcGxpY2F0aW9uIHN1cHBvcnQNCjxicj4NCmluc2lkZSB0 aGUgcmVsYXksIGluZGVlZCBpdCBpcyBub3QgaW4gY2hhcmdlIG9mIHByb3ZpZGluZyBhcHBsaWNh dGlvbiA8YnI+DQpmdW5jdGlvbmFsaXRpZXMuPGJyPg0KQW55d2F5IEkgZ3Vlc3MgdGhlcmUgaXMg bm90IGFueSByZXN0cmljdGlvbiBmb3IgcHJvdmlkaW5nIHRvIHJlbGF5cyB0aGUNCjxicj4NCmNh cGFiaWxpdGllcyBvZiBwcm9jZXNzaW5nIGFwcGxpY2F0aW9uIGxldmVsIGRhdGEuIDxicj4NCjxi cj4NCkkgZG9uJ3Qga25vdyBpZiBJIGFuc3dlcmVkIHlvdXIgcXVlc3Rpb24uIDxicj4NCjxicj4N ClJlZ2FyZHMsPGJyPg0KTWFyY28uIDxicj4NCjxicj4NCjxicj4NCk5pbWlzaCBCaGFyZ2F2YSBz Y3JpdmU6IDxicj4NCjxicj4NCiZndDsgSGkgU2F0ZW5kcmEgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFBsZWFzZSBmaW5kIG15IGNvbW1lbnRzIGlubGluZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJl Z2FyZHMsPGJyPg0KJmd0OyBOaW1pc2ggPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOzxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O1NhdGVuZHJhIEdlcmEgKHNhdGdlcmEp JnF1b3Q7IDxicj4NCiZndDsgMDYvMTUvMjAwNyAwMjo1NiBQTSA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBUbzxicj4NCiZndDsgTmltaXNoIEJoYXJnYXZhL0hTU0BIU1M8YnI+DQom Z3Q7IGNjPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFN1YmplY3Q8YnI+DQomZ3Q7IFJFOiBbRGltZV0g UmVsYXkgc3VwcG9ydGluZyBhcHBsaWNhdGlvbiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEhpIE5pbWlzaCw8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgSU1PIHRoZXJlIGlzIG5v IHJlc3RyaWN0aW9uIG9uIHN1cHBvcnQgb2YgYXBwbGljYXRpb25zIG9uIGEgcmVsYXkNCm5vZGUg PGJyPg0KJmd0OyAobm9kZSBzdXBwb3J0aW5nIHJlbGF5IGZ1bmN0aW9uYWxpdHkpLjxicj4NCiZn dDsgSSByZW1lbWJlciBtb3JlIHRoYW4gb25lIGltcGxlbWVudGF0aW9ucyBmcm9tIGxhc3QgaW50 ZXJvcCBzdXBwb3J0aW5nDQo8YnI+DQomZ3Q7IGFwcGxpY2F0aW9uIGluIGFkZGl0aW9uIHRvIHJl bGF5IGZ1bmN0aW9uYWxpdHkgb24gdGhlIHNhbWUgbm9kZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgQ291bGQgeW91IHBsZWFzZSB2ZXJpZnkgdGhhdCB0aGUgbm9kZSB3YXMgc3Vw cG90aW5nIHJlbGF5IGFwcGxpY2F0aW9uDQphbHNvIDxicj4NCiZndDsgKGFsb25nIHdpdGggcmVs YXkgZnVuY3Rpb25hbGl0eSkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQgaXMg Y29tbW9uIHRvIGhhdmUgc2ltaWxhciBzZXR1cCB3aGVyZSBhIHNlcnZlciBzZXJ2ZXMgcmVxdWVz dHMNCmZvci9mcm9tIDxicj4NCiZndDsgbG9jYWwgZG9tYWluIGFuZCByZWxheXMgdGhlIHJlc3Qu ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZG8gYWdyZWUgdGhhdCBh IG5vZGUgY2FuIHNlcnZlIHRoZSByZXF1ZXN0cyBmcm9tIHNvbWUgZG9tYWluIGFuZA0KcmVsYXkg PGJyPg0KJmd0OyB0aGUgcmVzdC4gPGJyPg0KJmd0OyBXaGF0IEkgd2FudCB0byBjb25maXJtIGlz IHdoZXRoZXIgdGhpcyBub2RlIHN1cHBvcnRzIHRoZSByZWxheSBhcHBsaWNhdGlvbg0KPGJyPg0K Jmd0OyBhbHNvID88YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDs8YnI+DQom Z3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBTYXRlbmRyYSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJv bTogTmltaXNoIEJoYXJnYXZhIFs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpuaW1pc2guYmhh cmdhdmFAYXJpY2VudC5jb20+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pm1haWx0bzpu aW1pc2guYmhhcmdhdmFAYXJpY2VudC5jb208L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBz aXplPTM+XQ0KPGJyPg0KJmd0OyBTZW50OiBGcmlkYXksIEp1bmUgMTUsIDIwMDcgMTI6NDggUE08 YnI+DQomZ3Q7IFRvOiBkaW1lQGlldGYub3JnOyB2ZmFqYXJkb0B0YXJpLnRvc2hpYmEuY29tOyB0 YXN2ZXJlbkBzb251c25ldC5jb208YnI+DQomZ3Q7IFN1YmplY3Q6IFtEaW1lXSBSZWxheSBzdXBw b3J0aW5nIGFwcGxpY2F0aW9uIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIGFs bCwgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENhbiBhbnlvbmUgcHJvdmlkZSBpbmZvcm1h dGlvbiBhYm91dCB3aGV0aGVyIHRoZSByZWxheSBub2RlcyBjYW4gc3VwcG9ydA0KPGJyPg0KJmd0 OyBhbnkgYXBwbGljYXRpb24gYWxzbz8gJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFjY29y ZGluZyB0byBTcGVjaWZpY2F0aW9uIDM1ODggc2VjdGlvbiAyLjguMSBsYXN0IHBhcmEgJm5ic3A7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O1NpbmNlIFJlbGF5cyBkbyBub3QgcGVyZm9ybSBh bnkgYXBwbGljYXRpb24gbGV2ZWwgcHJvY2Vzc2luZywNCnRoZXkgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7cHJvdmlkZSByZWxheWluZyBzZXJ2aWNlcyBmb3IgYWxsIERpYW1ldGVyIGFwcGxpY2F0 aW9ucywNCmFuZCA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0aGVyZWZvcmUgTVVTVCBhZHZlcnRp c2UgdGhlIFJlbGF5IEFwcGxpY2F0aW9uIElkZW50aWZpZXIuJnF1b3Q7DQombmJzcDs8YnI+DQom Z3Q7IDxicj4NCiZndDsgRG9lcyB0aGlzIG1lYW4gdGhhdCByZWxheSBhZ2VudHMgY2FuIG5ldmVy IHN1cHBvcnQgYW55IGFwcGxpY2F0aW9uDQphYm92ZSA8YnI+DQomZ3Q7IHRoZW0gPyAmbmJzcDs8 YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IE5pbWlzaCA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqKioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmlj ZW50LVVuY2xhc3NpZmllZCAmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKioNCjxicj4NCiZn dDsgJnF1b3Q7RElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNl bnQgJm5ic3A7YW5kDQppcyBpbnRlbmRlZCA8YnI+DQomZ3Q7IHNvbGVseSBmb3IgdGhlIHVzZSBv ZiA8YnI+DQomZ3Q7IHRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBt YXkgY29udGFpbiBwcml2aWxlZ2VkDQpvciA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiBhbmQgc2hvdWxkIG5vdCBiZSA8YnI+DQomZ3Q7IGNpcmN1bGF0ZWQgb3IgdXNlZCBmb3Ig YW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4NCklmIDxicj4N CiZndDsgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCA8YnI+DQomZ3Q7 IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZA0KPGJyPg0KJmd0OyByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhh dCB5b3UgYXJlIHN0cmljdGx5PGJyPg0KJmd0OyBwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlp bmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cw0Kb2YgPGJyPg0KJmd0OyB0 aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgPGJyPg0K Jmd0OyBsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gdHJhbnNtaXR0ZWQNCmJ5IHRoaXMgPGJyPg0KJmd0OyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdl IGZyb20gdmlydXMuJnF1b3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqKioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmlj ZW50LVVuY2xhc3NpZmllZCAmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQomZ3Q7 ICZxdW90O0RJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50 ICZuYnNwO2FuZA0KaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIDxicj4NCiZndDsg dGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHBy aXZpbGVnZWQNCm9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSA8 YnI+DQomZ3Q7IGNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBm b3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2Fn ZSBpbiBlcnJvciwgPGJyPg0KJmd0OyBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVk aWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCwgeW91IGFyZSBu b3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHk8YnI+DQomZ3Q7IHByb2hpYml0ZWQgZnJvbSB1 c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzDQpvZiB0 aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgPGJyPg0K Jmd0OyBsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gdHJhbnNtaXR0ZWQNCmJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVz LiZxdW90Ozxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQoq KioqKkFyaWNlbnQtVW5jbGFzc2lmaWVkICoqKioqPSA8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0cj4NCjx0ZCB3aWR0aD0xMDAlIGJnY29sb3I9d2hpdGU+PHR0Pjxmb250IHNpemU9Mz4m cXVvdDtESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UNCmlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQg Jm5ic3A7YW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiA8YnI+DQp0aGUgaW5k aXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdl ZCBvciBjb25maWRlbnRpYWwNCmluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIDxicj4NCmNp cmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBp cyBpbnRlbmRlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwg PGJyPg0KcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwNCnlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3Ug YXJlIHN0cmljdGx5PGJyPg0KcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmlu Zywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YNCnRoaXMgbWVzc2FnZS4gQXJpY2VudCBh Y2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciA8YnI+DQpsb3NzIG9yIGRhbWFnZSBhcmlzaW5n IGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcw0KZW1h aWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiZxdW90Ozxicj4NCjwvZm9udD48L3R0Pjwv dGFibGU+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxi cj4NCioqKioqKioqKioqKioqKioqKioqKioqICZuYnNwO0FyaWNlbnQtVW5jbGFzc2lmaWVkICZu YnNwOyAqKioqKioqKioqKioqKioqKioqKioqKjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29s b3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAwMDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVz c2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNo b3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhh biBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNz YWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0 aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRl cmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50 IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZy b20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBp bmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo8L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwvdGFi bGU+ --=_alternative 001D0AAA652572FE_=-- --===============1767046409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1767046409==-- From dime-bounces@ietf.org Mon Jun 18 05:14:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DJz-0004rp-Jq; Mon, 18 Jun 2007 05:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DJx-0004rh-KQ for dime@ietf.org; Mon, 18 Jun 2007 05:14:50 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0DJx-0004G7-30 for dime@ietf.org; Mon, 18 Jun 2007 05:14:49 -0400 Received: (qmail invoked by alias); 18 Jun 2007 09:14:47 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp028) with SMTP; 18 Jun 2007 11:14:47 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+klRRk0sGkdS8uUv+nHFPElgf+K9PDba8BArSkhy ETgYNEAmZzh8ta Message-ID: <46764D05.3090005@gmx.net> Date: Mon, 18 Jun 2007 11:14:45 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Registering new Command Codes with IANA based on"ExpertReview" References: <0D22E3C1A7D7A843B12BF8C6F0A4075802148F01@MCHP7IDA.ww002.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mark Mark Jones wrote: > Hannes, > > The inconsistency in the assignment rules may be the result of the > removal of some vendor-specific features late in the Diameter base > protocol design. Once upon a time, the Diameter header contained a > vendor id to allow a vendor-specific namespace for commands. I suspect > the 'IETF Consensus' rule was originally intended just for the IETF > commands. > That might be true. Let us ask, for example, John & Jari what the original intention was. > I have concerns about the effectiveness of the 'Expert Review' given the > limited success in getting other SDOs to submit to 'IETF Consensus' for > new commands. The DIME group may find it can achieve the same > interoperability goals by giving the SDOs (and vendors) the tools they > need to police their own specifications. The Diameter Applications > Design Guidelines draft is an key deliverable in this regard. Once this > draft is complete, SDOs creating Diameter applications can > encourage/require their working groups to review their specifications > against it for compliance. > The document will hopeful give some help to people extending Diameter. > If the Expert Review is the preferred route of this group, we should > recognize the importance of effective socialization with the other SDOs > to ensure they appreciate its value and understand where it fits in > their specification process. > We will do our best. Ciao Hannes > Regards > Mark > > >> -----Original Message----- >> From: Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com] >> Sent: June 14, 2007 15:11 >> To: Mark Jones; Hannes Tschofenig >> Cc: dime@ietf.org >> Subject: AW: [Dime] Registering new Command Codes with IANA >> based on"ExpertReview" >> >> Hi Mark, >> >> It is somewhat strange that the application ids and the command codes >> have a different policy. >> I would, however, like to have a model where some Diameter >> experts could >> do a brief (e.g., 2 weeks time) review of the suggested extension to >> check whether the chosen design approach is not violating the Diameter >> extensibility concept. >> This review would be based on Diameter extensiblity and not on the >> actual content of the extension. >> >> Ciao >> Hannes >> >> >>> Hannes, >>> >>> I agree with your assessment of the SDO situation and that >>> >> we need to >> >>> revisit the assignment rules. >>> >>> Why are vendor-specific application ids assigned on a 'First >>> Come First >>> Served' basis whereas new vendor-specific commands within that >>> application require 'IETF Consensus'? >>> >>> Why not subdivide the Command Code namespace (like the >>> >> application id) >> >>> to allow a vendor-specific range that is also allocated by IANA on a >>> 'First Come First Served' basis? >>> >>> Thanks >>> Mark >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: June 14, 2007 04:36 >>>> To: dime@ietf.org >>>> Subject: [Dime] Registering new Command Codes with IANA based >>>> on "ExpertReview" >>>> >>>> Hi all, >>>> >>>> RFC 3588 describes that "IETF Consensus" is needed when >>>> >>> registering a >>> >>>> new Command Code with IANA. That's fine if you develop a >>>> specification >>>> in the IETF. >>>> It is, however, challenging when another SDOs extend Diameter >>>> but don't >>>> want todo this within the IETF itself. What they then do is >>>> >>> to avoid >>> >>>> creating a command code (and applications in general) but >>>> >> re-using >> >>>> existing applications, such as Diameter NASREQ, and adding >>>> vendor-specific AVPs. As one might guess the consequence is a >>>> hack. This >>>> can lead to interoperability problems. >>>> >>>> Now, in a chat between Dan, Victor and myself we thought >>>> about ways how >>>> to change the current situation. We would like to have >>>> >>> other SDOs to >>> >>>> extend Diameter in such a way that it does not cause >>>> >>> interoperability >>> >>>> problems. One way is to improve the current situation is to >>>> change the >>>> policy for registering Command Codes from "IETF Consensus" >>>> >>> to "Expert >>> >>>> Review" (as part of the work on >>>> http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis >>>> -04.txt). >>>> This would obviously require that we setup a expert review >>>> team in order >>>> to actually handle the incoming review requests. >>>> >>>> What do people think about the suggested change? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 18 12:20:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JxY-0004rz-OO; Mon, 18 Jun 2007 12:20:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JxX-0004rr-Ue for dime@ietf.org; Mon, 18 Jun 2007 12:20:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0JxV-0006hi-Cn for dime@ietf.org; Mon, 18 Jun 2007 12:20:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5IGK22f005024; Mon, 18 Jun 2007 19:20:03 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 19:20:01 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:19:58 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 11:19:20 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4FB63A77@daebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Route-Record AVPs in responses Thread-Index: AceuZRYn9QE9wZkaQpeaTtdzbWPNCwDX0F1w References: From: To: X-OriginalArrivalTime: 18 Jun 2007 16:19:58.0329 (UTC) FILETIME=[839EFE90:01C7B1C4] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Gavin.Wong@vodafone.com Subject: [Dime] RE: Route-Record AVPs in responses X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Forwarding this to the DIME mailing list, where thiese issues are discussed. John=20 >-----Original Message----- >From: ext m.hillier@telenet-ag.de [mailto:m.hillier@telenet-ag.de]=20 >Sent: 14 June, 2007 02:19 >To: Loughney John (Nokia-NRC/PaloAlto) >Cc: Gavin.Wong@vodafone.com >Subject: Route-Record AVPs in responses > >Dear John, > >from current work, I had to clarify the presence and use of =20 >Route-Record AVPs in Diameter Responses, in particular=20 >Credit-Control-Answer messages. >Just to make sure, I double checked 3588 and Draft 3588bis-04=20 >and as many AAA WG messages as I could! > >And I found no clarification and reference to any recent discussion. > >Googling, I found the conversation you had back in 2003 with=20 >Pasi. It seems to me that the issues raised there are still=20 >current and not solved. > >Applications like NASREQ and CCA have included Route-Record=20 >AVPs in their responses, but say nothing about the values and=20 >the processing. >=20 >And it is unclear whether the server reflects the received=20 >list of Route-Record AVPs and the relays and proxies on the=20 >return path "peel off"=20 >the AVPs one by one >OR alternatively the server removes all Route-Record AVPs and =20 >each agent adds in the identity of the Diameter peer it=20 >received the answer from in a new Route-Record, before=20 >forwarding the response. > >I really hope I have missed a clarification ! > >Best regards > >Mike Hillier > > >RE: : Route-Record AVP in responses > > >Subject:=20 >RE: : Route-Record AVP in responses > >Hi Pasi, > >These changes sound too big to make within the authors' 48=20 >hour period, so I think we need to file these as a bug for the future. > >I think the list should discuss what is the best way to solve this. > >John > >> -----Original Message----- >> From: ext [mailto:Pasi.Eronen@nokia.com] >> Sent: 02 September, 2003 21:50 >> To: Loughney John (NRC/Helsinki); jari.arkko@kolumbus.fi >> Cc: aaa-wg@merit.edu >> Subject: RE: [AAA-WG]: Route-Record AVP in responses >>=20 >>=20 >>=20 >> John Loughney wrote: >> > Yes, and I am waiting on the simple fixes that don't get us into=20 >> > trouble ;) >>=20 >> Let's see what changes would be needed... if we stick with the=20 >> decision in issue 228 (no Route-Record AVPs in responses),=20 >Base needs=20 >> these changes: >>=20 >> - In section 2.10, delete the paragraph that starts=20 >> "Similarly, the local Diameter agent..." >> - In 10.2 (AVP occurrence table), change "0+" to "0" >> in cell (Route-Record,ACA). >>=20 >> From editing point of view, the changes are small--but might get us=20 >> into trouble since it removes some functionality...=20 >(especially since=20 >> the deleted paragraph also discusses some security issues). >>=20 >> If we decide that responses DO have Route-Records, we need to change=20 >> the following: >>=20 >> - First we have to decide whether the Route-Record AVPs are=20 >> added to the response one-by-one (as it gets forwarded=20 >> back to the client), or if the server does it (by copying >> all the Route-Record AVPs from the request). While the latter >> was used in e.g. Base-05, IMHO the former seems much less >> problematic. >> - The former approach would mean adding a new paragraph to=20 >> Section 6.2.2 (after the first one): "A proxy or relay agent=20 >> MUST append a Route-Record AVP to all responses forwarded.=20 >> The AVP contains the identity of the peer the response was=20 >> received from." >> - In 10.1 (AVP occurrence table), change "0" to "0+" in=20 >> cells Route-Record X (RAA,ASA,STA) >> - Add "* [ Route-Record ]" to ABNFs (after Proxy-Info)=20 >> in 8.3.2 (RAA), 8.4.2 (STA), 8.5.2 (ASA) and 9.7.2 (ACA) >>=20 >> (Either way, NASREQ needs changes as well. I can try to figure out=20 >> what they are when we decide which way to go.) >>=20 >> Best regards, >> Pasi >>=20 > > > > > > > >Michael Hillier >Vodafone Group Technology > >Mobile (Vodafone) +49 170 5454 121 > >M.Hillier@telenet-ag.de >Michael.Hillier@vodafone.com > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 18 14:52:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0MLG-0005pD-AZ; Mon, 18 Jun 2007 14:52:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0MLF-0005p8-OX for dime@ietf.org; Mon, 18 Jun 2007 14:52:45 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0MLE-0007kj-95 for dime@ietf.org; Mon, 18 Jun 2007 14:52:45 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5IIqUYm017224; Mon, 18 Jun 2007 21:52:38 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 21:52:37 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 13:52:28 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Jun 2007 13:51:36 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4FB63C0E@daebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pass word in Diameter Thread-Index: Acescangx/Z2OmO+TyC0O8jIqa9hugFZ/k6g References: From: To: X-OriginalArrivalTime: 18 Jun 2007 18:52:28.0389 (UTC) FILETIME=[D17B5950:01C7B1D9] X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: erik.guttman@sun.com, Tong.Luo@windriver.com, pcalhoun@airespace.com, Jari.Arkko@ericsson.com Subject: [Dime] RE: Pass word in Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1634466736==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1634466736== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B1D9.B2F56E52" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B1D9.B2F56E52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have forwarded this to the DiME WG list, this is the proper place to discuss these issues. =20 John ________________________________ From: ext Luo, Tong [mailto:Tong.Luo@windriver.com]=20 Sent: 11 June, 2007 14:44 To: pcalhoun@airespace.com; Loughney John (Nokia-NRC/PaloAlto); Jari.Arkko@ericsson.com; erik.guttman@sun.com Subject: Pass word in Diameter =09 =09 Hi,=20 Since unlike Radius, the Diameter protocol defined by RFC 3588 doesn't have an authenticator in the message header anymore. However, the user access request message defined by Radius could add User-Password attribute (attribute type 2), which would require to use authenticator in the Radius header to encrypt the password. =20 So my question is: without authenticator in the Diameter header, how should the User-Password attribute be calculated in Diameter? Thanks,=20 Tong=20 ------_=_NextPart_001_01C7B1D9.B2F56E52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pass word in Diameter
I have forwarded this to the DiME WG list, this = is the=20 proper place to discuss these issues.
 
John

From: ext Luo, Tong=20 [mailto:Tong.Luo@windriver.com]
Sent: 11 June, 2007=20 14:44
To: pcalhoun@airespace.com; Loughney John=20 (Nokia-NRC/PaloAlto); Jari.Arkko@ericsson.com;=20 erik.guttman@sun.com
Subject: Pass word in=20 Diameter

Hi,

Since unlike Radius, the Diameter = protocol defined=20 by RFC 3588 doesn't have an authenticator in the message header = anymore.=20 However,  the user access request message defined by Radius could = add=20 User-Password attribute (attribute type 2), which would require to use = authenticator in the Radius header to encrypt the password.  =

So my question is: without = authenticator in the=20 Diameter header,  how should the User-Password  attribute be = calculated in Diameter?

Thanks,
Tong

------_=_NextPart_001_01C7B1D9.B2F56E52-- --===============1634466736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1634466736==-- From dime-bounces@ietf.org Mon Jun 18 15:18:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Mjz-0005Oq-W0; Mon, 18 Jun 2007 15:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Mjy-0005Ol-RM for dime@ietf.org; Mon, 18 Jun 2007 15:18:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Mjw-0006dj-7X for dime@ietf.org; Mon, 18 Jun 2007 15:18:18 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 18 Jun 2007 12:18:16 -0700 X-IronPort-AV: i="4.16,435,1175497200"; d="scan'208,217"; a="380223002:sNHT110374484" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5IJIFPX003587; Mon, 18 Jun 2007 12:18:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5IJICtr021831; Mon, 18 Jun 2007 19:18:15 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 12:18:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] RE: Pass word in Diameter Date: Mon, 18 Jun 2007 12:18:20 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625042EB489@xmb-sjc-215.amer.cisco.com> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4FB63C0E@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Pass word in Diameter Thread-Index: Acescangx/Z2OmO+TyC0O8jIqa9hugFZ/k6gAADfm9A= References: <071568CA7B789D4AA170CEF8C9613B4FB63C0E@daebe103.NOE.Nokia.com> From: "Glen Zorn \(gwz\)" To: , X-OriginalArrivalTime: 18 Jun 2007 19:18:12.0359 (UTC) FILETIME=[69C27970:01C7B1DD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4659; t=1182194295; x=1183058295; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20RE=3A=20Pass=20word=20in=20Diameter |Sender:=20; bh=PZwjZ4/NTb8yXc1+yggY2Y1ZqsF5ghDbQl+fUCNtzlM=; b=KWihUjp2kN/4xJCOOo5orhr/IBDa/4ZaZNMmxvV7b9mr2QwK/qASR0xwBJcSZqYVicpvg/45 911eAm/EDGByb2petKC/xjMQX1R/4lZBBpdu8Rg64No/prXcIjBnm2ilT8T0JMMoJ1Gku/86SJ K9OjUFHF3ZGd8aZ2AxTFRqcl4=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: erik.guttman@sun.com, Tong.Luo@windriver.com, pcalhoun@airespace.com, Jari.Arkko@ericsson.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0644212044==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0644212044== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B1DD.697C5CC4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B1DD.697C5CC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In Diameter, the User-Password attribute is not encrypted separately. It is covered by the TLS or IPsec security applied to the entire message. ________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Monday, June 18, 2007 11:52 AM To: dime@ietf.org Cc: erik.guttman@sun.com; Tong.Luo@windriver.com; pcalhoun@airespace.com; Jari.Arkko@ericsson.com Subject: [Dime] RE: Pass word in Diameter I have forwarded this to the DiME WG list, this is the proper place to discuss these issues. =20 John ________________________________ From: ext Luo, Tong [mailto:Tong.Luo@windriver.com]=20 Sent: 11 June, 2007 14:44 To: pcalhoun@airespace.com; Loughney John (Nokia-NRC/PaloAlto); Jari.Arkko@ericsson.com; erik.guttman@sun.com Subject: Pass word in Diameter =09 =09 Hi,=20 Since unlike Radius, the Diameter protocol defined by RFC 3588 doesn't have an authenticator in the message header anymore. However, the user access request message defined by Radius could add User-Password attribute (attribute type 2), which would require to use authenticator in the Radius header to encrypt the password. =20 So my question is: without authenticator in the Diameter header, how should the User-Password attribute be calculated in Diameter? Thanks,=20 Tong=20 ------_=_NextPart_001_01C7B1DD.697C5CC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pass word in Diameter
In Diameter, the User-Password attribute is = not=20 encrypted separately.  It is covered by the TLS or IPsec = security=20 applied to the entire message.

From: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Sent: Monday, June 18, 2007 = 11:52=20 AM
To: dime@ietf.org
Cc: erik.guttman@sun.com;=20 Tong.Luo@windriver.com; pcalhoun@airespace.com;=20 Jari.Arkko@ericsson.com
Subject: [Dime] RE: Pass word in=20 Diameter

I have forwarded this to the DiME WG list, this = is the=20 proper place to discuss these issues.
 
John

From: ext Luo, Tong=20 [mailto:Tong.Luo@windriver.com]
Sent: 11 June, 2007=20 14:44
To: pcalhoun@airespace.com; Loughney John=20 (Nokia-NRC/PaloAlto); Jari.Arkko@ericsson.com;=20 erik.guttman@sun.com
Subject: Pass word in=20 Diameter

Hi,

Since unlike Radius, the Diameter = protocol defined=20 by RFC 3588 doesn't have an authenticator in the message header = anymore.=20 However,  the user access request message defined by Radius could = add=20 User-Password attribute (attribute type 2), which would require to use = authenticator in the Radius header to encrypt the password.  =

So my question is: without = authenticator in the=20 Diameter header,  how should the User-Password  attribute be = calculated in Diameter?

Thanks,
Tong

------_=_NextPart_001_01C7B1DD.697C5CC4-- --===============0644212044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0644212044==-- From dime-bounces@ietf.org Tue Jun 19 12:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gLd-0003nx-HL; Tue, 19 Jun 2007 12:14:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gLc-0003ns-RZ for dime@ietf.org; Tue, 19 Jun 2007 12:14:28 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0gLX-0003cc-5W for dime@ietf.org; Tue, 19 Jun 2007 12:14:28 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1182269661!6864168!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3233 invoked from network); 19 Jun 2007 16:14:22 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 19 Jun 2007 16:14:22 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JGEL3W013616 for ; Tue, 19 Jun 2007 09:14:21 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l5JGEKn5016931 for ; Tue, 19 Jun 2007 11:14:21 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l5JGEJPJ016910 for ; Tue, 19 Jun 2007 11:14:20 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Date: Tue, 19 Jun 2007 12:14:18 -0400 Message-ID: In-Reply-To: <9b0e41640706141153g677d33e7o6ddb3f53da606939@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: FW: First draft on the integration of QoS application thread-index: AceutWPOQbUxj1/bQ4Krh8NNWpduIwD1l7dw References: <9b0e41640706141150i640dd29cy89ad225881907627@mail.gmail.com> <9b0e41640706141153g677d33e7o6ddb3f53da606939@mail.gmail.com> From: "McCann Peter-A001034" To: "Christian Esteve" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ce0328cdf9c90e4680655d09dccace5 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Christian, Thanks for your comments, I would certainly like to take a look at your paper. I suppose I could be convinced that local policy should be taken care of with a separate interface, but I think it's important that IETF standardize the inter-domain case as a first priority. The local interface is less important to standardize now, because it could easily be taken care of with a proprietary interface based on purchasing decisions made by the operator, or it could easily be incorporated in to the Network Element itself. One of my goals for the diameter-qos draft has been to facilitate the inter-working of disparate application functions in different networks, and I think that should be the focus of this draft. If we really want to add a new local PDP element to the draft I would be ok with a modified Figure 1 that shows this. However, the Diameter cloud would then need to be shown between that entity and the application server, and the document should focus on this latter interface. In=20 other words, we should be standardizing Rx now. -Pete Christian Esteve wrote: > Hi folks, >=20 > the discussion thread reflects once again the confrontation between > the operator SDO and the IETF worlds, and as it usually happens, > disagreements are not only motivated by network engineering issues > but by scope and nomenclature divergences. =20 >=20 >>> I guess I don't see why we need two separate interfaces. They are >>> each transporting roughly the same information and doing the same >>> sort of job. >=20 > It is true that the job and type of infomation are similar, however > the separation of the interfaces makes sense to me. While one > interface is used only to request QoS, the other is expected to carry > and install QoS policy information (with different QoS descriptors).=20 >=20 > The AF-PDP-PEP model (also referred to as AS-AE-NE) reflects the > architecture evolution of the SDOs that introduce policy-based > resource control functions. =20 >=20 > It has been said that: >>>>> There may be proxies in the >>>>> Diameter cloud that enforce their own policy decisions, some of >>>>> which will be local to the Network Element's administrative >>>>> domain.=20 >=20 > To my understanding that is why the separated interfaces make sense. >=20 > An intermediate PDP (also referred to as PDF) may enforce further > policies (network type specific, user profile related,=20 > operator-based) in conjunction with other network elements (resource > information, user database).=20 >=20 > Furthermore, the QoS description over the AF-PDP interface is likely > to differ from the QoS information describing the policy to be > instaslled in the NE, harmonizing and easing AF QoS requests and > enabling the QoS policy installation mechanism to evolve separately > in accordance to the transport network specifics. =20 >=20 > The PDP would certainly have an inter-domain interface to AFs and > other inter- an intra PDPs. I bnelieve that the Diameter QoS > application running between the AF and the PDP could be defined in a > way that it could be applied for the inter-domain PDP-PDP peering > interface. =20 >=20 > Unfortunately my contribution to the discussion at this point is not > enriching the discussion regarding the implications to the Diameter > functionality (e.g. command and AVPs, realm routing, discovery > schemes, etc.). =20 >=20 > However, I am sharing under > http://www.dca.fee.unicamp.br/~pasquini/dime-qos-app/ > some figures depicting the abstracted SDOs architectures that could > help in the following discussions around the Diameter QoS > application. =20 > The figures have been extracted > from the the paper "A review on policy-based resource and admission > control functions in evolving access and next generation networks", > recently accepted for publication (draft copy can be provided if > interested). =20 >=20 >=20 > Best regards, > Christian >>=20 >>=20 >>> ------------------------------ >>>=20 >>> Message: 5 >>> Date: Wed, 13 Jun 2007 18:08:21 -0400 >>> From: "McCann Peter-A001034" >>> Subject: [Dime] FW: First draft on the integration of QoS >>> application >>> To: >>> Message-ID: >>> =20 >>> >>> Content-Type: text/plain; charset=3D"us-ascii"=20 >>>=20 >>> Below is a discussion thread that has been taking place among >>> authors of the diameter-qos draft. We thought it important that the >>> mailing list have some visibility to the discussion. Comments >>> welcome.=20 >>>=20 >>> -Pete >>>=20 >>> McCann Peter-A001034 wrote: >>>> Hi, Dong, >>>>=20 >>>> I guess I don't see why we need two separate interfaces. They are >>>> each transporting roughly the same information and doing the same >>>> sort of job.=20 >>>>=20 >>>> The current document in my mind has always been an inter-domain >>>> interface. See the abstract:=20 >>>>=20 >>>> ...Clients that implement the Diameter QoS application contact an >>>> authorizing entity/application server that is located somewhere >>>> in the network, allowing for a wide variety of flexible >>>> deployment models.=20 >>>>=20 >>>> And the following text in Section 3.2: >>>>=20 >>>> Inter-domain support >>>>=20 >>>> In particular, users may roam outside their home network, >>>> leading to a situation where the network element and >>>> authorizing entity are in different administrative domains. >>>>=20 >>>> -Pete >>>>=20 >>>> Sun, Dong (Dong) wrote: >>>>> Hi Pete, >>>>> I have no doubt about the importance of inter-domain policy >>>>> communications, and it might be better to use the Diameter broker >>>>> instead of SIP proxy to deal with inter-domain resource >>>>> management.=20 >>>>> In fact, I think 3GPP does use the similar model as you >>>>> described, that a Diameter broker (client) is embedded in the AF >>>>> (e.g. P-CSCF), and the interface between AF and underlying Policy >>>>> engine (e.g. PCRF) is an inter-domain interface per se. >>>>> certainly, since they (SIP and Diameter brokers) are grouped >>>>> together, it is less flexible and scalable for the implementation. >>>>>=20 >>>>> However, I think this interface (named as Rx in 3GPP, Gq' in >>>>> TISPAN, Rs in ITU) is not for the control of policy enforcement >>>>> directly. In my view, this interface (Rx) is a peering interface >>>>> between policy servers rather than between policy server and >>>>> enforcement point as described in the current QoS application, >>>>> and I believe it is more appropriate to model the inter-domain >>>>> interface as the policy server to policy server (PDF-PDF) peering >>>>> interface.=20 >>>>>=20 >>>>> I have no problem to develop a doc to address this inter-domain >>>>> application, however, if you look around the current document, I >>>>> did not see any indication from that perspective. >>>>>=20 >>>>> Dong >>>>>=20 >>>>> -----Original Message----- >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>> Sent: Wednesday, June 13, 2007 2:11 PM >>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>>> TSOU; Avri Doria Cc: Victor Fajardo >>>>> Subject: RE: First draft on the integration of QoS application >>>>>=20 >>>>> Hi, Dong, >>>>>=20 >>>>> Sun, Dong (Dong) wrote: >>>>>> Hi Pete, >>>>>>=20 >>>>>> Thanks for clarification. Just wondering if you can give an >>>>>> example who will use the "inter-domain" model for policy >>>>>> enforcement control, i.e. PDP and PEP reside in the different >>>>>> operator's administrative domains. Since the inter-domain is to >>>>>> serve for the operator's domain, I don't know how to create an >>>>>> application without considering their need. (BTW, I have no >>>>>> strong view to limit it to intra-domain only if the use case can >>>>>> be identified).=20 >>>>>=20 >>>>> Arbitrary third parties should be allowed to deploy application >>>>> servers and interface to the Diameter cloud to get QoS from the >>>>> network. The Diameter QoS Application should play this role. >>>>> In the extreme case, I should be allowed to put a SIP server in >>>>> my basement, sign up with a Diameter broker, and run my >>>>> application end-to-end. >>>>>=20 >>>>>> I agree that this application should support "a generic mediator >>>>>> that can handle many applications". However, Given the >>>>>> integrated AS and AE, it makes the AE has to be collocated with >>>>>> the application content providers rather than the network >>>>>> itself, I feel it is also too limited and not the common case in >>>>>> reality. (As far as I know, all deployed or emerging network >>>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view >>>>>> this solution as the main trend). I am wondering who will use >>>>>> this application eventually. >>>>>=20 >>>>> I am not ruling out a PDP in the network local to the PEP. I am >>>>> just saying that this PDP should be viewed as a Diameter proxy on >>>>> the path to the Authorizing Entity, which itself may be either a >>>>> static subscriber database or an active application server. >>>>> I don't want to work only on the localized protocol, I want to >>>>> define the inter-domain one. If you insist on separating the AE >>>>> from the AS then I would say that the important Diameter >>>>> interface is the one between AE and AS. It is much more >>>>> important to standardize the inter-domain interface because this >>>>> is the one that will be used between operators. >>>>>=20 >>>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they >>>>> are going down the path of using SIP proxies as the inter-domain >>>>> interface. I think this architecture is bad for the Internet, >>>>> and will limit the kinds of applications that can be deployed. >>>>> The Internet model is that applications should be deployable >>>>> without modifying the middleboxes. Tying SIP servers to the >>>>> network traffic path also doesn't work well with Mobile IP. >>>>>=20 >>>>>> In addition, the scalable roaming agreements sound like a >>>>>> general algorithm that may be applicable for any inter-domain >>>>>> issue in the context of Diameter applications, or it is only the >>>>>> fundament to this application? >>>>>=20 >>>>> The Diameter NASREQ application (similar to the basic RADIUS >>>>> protocol) has always been about inter-domain operation. Diameter >>>>> is used as the mediating protocol between different operator >>>>> domains. I think we should be following the same model with the >>>>> Diameter QoS application. >>>>>=20 >>>>> -Pete >>>>>=20 >>>>>> Dong >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>> Sent: Wednesday, June 13, 2007 11:06 AM >>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on >>>>>> the integration of QoS application >>>>>>=20 >>>>>> Hi, Dong, >>>>>>=20 >>>>>> An "Autonomous System" has a very specific meaning in the >>>>>> context of routing protocols; I would not want to say that they >>>>>> correspond one-to-one with the "domains" that exist when I talk >>>>>> about "inter-domain" in the context of diameter-qos. I would >>>>>> say that "operator's administrative domain" is a better term. >>>>>>=20 >>>>>> In any case, I think that the Diameter cloud from the figure 1 >>>>>> should be a generic inter-domain mediator that can handle many >>>>>> applications, of which Diameter QoS is one. The scalable >>>>>> roaming agreements embodied in this cloud should allow the >>>>>> Authorizing Entity to be anywhere in the network. There may be >>>>>> proxies in the Diameter cloud that enforce their own policy >>>>>> decisions, some of which will be local to the Network Element's >>>>>> administrative domain. However, that should not impact the >>>>>> specification of the=20 >>>>>> Diameter QoS Application. This inter-domain operation has been >>>>>> at the core of the document since I started it: see Section 3.2 >>>>>> in the -00 version. >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>> Sun, Dong (Dong) wrote: >>>>>>> Hi Pete, >>>>>>>=20 >>>>>>> Before making any conclusion, I'd like to clarify some terms: >>>>>>> Since you mentioned this is IETF, Internet and such, the domain >>>>>>> you refer to is in the context of the "Autonomous System" or >>>>>>> "operator's administrative domain". >>>>>>>=20 >>>>>>> Dong >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>>> Sent: Wednesday, June 13, 2007 10:27 AM >>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on >>>>>>> the integration of QoS application >>>>>>>=20 >>>>>>> Hi, Dong, >>>>>>>=20 >>>>>>> I think you and I have a fundamental disagreement on the scope >>>>>>> and purpose of this document. I really don't see the need to >>>>>>> standardize >>>>>=20 >>>>>>> an intra-domain localized solution to the problem. This is >>>>>>> IETF we should be solving the problem for the whole Internet, >>>>>>> which means inter-domain is the target. I understand that some >>>>>>> operators might not want to open their networks, but we should >>>>>>> not be defining standards for these closed architectures. >>>>>>>=20 >>>>>>> I also feel strongly that we should have adequate discovery >>>>>>> mechanisms >>>>>>=20 >>>>>>> for all modes of operation specified in this document; >>>>>>> otherwise it could lead to inter-operability problems. >>>>>>>=20 >>>>>>> Hannes, I would like to note this as a serious issue that >>>>>>> should be resolved before we proceed any further. I would like >>>>>>> to check with the mailing list and the ADs on their >>>>>>> preferences. What do you think >>>>>=20 >>>>>>> would be the appropriate way to introduce the issue? Would you >>>>>>> like to introduce the question to the mailing list? >>>>>>>=20 >>>>>>> -Pete >>>>>>>=20 >>>>>>> Sun, Dong (Dong) wrote: >>>>>>>> Hi Pete, >>>>>>>>=20 >>>>>>>> First of all, Thanks for the review and comments. >>>>>>>>=20 >>>>>>>> 1. Concerning the split of Application Server and Authorizing >>>>>>>> Entity, >>>>>>=20 >>>>>>>> which is somewhat related to another main comment you brought >>>>>>>> up i.e. the relationship between Authorizing Entity and NE - >>>>>>>> inter-domain Vs. intra-domain, the rationale in my mind is as >>>>>>>> follow: - In the real network (or the vision of NGN, or >>>>>>>> somewhat the >>>>>=20 >>>>>>>> net neutrality perspective), the packet (transport) network >>>>>>>> should support >>>>>>>=20 >>>>>>>> a variety of applications which may belong to different SPs >>>>>>>> i.e. in different domain. The PDP (i.e. Authorizing entity in >>>>>>>> the context of >>>>>=20 >>>>>>>> QoS application) can act as the arbitrator to isolate the >>>>>>>> diversity of application attributes from the speciality of >>>>>>>> network functionality. The authorizing entity is typically >>>>>>>> part of transport >>>>>=20 >>>>>>>> network domain along with the NEs since the network operators >>>>>>>> are commonly willing to >>>>>>>=20 >>>>>>>> neither rely on the third party to control the use of their >>>>>>>> network resources nor disclose the network details (e.g. >>>>>>>> topology, resource usage and policies) to other carriers/SPs. >>>>>>>> Therefore, the common case is that the interface between >>>>>>>> Authorizing entity and NE (enforcement point) should be >>>>>>>> intra-domain in nature.=20 >>>>>>>>=20 >>>>>>>> - On the other hand, the interface between AS and AE can be >>>>>>>> inter-domain, which also makes the life easier concerning the >>>>>>>> inter-domain enforcement interface. >>>>>>>>=20 >>>>>>>> - The policy communications between different domains is quite >>>>>>>> important, for example, for the roaming scenario. However, it >>>>>>>> is outside the scope of this application if my understanding >>>>>>>> is correct. I feel it is better to be solved through >>>>>>>> inter-Authorizing Entity interface rather than this interface. >>>>>>>> Certainly, the command and AVPs >>>>>>=20 >>>>>>>> might be shared, but I would rather not mix them together for >>>>>>>> the time being.=20 >>>>>>>>=20 >>>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree >>>>>>>> that it >>>>>=20 >>>>>>>> is a tricky issue and also support to describe the issue in >>>>>>>> the document. However, I'd like to point out, this document >>>>>>>> should concentrate on the protocol related issue and allow the >>>>>>>> flexibility to use the other discovery mechanism beyond the >>>>>>>> Diameter protocol capability. In other words, we mainly need >>>>>>>> to define some mechanism based on Diameter protocol's >>>>>>>> capability, such as the realm based routing, and leave the >>>>>>>> door open for other advanced discovery schemes. >>>>>>>>=20 >>>>>>>> See additional comment in line... >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Dong >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>>>> Sent: Tuesday, June 12, 2007 5:26 PM >>>>>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina >>>>>>>> TSOU; >>>>>=20 >>>>>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the >>>>>>>> integration of QoS application >>>>>>>>=20 >>>>>>>> Hi, all, >>>>>>>>=20 >>>>>>>> Please see my comments in line. >>>>>>>>=20 >>>>>>>> Hannes Tschofenig wrote: >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> could you please take a look at the proposal by Dong? >>>>>>>>>=20 >>>>>>>>> They are available here: >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>> http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/dra >>> ft >>>>> -i >>>>>>>> etf-dime-diameter-qos-01-ds.txt >>>>>>>>>=20 >>>>>>>>> The XML file is in the same directory, as usual. >>>>>>>>>=20 >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>>=20 >>>>>>>>> Sun, Dong (Dong) wrote: >>>>>>>>>> Hi Hannes et al, >>>>>>>>>>=20 >>>>>>>>>> Attached is the first cut to integrate two I-Ds. The change >>>>>>>>>> is a minimum set based on the comments from the exploder >>>>>>>>>> (Tina, Christian >>>>>>>=20 >>>>>>>>>> and Tolga). There are some open issues to be done, I'd like >>>>>>>>>> to get >>>>>=20 >>>>>>>>>> your comments on changes first and discuss how to proceed on >>>>>>>>>> those >>>>>=20 >>>>>>>>>> open items before making any further editings. Main changes: >>>>>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push >>>>>>>>>> modes >>>>>>>>=20 >>>>>>>> In the definition of Pull mode, the following sentence >>>>>>>> The Authorizing Entity then installs the QoS >>>>>>>> authorization decision to the Network Element >>>>>>>> initiatively. needs work. "initiatively" is not a word. >>>>>>>>=20 >>>>>>>> [DS] ok. Any good word? Basically I don't like some words such >>>>>>>> as unsolicited since it is used by 3GPP for different meaning. >>>>>>>> Maybe "directly" instead?=20 >>>>>>>>=20 >>>>>>>>>> 2. section 3.1/2: modify the architecture diagram to >>>>>>>>>> separate the Authorizing Entity from AS (further alignment >>>>>>>>>> is needed in the context); and add new subsections to >>>>>>>>>> addressing the endpoint features >>>>>>>>=20 >>>>>>>>>> and push/pull modes. >>>>>>>>=20 >>>>>>>> Breaking up the AS and AE implies that there will be another >>>>>>>> interface >>>>>>>=20 >>>>>>>> yet to be defined. I would rather not open up this >>>>>>>> possibility. The >>>>>>=20 >>>>>>>> Diameter QoS application should be usable all the way from >>>>>>>> network element to application server, perhaps passing through >>>>>>>> an arbitrary number of proxies that enforce their own >>>>>>>> policies, but there should be >>>>>>>=20 >>>>>>>> 1 interface not 2. Also, it is important to note that the AS >>>>>>>> need not >>>>>>>=20 >>>>>>>> be present at all in some >>>>>>>> scenarios: for example, when authorizing requests from a >>>>>>>> static subscriber database. >>>>>>>>=20 >>>>>>>> [DS] First of all, I don't intend to standardize the interface >>>>>>>> between >>>>>>>=20 >>>>>>>> AS and AE in this application. Second, I am not sure why the >>>>>>>> separate >>>>>>=20 >>>>>>>> of AS and AE prevents the AE access to a static subscriber >>>>>>>> database. The basic rationale is address as aforementioned. >>>>>>>>=20 >>>>>>>>>> 3. section 3.3: minor revision on the models for pull; >>>>>>>>>> rewrite the >>>>>=20 >>>>>>>>>> push model (Tina, pls take a look) >>>>>>>>=20 >>>>>>>> 3.2 looks new. It seems to be overly weighted in favor of the >>>>>>>> push model. I would like to point out that there is a big >>>>>>>> discovery problem with the push model, especially when the AE >>>>>>>> and NE are in different administrative domains. The push >>>>>>>> model is only applicable >>>>>=20 >>>>>>>> to the case where the AE and the NE are in the same >>>>>>>> administrative domain and therefore it is a special case. >>>>>>>>=20 >>>>>>>> [DS] I think in reality the operators mainly look at the >>>>>>>> intra-domain >>>>>>=20 >>>>>>>> policy enforcement interface, whatever pull or push models. I >>>>>>>> am not >>>>>=20 >>>>>>>> in favor of any specific models, just analyze the impact of >>>>>>>> endpoint's >>>>>>>=20 >>>>>>>> capability. If you have any words that can enhance the pull >>>>>>>> model, it >>>>>>=20 >>>>>>>> is very welcome :-). >>>>>>>>=20 >>>>>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section >>>>>>>>>> 7.4 and >>>>>>>>=20 >>>>>>>>>> table. But the name still remains in some texts. >>>>>>>>>>=20 >>>>>>>>>> To be done: >>>>>>>>>> 1. state mechanism for Push mode: server initiated policy >>>>>>>>>> installation 2. should section 4.4 be merged with section >>>>>>>>>> 4.2 since >>>>>>=20 >>>>>>>>>> both them discuss how to initiate a new Diameter session? In >>>>>>>>>> addition, the text needs to be beefed up for server >>>>>>>>>> initiated session.=20 >>>>>>>>>> 3. authorization schemes/models for Pull: inter-domain >>>>>>>>>> authorization >>>>>>>=20 >>>>>>>>>> between authorizing entity and NE is not envisaged as the >>>>>>>>>> basic model, should be revised in the context; Token based >>>>>>>>>> approach is not >>>>>>>=20 >>>>>>>>>> the main trend, should be shortened. >>>>>>>>=20 >>>>>>>> We need to have inter-domain authorization as the basic >>>>>>>> scenario; local authorization should be treated as a special >>>>>>>> case. The whole point is to leverage the inter-domain >>>>>>>> capability of Diameter to mediate between network elements and >>>>>>>> authorizing entities, whether the AEs are application servers >>>>>>>> or static subscriber databases. >>>>>>>>=20 >>>>>>>> [DS] I agree that inter-domain authorization/policy >>>>>>>> communication is >>>>>=20 >>>>>>>> important, but the mechanism and scope of this document is >>>>>>>> inappropriate to solve that issue, since it is not the right >>>>>>>> way forward envisioned by the industry and operators. >>>>>>>>=20 >>>>>>>> If we only solve the local case it will mean that an >>>>>>>> application server has to be co-located in the local domain. >>>>>>>> This is not the way >>>>>>=20 >>>>>>>> the Internet is supposed to work: services should be >>>>>>>> deployable end-to-end, without modifying elements of the >>>>>>>> network along the path. It should be possible for the >>>>>>>> application server to be located >>>>>=20 >>>>>>>> anywhere in the network and the AAA part should just work. >>>>>>>>=20 >>>>>>>> [DS] as I said, the AS and AE can be in different domains. On >>>>>>>> the other hand, if we integrate the AS with AE together, it >>>>>>>> impose a tight >>>>>>>=20 >>>>>>>> coupled service model, i.e. AS and AE always have to be in the >>>>>>>> same domain. Exactly the issue you are concerned. >>>>>>>>=20 >>>>>>>>>> 4. The current doc mainly talks about the QoS, should add >>>>>>>>>> some tint >>>>>>=20 >>>>>>>>>> on the policy control side. >>>>>>>>>>=20 >>>>>>>>>> Please let me know your opinion and how to proceed. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Dong >>>>>>>>=20 >>>>>>>> -Pete >>>=20 >>>=20 >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>> End of DiME Digest, Vol 18, Issue 13 >>> ************************************ >>>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 19 12:16:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gNK-00069M-IV; Tue, 19 Jun 2007 12:16:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gNJ-00062U-9i for dime@ietf.org; Tue, 19 Jun 2007 12:16:13 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0gNG-00042Z-Ej for dime@ietf.org; Tue, 19 Jun 2007 12:16:13 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1182269769!22676302!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25830 invoked from network); 19 Jun 2007 16:16:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 19 Jun 2007 16:16:09 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JGG9BW014233 for ; Tue, 19 Jun 2007 09:16:09 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5JGG8EL013402 for ; Tue, 19 Jun 2007 11:16:08 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JGG6Re013369 for ; Tue, 19 Jun 2007 11:16:07 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] FW: First draft on the integration of QoS application Date: Tue, 19 Jun 2007 12:16:05 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7187F9F@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: First draft on the integration of QoS application thread-index: AcetISvGTMneLoT9RHySt6sElj/kSQADAwBAAAQSw0AAIhfZoAAA/rRwAAA4YPAAALX/UAAEvulgAAHFv2AAAzbrgAAEo/mQACyi5MAA9NG4UA== References: <033458F56EC2A64E8D2D7B759FA3E7E7187F9F@sonusmail04.sonusnet.com> From: "McCann Peter-A001034" To: "Asveren, Tolga" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Tolga, I agree that we should have the flexibility for the diameter-qos application to be inter-domain. As such, we need to define everything needed to make that work for both the push and pull modes, including discovery and routing of messages end-to-end. -Pete Asveren, Tolga wrote: > IMHO it makes sense to separate AF and PDF functionalities depending > on the network topology/business model. It provides a single point of > contact for AF, if the service instance requires QoS reservations in > multiple networks/devices etc... =20 >=20 > OTOH, I have no strong opinion in terms of where the inter-domain > boundary is going to be. It could be that both AF/PDF and PDF/PEP > interfaces are inter-domain for a specific service instance. Probably > this is not something for us to decide but we need to have the > flexibility to support all models (if possible). =20 >=20 > I guess IETF QoS work can address both interfaces. PDF can act as a > Diameter proxy, Diameter B2BUA type of entity etc... or may not be in > the picture at all depending on the business model. What problem do > we see with this approach? =20 >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Wednesday, June 13, 2007 6:08 PM >> To: dime@ietf.org >> Subject: [Dime] FW: First draft on the integration of QoS application >>=20 >> Below is a discussion thread that has been taking place among authors >> of the diameter-qos draft. We thought it important that the mailing >> list have some visibility to the discussion. Comments welcome. >>=20 >> -Pete >>=20 >> McCann Peter-A001034 wrote: >>> Hi, Dong, >>>=20 >>> I guess I don't see why we need two separate interfaces. They are >>> each transporting roughly the same information and doing the same >>> sort of job.=20 >>>=20 >>> The current document in my mind has always been an inter-domain >>> interface. See the abstract:=20 >>>=20 >>> ...Clients that implement the Diameter QoS application contact an >>> authorizing entity/application server that is located somewhere >>> in the network, allowing for a wide variety of flexible >>> deployment models.=20 >>>=20 >>> And the following text in Section 3.2: >>>=20 >>> Inter-domain support >>>=20 >>> In particular, users may roam outside their home network, >>> leading to a situation where the network element and >>> authorizing entity are in different administrative domains. >>>=20 >>> -Pete >>>=20 >>> Sun, Dong (Dong) wrote: >>>> Hi Pete, >>>> I have no doubt about the importance of inter-domain policy >>>> communications, and it might be better to use the Diameter broker >>>> instead of SIP proxy to deal with inter-domain resource management. >>>> In fact, I think 3GPP does use the similar model as you described, >>>> that a Diameter broker (client) is embedded in the AF (e.g. >>>> P-CSCF), and the interface between AF and underlying Policy engine >>>> (e.g. PCRF) is an inter-domain interface per se. certainly, since >>>> they (SIP and Diameter brokers) are grouped together, it is less >>>> flexible and scalable for the implementation. >>>>=20 >>>> However, I think this interface (named as Rx in 3GPP, Gq' in >>>> TISPAN, Rs in ITU) is not for the control of policy enforcement >>>> directly. In my view, this interface (Rx) is a peering interface >>>> between policy servers rather than between policy server and >>>> enforcement point as described in the current QoS application, and >>>> I believe it is more appropriate to model the inter-domain >>>> interface as the policy server to policy server (PDF-PDF) peering >>>> interface.=20 >>>>=20 >>>> I have no problem to develop a doc to address this inter-domain >>>> application, however, if you look around the current document, I >>>> did not see any indication from that perspective. >>>>=20 >>>> Dong >>>>=20 >>>> -----Original Message----- >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>> Sent: Wednesday, June 13, 2007 2:11 PM >>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on >>>> the integration of QoS application=20 >>>>=20 >>>> Hi, Dong, >>>>=20 >>>> Sun, Dong (Dong) wrote: >>>>> Hi Pete, >>>>>=20 >>>>> Thanks for clarification. Just wondering if you can give an >>>>> example who will use the "inter-domain" model for policy >>>>> enforcement control, i.e. PDP and PEP reside in the different >>>>> operator's administrative domains. Since the inter-domain is to >>>>> serve for the operator's domain, I don't know how to create an >>>>> application without considering their need. (BTW, I have no >>>>> strong view to limit it to intra-domain only if the use case can >>>>> be identified).=20 >>>>=20 >>>> Arbitrary third parties should be allowed to deploy application >>>> servers and interface to the Diameter cloud to get QoS from the >>>> network. The Diameter QoS Application should play this role. >>>> In the extreme case, I should be allowed to put a SIP server in my >>>> basement, sign up with a Diameter broker, and run my application >>>> end-to-end.=20 >>>>=20 >>>>> I agree that this application should support "a generic mediator >>>>> that can handle many applications". However, Given the integrated >>>>> AS and AE, it makes the AE has to be collocated with the >>>>> application content providers rather than the network itself, I >>>>> feel it is also too limited and not the common case in reality. >>>>> (As far as I know, all deployed or emerging network >>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view >>>>> this solution as the main trend). I am wondering who will use >>>>> this application eventually. >>>>=20 >>>> I am not ruling out a PDP in the network local to the PEP. I am >>>> just saying that this PDP should be viewed as a Diameter proxy on >>>> the path to the Authorizing Entity, which itself may be either a >>>> static subscriber database or an active application server. >>>> I don't want to work only on the localized protocol, I want to >>>> define the inter-domain one. If you insist on separating the AE >>>> from the AS then I would say that the important Diameter interface >>>> is the one between AE and AS. It is much more important to >>>> standardize the inter-domain interface because this is the one >>>> that will be used between operators.=20 >>>>=20 >>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they are >>>> going down the path of using SIP proxies as the inter-domain >>>> interface. I think this architecture is bad for the Internet, and >>>> will limit the kinds of applications that can be deployed. >>>> The Internet model is that applications should be deployable >>>> without modifying the middleboxes. Tying SIP servers to the >>>> network traffic path also doesn't work well with Mobile IP. >>>>=20 >>>>> In addition, the scalable roaming agreements sound like a general >>>>> algorithm that may be applicable for any inter-domain issue in the >>>>> context of Diameter applications, or it is only the fundament to >>>>> this application? >>>>=20 >>>> The Diameter NASREQ application (similar to the basic RADIUS >>>> protocol) has always been about inter-domain operation. Diameter >>>> is used as the mediating protocol between different operator >>>> domains. I think we should be following the same model with the >>>> Diameter QoS application.=20 >>>>=20 >>>> -Pete >>>>=20 >>>>> Dong >>>>>=20 >>>>> -----Original Message----- >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>> Sent: Wednesday, June 13, 2007 11:06 AM >>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on >>>>> the integration of QoS application >>>>>=20 >>>>> Hi, Dong, >>>>>=20 >>>>> An "Autonomous System" has a very specific meaning in the context >>>>> of routing protocols; I would not want to say that they correspond >>>>> one-to-one with the "domains" that exist when I talk about >>>>> "inter-domain" in the context of diameter-qos. I would say that >>>>> "operator's administrative domain" is a better term. >>>>>=20 >>>>> In any case, I think that the Diameter cloud from the figure 1 >>>>> should be a generic inter-domain mediator that can handle many >>>>> applications, of which Diameter QoS is one. The scalable roaming >>>>> agreements embodied in this cloud should allow the Authorizing >>>>> Entity to be anywhere in the network. There may be proxies in the >>>>> Diameter cloud that enforce their own policy decisions, some of >>>>> which will be local to the Network Element's administrative >>>>> domain. However, that should not impact the specification of the >>>>> Diameter QoS Application. This inter-domain operation has been at >>>>> the core of the document since I started it: see Section 3.2 in >>>>> the -00 version.=20 >>>>>=20 >>>>> -Pete >>>>>=20 >>>>> Sun, Dong (Dong) wrote: >>>>>> Hi Pete, >>>>>>=20 >>>>>> Before making any conclusion, I'd like to clarify some terms: >>>>>> Since you mentioned this is IETF, Internet and such, the domain >>>>>> you refer to is in the context of the "Autonomous System" or >>>>>> "operator's administrative domain". >>>>>>=20 >>>>>> Dong >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>> Sent: Wednesday, June 13, 2007 10:27 AM >>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on >>>>>> the integration of QoS application >>>>>>=20 >>>>>> Hi, Dong, >>>>>>=20 >>>>>> I think you and I have a fundamental disagreement on the scope >>>>>> and purpose of this document. I really don't see the need to >>>>>> standardize >>>>=20 >>>>>> an intra-domain localized solution to the problem. This is IETF >>>>>> we should be solving the problem for the whole Internet, which >>>>>> means inter-domain is the target. I understand that some >>>>>> operators might not want to open their networks, but we should >>>>>> not be defining standards for these closed architectures. >>>>>>=20 >>>>>> I also feel strongly that we should have adequate discovery >>>>>> mechanisms >>>>>=20 >>>>>> for all modes of operation specified in this document; otherwise >>>>>> it could lead to inter-operability problems. >>>>>>=20 >>>>>> Hannes, I would like to note this as a serious issue that should >>>>>> be resolved before we proceed any further. I would like to >>>>>> check with the mailing list and the ADs on their preferences.=20 >>>>>> What do you think >>>>=20 >>>>>> would be the appropriate way to introduce the issue? Would you >>>>>> like to introduce the question to the mailing list? >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>> Sun, Dong (Dong) wrote: >>>>>>> Hi Pete, >>>>>>>=20 >>>>>>> First of all, Thanks for the review and comments. >>>>>>>=20 >>>>>>> 1. Concerning the split of Application Server and Authorizing >>>>>>> Entity, >>>>>=20 >>>>>>> which is somewhat related to another main comment you brought up >>>>>>> i.e. the relationship between Authorizing Entity and NE - >>>>>>> inter-domain Vs. intra-domain, the rationale in my mind is as >>>>>>> follow: - In the real network (or the vision of NGN, or somewhat >>>>>>> the >>>>=20 >>>>>>> net neutrality perspective), the packet (transport) network >>>>>>> should support >>>>>>=20 >>>>>>> a variety of applications which may belong to different SPs i.e. >>>>>>> in different domain. The PDP (i.e. Authorizing entity in the >>>>>>> context of >>>>=20 >>>>>>> QoS application) can act as the arbitrator to isolate the >>>>>>> diversity of application attributes from the speciality of >>>>>>> network functionality. The authorizing entity is typically part >>>>>>> of transport >>>>=20 >>>>>>> network domain along with the NEs since the network operators >>>>>>> are commonly willing to >>>>>>=20 >>>>>>> neither rely on the third party to control the use of their >>>>>>> network resources nor disclose the network details (e.g. >>>>>>> topology, resource usage and policies) to other carriers/SPs. >>>>>>> Therefore, the common case is that the interface between >>>>>>> Authorizing entity and NE (enforcement point) should be >>>>>>> intra-domain in nature.=20 >>>>>>>=20 >>>>>>> - On the other hand, the interface between AS and AE can be >>>>>>> inter-domain, which also makes the life easier concerning the >>>>>>> inter-domain enforcement interface. >>>>>>>=20 >>>>>>> - The policy communications between different domains is quite >>>>>>> important, for example, for the roaming scenario. However, it is >>>>>>> outside the scope of this application if my understanding is >>>>>>> correct. I feel it is better to be solved through >>>>>>> inter-Authorizing Entity interface rather than this interface. >>>>>>> Certainly, the command and AVPs >>>>>=20 >>>>>>> might be shared, but I would rather not mix them together for >>>>>>> the time being.=20 >>>>>>>=20 >>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree >>>>>>> that it >>>>=20 >>>>>>> is a tricky issue and also support to describe the issue in the >>>>>>> document. However, I'd like to point out, this document should >>>>>>> concentrate on the protocol related issue and allow the >>>>>>> flexibility to use the other discovery mechanism beyond the >>>>>>> Diameter protocol capability. In other words, we mainly need to >>>>>>> define some mechanism based on Diameter protocol's capability, >>>>>>> such as the realm based routing, and leave the door open for >>>>>>> other advanced discovery schemes. >>>>>>>=20 >>>>>>> See additional comment in line... >>>>>>>=20 >>>>>>> Regards, >>>>>>> Dong >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>>> Sent: Tuesday, June 12, 2007 5:26 PM >>>>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina >>>>>>> TSOU; >>>>=20 >>>>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the >>>>>>> integration of QoS application >>>>>>>=20 >>>>>>> Hi, all, >>>>>>>=20 >>>>>>> Please see my comments in line. >>>>>>>=20 >>>>>>> Hannes Tschofenig wrote: >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> could you please take a look at the proposal by Dong? >>>>>>>>=20 >>>>>>>> They are available here: >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >> http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft >>>> -i >>>>>>> etf-dime-diameter-qos-01-ds.txt >>>>>>>>=20 >>>>>>>> The XML file is in the same directory, as usual. >>>>>>>>=20 >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>>=20 >>>>>>>> Sun, Dong (Dong) wrote: >>>>>>>>> Hi Hannes et al, >>>>>>>>>=20 >>>>>>>>> Attached is the first cut to integrate two I-Ds. The change >>>>>>>>> is a minimum set based on the comments from the exploder >>>>>>>>> (Tina, Christian >>>>>>=20 >>>>>>>>> and Tolga). There are some open issues to be done, I'd like to >>>>>>>>> get >>>>=20 >>>>>>>>> your comments on changes first and discuss how to proceed on >>>>>>>>> those >>>>=20 >>>>>>>>> open items before making any further editings. Main changes: >>>>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push modes >>>>>>>=20 >>>>>>> In the definition of Pull mode, the following sentence >>>>>>> The Authorizing Entity then installs the QoS >>>>>>> authorization decision to the Network Element >>>>>>> initiatively. needs work. "initiatively" is not a word. >>>>>>>=20 >>>>>>> [DS] ok. Any good word? Basically I don't like some words such >>>>>>> as unsolicited since it is used by 3GPP for different meaning. >>>>>>> Maybe "directly" instead?=20 >>>>>>>=20 >>>>>>>>> 2. section 3.1/2: modify the architecture diagram to separate >>>>>>>>> the Authorizing Entity from AS (further alignment is needed in >>>>>>>>> the context); and add new subsections to addressing the >>>>>>>>> endpoint features >>>>>>>=20 >>>>>>>>> and push/pull modes. >>>>>>>=20 >>>>>>> Breaking up the AS and AE implies that there will be another >>>>>>> interface >>>>>>=20 >>>>>>> yet to be defined. I would rather not open up this possibility. >>>>>>> The >>>>>=20 >>>>>>> Diameter QoS application should be usable all the way from >>>>>>> network element to application server, perhaps passing through >>>>>>> an arbitrary number of proxies that enforce their own policies, >>>>>>> but there should be >>>>>>=20 >>>>>>> 1 interface not 2. Also, it is important to note that the AS >>>>>>> need not >>>>>>=20 >>>>>>> be present at all in some >>>>>>> scenarios: for example, when authorizing requests from a static >>>>>>> subscriber database.=20 >>>>>>>=20 >>>>>>> [DS] First of all, I don't intend to standardize the interface >>>>>>> between >>>>>>=20 >>>>>>> AS and AE in this application. Second, I am not sure why the >>>>>>> separate >>>>>=20 >>>>>>> of AS and AE prevents the AE access to a static subscriber >>>>>>> database. The basic rationale is address as aforementioned. >>>>>>>=20 >>>>>>>>> 3. section 3.3: minor revision on the models for pull; rewrite >>>>>>>>> the >>>>=20 >>>>>>>>> push model (Tina, pls take a look) >>>>>>>=20 >>>>>>> 3.2 looks new. It seems to be overly weighted in favor of the >>>>>>> push model. I would like to point out that there is a big >>>>>>> discovery problem with the push model, especially when the AE >>>>>>> and NE are in different administrative domains. The push model >>>>>>> is only applicable >>>>=20 >>>>>>> to the case where the AE and the NE are in the same >>>>>>> administrative domain and therefore it is a special case. >>>>>>>=20 >>>>>>> [DS] I think in reality the operators mainly look at the >>>>>>> intra-domain >>>>>=20 >>>>>>> policy enforcement interface, whatever pull or push models. I am >>>>>>> not >>>>=20 >>>>>>> in favor of any specific models, just analyze the impact of >>>>>>> endpoint's >>>>>>=20 >>>>>>> capability. If you have any words that can enhance the pull >>>>>>> model, it >>>>>=20 >>>>>>> is very welcome :-). >>>>>>>=20 >>>>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section >>>>>>>>> 7.4 and >>>>>>>=20 >>>>>>>>> table. But the name still remains in some texts. >>>>>>>>>=20 >>>>>>>>> To be done: >>>>>>>>> 1. state mechanism for Push mode: server initiated policy >>>>>>>>> installation 2. should section 4.4 be merged with section 4.2 >>>>>>>>> since >>>>>=20 >>>>>>>>> both them discuss how to initiate a new Diameter session? In >>>>>>>>> addition, the text needs to be beefed up for server initiated >>>>>>>>> session.=20 >>>>>>>>> 3. authorization schemes/models for Pull: inter-domain >>>>>>>>> authorization >>>>>>=20 >>>>>>>>> between authorizing entity and NE is not envisaged as the >>>>>>>>> basic model, should be revised in the context; Token based >>>>>>>>> approach is not >>>>>>=20 >>>>>>>>> the main trend, should be shortened. >>>>>>>=20 >>>>>>> We need to have inter-domain authorization as the basic >>>>>>> scenario; local authorization should be treated as a special >>>>>>> case. The whole point is to leverage the inter-domain >>>>>>> capability of Diameter to mediate between network elements and >>>>>>> authorizing entities, whether the AEs are application servers >>>>>>> or static subscriber databases.=20 >>>>>>>=20 >>>>>>> [DS] I agree that inter-domain authorization/policy >>>>>>> communication is >>>>=20 >>>>>>> important, but the mechanism and scope of this document is >>>>>>> inappropriate to solve that issue, since it is not the right way >>>>>>> forward envisioned by the industry and operators. >>>>>>>=20 >>>>>>> If we only solve the local case it will mean that an application >>>>>>> server has to be co-located in the local domain. This is not >>>>>>> the way >>>>>=20 >>>>>>> the Internet is supposed to work: services should be deployable >>>>>>> end-to-end, without modifying elements of the network along the >>>>>>> path. It should be possible for the application server to be >>>>>>> located >>>>=20 >>>>>>> anywhere in the network and the AAA part should just work. >>>>>>>=20 >>>>>>> [DS] as I said, the AS and AE can be in different domains. On >>>>>>> the other hand, if we integrate the AS with AE together, it >>>>>>> impose a tight >>>>>>=20 >>>>>>> coupled service model, i.e. AS and AE always have to be in the >>>>>>> same domain. Exactly the issue you are concerned. >>>>>>>=20 >>>>>>>>> 4. The current doc mainly talks about the QoS, should add some >>>>>>>>> tint >>>>>=20 >>>>>>>>> on the policy control side. >>>>>>>>>=20 >>>>>>>>> Please let me know your opinion and how to proceed. >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Dong >>>>>>>=20 >>>>>>> -Pete >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 19 17:36:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lNA-0004oc-ND; Tue, 19 Jun 2007 17:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lN9-0004eZ-AU for dime@ietf.org; Tue, 19 Jun 2007 17:36:23 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lN7-0001oF-GU for dime@ietf.org; Tue, 19 Jun 2007 17:36:23 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l5JLaLiV021947; Tue, 19 Jun 2007 17:36:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] FW: First draft on the integration of QoS application Date: Tue, 19 Jun 2007 17:36:21 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7187FBB@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: First draft on the integration of QoS application Thread-Index: AcetISvGTMneLoT9RHySt6sElj/kSQADAwBAAAQSw0AAIhfZoAAA/rRwAAA4YPAAALX/UAAEvulgAAHFv2AAAzbrgAAEo/mQACyi5MAA9NG4UAALIyWw References: <033458F56EC2A64E8D2D7B759FA3E7E7187F9F@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 64592953d6410e1f725ee21266e2f396 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Pete, I think I agree with you overall just I think we need to be careful about what we mean with "discovery". It could be that it is better to leave it implementation dependent/out of scope of Diameter QoS protocol, how a Diameter node selects the next-hop for the initial request for a session. Thanks, Tolga > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, June 19, 2007 12:16 PM > To: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] FW: First draft on the integration of QoS application >=20 > Hi, Tolga, >=20 > I agree that we should have the flexibility for the > diameter-qos application to be inter-domain. As such, > we need to define everything needed to make that work > for both the push and pull modes, including discovery > and routing of messages end-to-end. >=20 > -Pete >=20 >=20 > Asveren, Tolga wrote: > > IMHO it makes sense to separate AF and PDF functionalities depending > > on the network topology/business model. It provides a single point of > > contact for AF, if the service instance requires QoS reservations in > > multiple networks/devices etc... > > > > OTOH, I have no strong opinion in terms of where the inter-domain > > boundary is going to be. It could be that both AF/PDF and PDF/PEP > > interfaces are inter-domain for a specific service instance. Probably > > this is not something for us to decide but we need to have the > > flexibility to support all models (if possible). > > > > I guess IETF QoS work can address both interfaces. PDF can act as a > > Diameter proxy, Diameter B2BUA type of entity etc... or may not be in > > the picture at all depending on the business model. What problem do > > we see with this approach? > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >> Sent: Wednesday, June 13, 2007 6:08 PM > >> To: dime@ietf.org > >> Subject: [Dime] FW: First draft on the integration of QoS application > >> > >> Below is a discussion thread that has been taking place among authors > >> of the diameter-qos draft. We thought it important that the mailing > >> list have some visibility to the discussion. Comments welcome. > >> > >> -Pete > >> > >> McCann Peter-A001034 wrote: > >>> Hi, Dong, > >>> > >>> I guess I don't see why we need two separate interfaces. They are > >>> each transporting roughly the same information and doing the same > >>> sort of job. > >>> > >>> The current document in my mind has always been an inter-domain > >>> interface. See the abstract: > >>> > >>> ...Clients that implement the Diameter QoS application contact an > >>> authorizing entity/application server that is located somewhere > >>> in the network, allowing for a wide variety of flexible > >>> deployment models. > >>> > >>> And the following text in Section 3.2: > >>> > >>> Inter-domain support > >>> > >>> In particular, users may roam outside their home network, > >>> leading to a situation where the network element and > >>> authorizing entity are in different administrative domains. > >>> > >>> -Pete > >>> > >>> Sun, Dong (Dong) wrote: > >>>> Hi Pete, > >>>> I have no doubt about the importance of inter-domain policy > >>>> communications, and it might be better to use the Diameter broker > >>>> instead of SIP proxy to deal with inter-domain resource management. > >>>> In fact, I think 3GPP does use the similar model as you described, > >>>> that a Diameter broker (client) is embedded in the AF (e.g. > >>>> P-CSCF), and the interface between AF and underlying Policy engine > >>>> (e.g. PCRF) is an inter-domain interface per se. certainly, since > >>>> they (SIP and Diameter brokers) are grouped together, it is less > >>>> flexible and scalable for the implementation. > >>>> > >>>> However, I think this interface (named as Rx in 3GPP, Gq' in > >>>> TISPAN, Rs in ITU) is not for the control of policy enforcement > >>>> directly. In my view, this interface (Rx) is a peering interface > >>>> between policy servers rather than between policy server and > >>>> enforcement point as described in the current QoS application, and > >>>> I believe it is more appropriate to model the inter-domain > >>>> interface as the policy server to policy server (PDF-PDF) peering > >>>> interface. > >>>> > >>>> I have no problem to develop a doc to address this inter-domain > >>>> application, however, if you look around the current document, I > >>>> did not see any indication from that perspective. > >>>> > >>>> Dong > >>>> > >>>> -----Original Message----- > >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>> Sent: Wednesday, June 13, 2007 2:11 PM > >>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>> the integration of QoS application > >>>> > >>>> Hi, Dong, > >>>> > >>>> Sun, Dong (Dong) wrote: > >>>>> Hi Pete, > >>>>> > >>>>> Thanks for clarification. Just wondering if you can give an > >>>>> example who will use the "inter-domain" model for policy > >>>>> enforcement control, i.e. PDP and PEP reside in the different > >>>>> operator's administrative domains. Since the inter-domain is to > >>>>> serve for the operator's domain, I don't know how to create an > >>>>> application without considering their need. (BTW, I have no > >>>>> strong view to limit it to intra-domain only if the use case can > >>>>> be identified). > >>>> > >>>> Arbitrary third parties should be allowed to deploy application > >>>> servers and interface to the Diameter cloud to get QoS from the > >>>> network. The Diameter QoS Application should play this role. > >>>> In the extreme case, I should be allowed to put a SIP server in my > >>>> basement, sign up with a Diameter broker, and run my application > >>>> end-to-end. > >>>> > >>>>> I agree that this application should support "a generic mediator > >>>>> that can handle many applications". However, Given the integrated > >>>>> AS and AE, it makes the AE has to be collocated with the > >>>>> application content providers rather than the network itself, I > >>>>> feel it is also too limited and not the common case in reality. > >>>>> (As far as I know, all deployed or emerging network > >>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view > >>>>> this solution as the main trend). I am wondering who will use > >>>>> this application eventually. > >>>> > >>>> I am not ruling out a PDP in the network local to the PEP. I am > >>>> just saying that this PDP should be viewed as a Diameter proxy on > >>>> the path to the Authorizing Entity, which itself may be either a > >>>> static subscriber database or an active application server. > >>>> I don't want to work only on the localized protocol, I want to > >>>> define the inter-domain one. If you insist on separating the AE > >>>> from the AS then I would say that the important Diameter interface > >>>> is the one between AE and AS. It is much more important to > >>>> standardize the inter-domain interface because this is the one > >>>> that will be used between operators. > >>>> > >>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they are > >>>> going down the path of using SIP proxies as the inter-domain > >>>> interface. I think this architecture is bad for the Internet, and > >>>> will limit the kinds of applications that can be deployed. > >>>> The Internet model is that applications should be deployable > >>>> without modifying the middleboxes. Tying SIP servers to the > >>>> network traffic path also doesn't work well with Mobile IP. > >>>> > >>>>> In addition, the scalable roaming agreements sound like a general > >>>>> algorithm that may be applicable for any inter-domain issue in the > >>>>> context of Diameter applications, or it is only the fundament to > >>>>> this application? > >>>> > >>>> The Diameter NASREQ application (similar to the basic RADIUS > >>>> protocol) has always been about inter-domain operation. Diameter > >>>> is used as the mediating protocol between different operator > >>>> domains. I think we should be following the same model with the > >>>> Diameter QoS application. > >>>> > >>>> -Pete > >>>> > >>>>> Dong > >>>>> > >>>>> -----Original Message----- > >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>> Sent: Wednesday, June 13, 2007 11:06 AM > >>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>> the integration of QoS application > >>>>> > >>>>> Hi, Dong, > >>>>> > >>>>> An "Autonomous System" has a very specific meaning in the context > >>>>> of routing protocols; I would not want to say that they correspond > >>>>> one-to-one with the "domains" that exist when I talk about > >>>>> "inter-domain" in the context of diameter-qos. I would say that > >>>>> "operator's administrative domain" is a better term. > >>>>> > >>>>> In any case, I think that the Diameter cloud from the figure 1 > >>>>> should be a generic inter-domain mediator that can handle many > >>>>> applications, of which Diameter QoS is one. The scalable roaming > >>>>> agreements embodied in this cloud should allow the Authorizing > >>>>> Entity to be anywhere in the network. There may be proxies in the > >>>>> Diameter cloud that enforce their own policy decisions, some of > >>>>> which will be local to the Network Element's administrative > >>>>> domain. However, that should not impact the specification of the > >>>>> Diameter QoS Application. This inter-domain operation has been at > >>>>> the core of the document since I started it: see Section 3.2 in > >>>>> the -00 version. > >>>>> > >>>>> -Pete > >>>>> > >>>>> Sun, Dong (Dong) wrote: > >>>>>> Hi Pete, > >>>>>> > >>>>>> Before making any conclusion, I'd like to clarify some terms: > >>>>>> Since you mentioned this is IETF, Internet and such, the domain > >>>>>> you refer to is in the context of the "Autonomous System" or > >>>>>> "operator's administrative domain". > >>>>>> > >>>>>> Dong > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>> Sent: Wednesday, June 13, 2007 10:27 AM > >>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>> the integration of QoS application > >>>>>> > >>>>>> Hi, Dong, > >>>>>> > >>>>>> I think you and I have a fundamental disagreement on the scope > >>>>>> and purpose of this document. I really don't see the need to > >>>>>> standardize > >>>> > >>>>>> an intra-domain localized solution to the problem. This is IETF > >>>>>> we should be solving the problem for the whole Internet, which > >>>>>> means inter-domain is the target. I understand that some > >>>>>> operators might not want to open their networks, but we should > >>>>>> not be defining standards for these closed architectures. > >>>>>> > >>>>>> I also feel strongly that we should have adequate discovery > >>>>>> mechanisms > >>>>> > >>>>>> for all modes of operation specified in this document; otherwise > >>>>>> it could lead to inter-operability problems. > >>>>>> > >>>>>> Hannes, I would like to note this as a serious issue that should > >>>>>> be resolved before we proceed any further. I would like to > >>>>>> check with the mailing list and the ADs on their preferences. > >>>>>> What do you think > >>>> > >>>>>> would be the appropriate way to introduce the issue? Would you > >>>>>> like to introduce the question to the mailing list? > >>>>>> > >>>>>> -Pete > >>>>>> > >>>>>> Sun, Dong (Dong) wrote: > >>>>>>> Hi Pete, > >>>>>>> > >>>>>>> First of all, Thanks for the review and comments. > >>>>>>> > >>>>>>> 1. Concerning the split of Application Server and Authorizing > >>>>>>> Entity, > >>>>> > >>>>>>> which is somewhat related to another main comment you brought up > >>>>>>> i.e. the relationship between Authorizing Entity and NE - > >>>>>>> inter-domain Vs. intra-domain, the rationale in my mind is as > >>>>>>> follow: - In the real network (or the vision of NGN, or somewhat > >>>>>>> the > >>>> > >>>>>>> net neutrality perspective), the packet (transport) network > >>>>>>> should support > >>>>>> > >>>>>>> a variety of applications which may belong to different SPs i.e. > >>>>>>> in different domain. The PDP (i.e. Authorizing entity in the > >>>>>>> context of > >>>> > >>>>>>> QoS application) can act as the arbitrator to isolate the > >>>>>>> diversity of application attributes from the speciality of > >>>>>>> network functionality. The authorizing entity is typically part > >>>>>>> of transport > >>>> > >>>>>>> network domain along with the NEs since the network operators > >>>>>>> are commonly willing to > >>>>>> > >>>>>>> neither rely on the third party to control the use of their > >>>>>>> network resources nor disclose the network details (e.g. > >>>>>>> topology, resource usage and policies) to other carriers/SPs. > >>>>>>> Therefore, the common case is that the interface between > >>>>>>> Authorizing entity and NE (enforcement point) should be > >>>>>>> intra-domain in nature. > >>>>>>> > >>>>>>> - On the other hand, the interface between AS and AE can be > >>>>>>> inter-domain, which also makes the life easier concerning the > >>>>>>> inter-domain enforcement interface. > >>>>>>> > >>>>>>> - The policy communications between different domains is quite > >>>>>>> important, for example, for the roaming scenario. However, it is > >>>>>>> outside the scope of this application if my understanding is > >>>>>>> correct. I feel it is better to be solved through > >>>>>>> inter-Authorizing Entity interface rather than this interface. > >>>>>>> Certainly, the command and AVPs > >>>>> > >>>>>>> might be shared, but I would rather not mix them together for > >>>>>>> the time being. > >>>>>>> > >>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree > >>>>>>> that it > >>>> > >>>>>>> is a tricky issue and also support to describe the issue in the > >>>>>>> document. However, I'd like to point out, this document should > >>>>>>> concentrate on the protocol related issue and allow the > >>>>>>> flexibility to use the other discovery mechanism beyond the > >>>>>>> Diameter protocol capability. In other words, we mainly need to > >>>>>>> define some mechanism based on Diameter protocol's capability, > >>>>>>> such as the realm based routing, and leave the door open for > >>>>>>> other advanced discovery schemes. > >>>>>>> > >>>>>>> See additional comment in line... > >>>>>>> > >>>>>>> Regards, > >>>>>>> Dong > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>> Sent: Tuesday, June 12, 2007 5:26 PM > >>>>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina > >>>>>>> TSOU; > >>>> > >>>>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > >>>>>>> integration of QoS application > >>>>>>> > >>>>>>> Hi, all, > >>>>>>> > >>>>>>> Please see my comments in line. > >>>>>>> > >>>>>>> Hannes Tschofenig wrote: > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> could you please take a look at the proposal by Dong? > >>>>>>>> > >>>>>>>> They are available here: > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft > >>>> -i > >>>>>>> etf-dime-diameter-qos-01-ds.txt > >>>>>>>> > >>>>>>>> The XML file is in the same directory, as usual. > >>>>>>>> > >>>>>>>> Ciao > >>>>>>>> Hannes > >>>>>>>> > >>>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>>> Hi Hannes et al, > >>>>>>>>> > >>>>>>>>> Attached is the first cut to integrate two I-Ds. The change > >>>>>>>>> is a minimum set based on the comments from the exploder > >>>>>>>>> (Tina, Christian > >>>>>> > >>>>>>>>> and Tolga). There are some open issues to be done, I'd like to > >>>>>>>>> get > >>>> > >>>>>>>>> your comments on changes first and discuss how to proceed on > >>>>>>>>> those > >>>> > >>>>>>>>> open items before making any further editings. Main changes: > >>>>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push modes > >>>>>>> > >>>>>>> In the definition of Pull mode, the following sentence > >>>>>>> The Authorizing Entity then installs the QoS > >>>>>>> authorization decision to the Network Element > >>>>>>> initiatively. needs work. "initiatively" is not a word. > >>>>>>> > >>>>>>> [DS] ok. Any good word? Basically I don't like some words such > >>>>>>> as unsolicited since it is used by 3GPP for different meaning. > >>>>>>> Maybe "directly" instead? > >>>>>>> > >>>>>>>>> 2. section 3.1/2: modify the architecture diagram to separate > >>>>>>>>> the Authorizing Entity from AS (further alignment is needed in > >>>>>>>>> the context); and add new subsections to addressing the > >>>>>>>>> endpoint features > >>>>>>> > >>>>>>>>> and push/pull modes. > >>>>>>> > >>>>>>> Breaking up the AS and AE implies that there will be another > >>>>>>> interface > >>>>>> > >>>>>>> yet to be defined. I would rather not open up this possibility. > >>>>>>> The > >>>>> > >>>>>>> Diameter QoS application should be usable all the way from > >>>>>>> network element to application server, perhaps passing through > >>>>>>> an arbitrary number of proxies that enforce their own policies, > >>>>>>> but there should be > >>>>>> > >>>>>>> 1 interface not 2. Also, it is important to note that the AS > >>>>>>> need not > >>>>>> > >>>>>>> be present at all in some > >>>>>>> scenarios: for example, when authorizing requests from a static > >>>>>>> subscriber database. > >>>>>>> > >>>>>>> [DS] First of all, I don't intend to standardize the interface > >>>>>>> between > >>>>>> > >>>>>>> AS and AE in this application. Second, I am not sure why the > >>>>>>> separate > >>>>> > >>>>>>> of AS and AE prevents the AE access to a static subscriber > >>>>>>> database. The basic rationale is address as aforementioned. > >>>>>>> > >>>>>>>>> 3. section 3.3: minor revision on the models for pull; rewrite > >>>>>>>>> the > >>>> > >>>>>>>>> push model (Tina, pls take a look) > >>>>>>> > >>>>>>> 3.2 looks new. It seems to be overly weighted in favor of the > >>>>>>> push model. I would like to point out that there is a big > >>>>>>> discovery problem with the push model, especially when the AE > >>>>>>> and NE are in different administrative domains. The push model > >>>>>>> is only applicable > >>>> > >>>>>>> to the case where the AE and the NE are in the same > >>>>>>> administrative domain and therefore it is a special case. > >>>>>>> > >>>>>>> [DS] I think in reality the operators mainly look at the > >>>>>>> intra-domain > >>>>> > >>>>>>> policy enforcement interface, whatever pull or push models. I am > >>>>>>> not > >>>> > >>>>>>> in favor of any specific models, just analyze the impact of > >>>>>>> endpoint's > >>>>>> > >>>>>>> capability. If you have any words that can enhance the pull > >>>>>>> model, it > >>>>> > >>>>>>> is very welcome :-). > >>>>>>> > >>>>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section > >>>>>>>>> 7.4 and > >>>>>>> > >>>>>>>>> table. But the name still remains in some texts. > >>>>>>>>> > >>>>>>>>> To be done: > >>>>>>>>> 1. state mechanism for Push mode: server initiated policy > >>>>>>>>> installation 2. should section 4.4 be merged with section 4.2 > >>>>>>>>> since > >>>>> > >>>>>>>>> both them discuss how to initiate a new Diameter session? In > >>>>>>>>> addition, the text needs to be beefed up for server initiated > >>>>>>>>> session. > >>>>>>>>> 3. authorization schemes/models for Pull: inter-domain > >>>>>>>>> authorization > >>>>>> > >>>>>>>>> between authorizing entity and NE is not envisaged as the > >>>>>>>>> basic model, should be revised in the context; Token based > >>>>>>>>> approach is not > >>>>>> > >>>>>>>>> the main trend, should be shortened. > >>>>>>> > >>>>>>> We need to have inter-domain authorization as the basic > >>>>>>> scenario; local authorization should be treated as a special > >>>>>>> case. The whole point is to leverage the inter-domain > >>>>>>> capability of Diameter to mediate between network elements and > >>>>>>> authorizing entities, whether the AEs are application servers > >>>>>>> or static subscriber databases. > >>>>>>> > >>>>>>> [DS] I agree that inter-domain authorization/policy > >>>>>>> communication is > >>>> > >>>>>>> important, but the mechanism and scope of this document is > >>>>>>> inappropriate to solve that issue, since it is not the right way > >>>>>>> forward envisioned by the industry and operators. > >>>>>>> > >>>>>>> If we only solve the local case it will mean that an application > >>>>>>> server has to be co-located in the local domain. This is not > >>>>>>> the way > >>>>> > >>>>>>> the Internet is supposed to work: services should be deployable > >>>>>>> end-to-end, without modifying elements of the network along the > >>>>>>> path. It should be possible for the application server to be > >>>>>>> located > >>>> > >>>>>>> anywhere in the network and the AAA part should just work. > >>>>>>> > >>>>>>> [DS] as I said, the AS and AE can be in different domains. On > >>>>>>> the other hand, if we integrate the AS with AE together, it > >>>>>>> impose a tight > >>>>>> > >>>>>>> coupled service model, i.e. AS and AE always have to be in the > >>>>>>> same domain. Exactly the issue you are concerned. > >>>>>>> > >>>>>>>>> 4. The current doc mainly talks about the QoS, should add some > >>>>>>>>> tint > >>>>> > >>>>>>>>> on the policy control side. > >>>>>>>>> > >>>>>>>>> Please let me know your opinion and how to proceed. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Dong > >>>>>>> > >>>>>>> -Pete > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 19 17:57:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lhu-0000fH-A5; Tue, 19 Jun 2007 17:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lht-0000fB-E5 for dime@ietf.org; Tue, 19 Jun 2007 17:57:49 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0lhr-0007jJ-JL for dime@ietf.org; Tue, 19 Jun 2007 17:57:49 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1182290262!30201037!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9512 invoked from network); 19 Jun 2007 21:57:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 19 Jun 2007 21:57:42 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5JLvgcJ022367 for ; Tue, 19 Jun 2007 14:57:42 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l5JLvgP0019541 for ; Tue, 19 Jun 2007 16:57:42 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5JLvfXb019526 for ; Tue, 19 Jun 2007 16:57:41 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] FW: First draft on the integration of QoS application Date: Tue, 19 Jun 2007 17:57:37 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7187FBB@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: First draft on the integration of QoS application thread-index: AcetISvGTMneLoT9RHySt6sElj/kSQADAwBAAAQSw0AAIhfZoAAA/rRwAAA4YPAAALX/UAAEvulgAAHFv2AAAzbrgAAEo/mQACyi5MAA9NG4UAALIyWwAABIoPA= References: <033458F56EC2A64E8D2D7B759FA3E7E7187F9F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7187FBB@sonusmail04.sonusnet.com> From: "McCann Peter-A001034" To: "Asveren, Tolga" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e9eeacd7fe925d5f7faae01ed8f85b97 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Tolga, I think the next-hop for a session will be based on Diameter routing based on the application ID and Destination-Realm AVP, as specified in section 2.7 of the base protocol. As such, we need to provide guidance in how to set these parameters in any request message used by the Diameter QoS application. If this information is required from the underlying network element that receives a QoS request, we should state that. Similarly, if the information comes from an application server,=20 we should at least give some overview of how the AS learns this information in the inter-domain case. -Pete Asveren, Tolga wrote: > Hi Pete, >=20 > I think I agree with you overall just I think we need to be careful > about what we mean with "discovery". It could be that it is better to > leave it implementation dependent/out of scope of Diameter QoS > protocol, how a Diameter node selects the next-hop for the initial > request for a session. =20 >=20 > Thanks, > Tolga >=20 >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Tuesday, June 19, 2007 12:16 PM >> To: Asveren, Tolga; dime@ietf.org >> Subject: RE: [Dime] FW: First draft on the integration of QoS >> application=20 >>=20 >> Hi, Tolga, >>=20 >> I agree that we should have the flexibility for the diameter-qos >> application to be inter-domain. As such, we need to define >> everything needed to make that work for both the push and pull >> modes, including discovery and routing of messages end-to-end. >>=20 >> -Pete >>=20 >>=20 >> Asveren, Tolga wrote: >>> IMHO it makes sense to separate AF and PDF functionalities depending >>> on the network topology/business model. It provides a single point >>> of contact for AF, if the service instance requires QoS >>> reservations in multiple networks/devices etc... >>>=20 >>> OTOH, I have no strong opinion in terms of where the inter-domain >>> boundary is going to be. It could be that both AF/PDF and PDF/PEP >>> interfaces are inter-domain for a specific service instance. >>> Probably this is not something for us to decide but we need to have >>> the flexibility to support all models (if possible). >>>=20 >>> I guess IETF QoS work can address both interfaces. PDF can act as a >>> Diameter proxy, Diameter B2BUA type of entity etc... or may not be >>> in the picture at all depending on the business model. What problem >>> do we see with this approach?=20 >>>=20 >>> Thanks, >>> Tolga >>>=20 >>>> -----Original Message----- >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>> Sent: Wednesday, June 13, 2007 6:08 PM >>>> To: dime@ietf.org >>>> Subject: [Dime] FW: First draft on the integration of QoS >>>> application=20 >>>>=20 >>>> Below is a discussion thread that has been taking place among >>>> authors of the diameter-qos draft. We thought it important that >>>> the mailing list have some visibility to the discussion. Comments >>>> welcome.=20 >>>>=20 >>>> -Pete >>>>=20 >>>> McCann Peter-A001034 wrote: >>>>> Hi, Dong, >>>>>=20 >>>>> I guess I don't see why we need two separate interfaces. They are >>>>> each transporting roughly the same information and doing the same >>>>> sort of job.=20 >>>>>=20 >>>>> The current document in my mind has always been an inter-domain >>>>> interface. See the abstract:=20 >>>>>=20 >>>>> ...Clients that implement the Diameter QoS application contact an >>>>> authorizing entity/application server that is located somewhere >>>>> in the network, allowing for a wide variety of flexible >>>>> deployment models.=20 >>>>>=20 >>>>> And the following text in Section 3.2: >>>>>=20 >>>>> Inter-domain support >>>>>=20 >>>>> In particular, users may roam outside their home network, >>>>> leading to a situation where the network element and >>>>> authorizing entity are in different administrative domains. >>>>>=20 >>>>> -Pete >>>>>=20 >>>>> Sun, Dong (Dong) wrote: >>>>>> Hi Pete, >>>>>> I have no doubt about the importance of inter-domain policy >>>>>> communications, and it might be better to use the Diameter broker >>>>>> instead of SIP proxy to deal with inter-domain resource >>>>>> management. In fact, I think 3GPP does use the similar model as >>>>>> you described, that a Diameter broker (client) is embedded in >>>>>> the AF (e.g. P-CSCF), and the interface between AF and >>>>>> underlying Policy engine (e.g. PCRF) is an inter-domain >>>>>> interface per se. certainly, since they (SIP and Diameter >>>>>> brokers) are grouped together, it is less flexible and scalable >>>>>> for the implementation.=20 >>>>>>=20 >>>>>> However, I think this interface (named as Rx in 3GPP, Gq' in >>>>>> TISPAN, Rs in ITU) is not for the control of policy enforcement >>>>>> directly. In my view, this interface (Rx) is a peering interface >>>>>> between policy servers rather than between policy server and >>>>>> enforcement point as described in the current QoS application, >>>>>> and I believe it is more appropriate to model the inter-domain >>>>>> interface as the policy server to policy server (PDF-PDF) >>>>>> peering interface.=20 >>>>>>=20 >>>>>> I have no problem to develop a doc to address this inter-domain >>>>>> application, however, if you look around the current document, I >>>>>> did not see any indication from that perspective. >>>>>>=20 >>>>>> Dong >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>> Sent: Wednesday, June 13, 2007 2:11 PM >>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on >>>>>> the integration of QoS application >>>>>>=20 >>>>>> Hi, Dong, >>>>>>=20 >>>>>> Sun, Dong (Dong) wrote: >>>>>>> Hi Pete, >>>>>>>=20 >>>>>>> Thanks for clarification. Just wondering if you can give an >>>>>>> example who will use the "inter-domain" model for policy >>>>>>> enforcement control, i.e. PDP and PEP reside in the different >>>>>>> operator's administrative domains. Since the inter-domain is to >>>>>>> serve for the operator's domain, I don't know how to create an >>>>>>> application without considering their need. (BTW, I have no >>>>>>> strong view to limit it to intra-domain only if the use case can >>>>>>> be identified). >>>>>>=20 >>>>>> Arbitrary third parties should be allowed to deploy application >>>>>> servers and interface to the Diameter cloud to get QoS from the >>>>>> network. The Diameter QoS Application should play this role. >>>>>> In the extreme case, I should be allowed to put a SIP server in >>>>>> my basement, sign up with a Diameter broker, and run my >>>>>> application end-to-end.=20 >>>>>>=20 >>>>>>> I agree that this application should support "a generic mediator >>>>>>> that can handle many applications". However, Given the >>>>>>> integrated AS and AE, it makes the AE has to be collocated with >>>>>>> the application content providers rather than the network >>>>>>> itself, I feel it is also too limited and not the common case >>>>>>> in reality. (As far as I know, all deployed or emerging network >>>>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view >>>>>>> this solution as the main trend). I am wondering who will use >>>>>>> this application eventually. >>>>>>=20 >>>>>> I am not ruling out a PDP in the network local to the PEP. I am >>>>>> just saying that this PDP should be viewed as a Diameter proxy on >>>>>> the path to the Authorizing Entity, which itself may be either a >>>>>> static subscriber database or an active application server. >>>>>> I don't want to work only on the localized protocol, I want to >>>>>> define the inter-domain one. If you insist on separating the AE >>>>>> from the AS then I would say that the important Diameter >>>>>> interface is the one between AE and AS. It is much more >>>>>> important to standardize the inter-domain interface because this >>>>>> is the one that will be used between operators. >>>>>>=20 >>>>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they >>>>>> are going down the path of using SIP proxies as the inter-domain >>>>>> interface. I think this architecture is bad for the Internet, >>>>>> and will limit the kinds of applications that can be deployed. >>>>>> The Internet model is that applications should be deployable >>>>>> without modifying the middleboxes. Tying SIP servers to the >>>>>> network traffic path also doesn't work well with Mobile IP. >>>>>>=20 >>>>>>> In addition, the scalable roaming agreements sound like a >>>>>>> general algorithm that may be applicable for any inter-domain >>>>>>> issue in the context of Diameter applications, or it is only >>>>>>> the fundament to this application? >>>>>>=20 >>>>>> The Diameter NASREQ application (similar to the basic RADIUS >>>>>> protocol) has always been about inter-domain operation. Diameter >>>>>> is used as the mediating protocol between different operator >>>>>> domains. I think we should be following the same model with the >>>>>> Diameter QoS application.=20 >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>>> Dong >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>>> Sent: Wednesday, June 13, 2007 11:06 AM >>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on >>>>>>> the integration of QoS application >>>>>>>=20 >>>>>>> Hi, Dong, >>>>>>>=20 >>>>>>> An "Autonomous System" has a very specific meaning in the >>>>>>> context of routing protocols; I would not want to say that they >>>>>>> correspond one-to-one with the "domains" that exist when I talk >>>>>>> about "inter-domain" in the context of diameter-qos. I would >>>>>>> say that "operator's administrative domain" is a better term. >>>>>>>=20 >>>>>>> In any case, I think that the Diameter cloud from the figure 1 >>>>>>> should be a generic inter-domain mediator that can handle many >>>>>>> applications, of which Diameter QoS is one. The scalable >>>>>>> roaming agreements embodied in this cloud should allow the >>>>>>> Authorizing Entity to be anywhere in the network. There may be >>>>>>> proxies in the Diameter cloud that enforce their own policy >>>>>>> decisions, some of which will be local to the Network Element's >>>>>>> administrative domain. However, that should not impact the >>>>>>> specification of the Diameter QoS Application. This >>>>>>> inter-domain operation has been at the core of the document >>>>>>> since I started it: see Section 3.2 in the -00 version.=20 >>>>>>>=20 >>>>>>> -Pete >>>>>>>=20 >>>>>>> Sun, Dong (Dong) wrote: >>>>>>>> Hi Pete, >>>>>>>>=20 >>>>>>>> Before making any conclusion, I'd like to clarify some terms: >>>>>>>> Since you mentioned this is IETF, Internet and such, the domain >>>>>>>> you refer to is in the context of the "Autonomous System" or >>>>>>>> "operator's administrative domain". >>>>>>>>=20 >>>>>>>> Dong >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>>>> Sent: Wednesday, June 13, 2007 10:27 AM >>>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina >>>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on >>>>>>>> the integration of QoS application >>>>>>>>=20 >>>>>>>> Hi, Dong, >>>>>>>>=20 >>>>>>>> I think you and I have a fundamental disagreement on the scope >>>>>>>> and purpose of this document. I really don't see the need to >>>>>>>> standardize >>>>>>=20 >>>>>>>> an intra-domain localized solution to the problem. This is >>>>>>>> IETF we should be solving the problem for the whole Internet, >>>>>>>> which means inter-domain is the target. I understand that some >>>>>>>> operators might not want to open their networks, but we should >>>>>>>> not be defining standards for these closed architectures. >>>>>>>>=20 >>>>>>>> I also feel strongly that we should have adequate discovery >>>>>>>> mechanisms >>>>>>>=20 >>>>>>>> for all modes of operation specified in this document; >>>>>>>> otherwise it could lead to inter-operability problems. >>>>>>>>=20 >>>>>>>> Hannes, I would like to note this as a serious issue that >>>>>>>> should be resolved before we proceed any further. I would >>>>>>>> like to check with the mailing list and the ADs on their >>>>>>>> preferences. What do you think >>>>>>=20 >>>>>>>> would be the appropriate way to introduce the issue? Would you >>>>>>>> like to introduce the question to the mailing list? >>>>>>>>=20 >>>>>>>> -Pete >>>>>>>>=20 >>>>>>>> Sun, Dong (Dong) wrote: >>>>>>>>> Hi Pete, >>>>>>>>>=20 >>>>>>>>> First of all, Thanks for the review and comments. >>>>>>>>>=20 >>>>>>>>> 1. Concerning the split of Application Server and Authorizing >>>>>>>>> Entity, >>>>>>>=20 >>>>>>>>> which is somewhat related to another main comment you brought >>>>>>>>> up i.e. the relationship between Authorizing Entity and NE - >>>>>>>>> inter-domain Vs. intra-domain, the rationale in my mind is as >>>>>>>>> follow: - In the real network (or the vision of NGN, or >>>>>>>>> somewhat the >>>>>>=20 >>>>>>>>> net neutrality perspective), the packet (transport) network >>>>>>>>> should support >>>>>>>>=20 >>>>>>>>> a variety of applications which may belong to different SPs >>>>>>>>> i.e. in different domain. The PDP (i.e. Authorizing entity in >>>>>>>>> the context of >>>>>>=20 >>>>>>>>> QoS application) can act as the arbitrator to isolate the >>>>>>>>> diversity of application attributes from the speciality of >>>>>>>>> network functionality. The authorizing entity is typically >>>>>>>>> part of transport >>>>>>=20 >>>>>>>>> network domain along with the NEs since the network operators >>>>>>>>> are commonly willing to >>>>>>>>=20 >>>>>>>>> neither rely on the third party to control the use of their >>>>>>>>> network resources nor disclose the network details (e.g. >>>>>>>>> topology, resource usage and policies) to other carriers/SPs. >>>>>>>>> Therefore, the common case is that the interface between >>>>>>>>> Authorizing entity and NE (enforcement point) should be >>>>>>>>> intra-domain in nature.=20 >>>>>>>>>=20 >>>>>>>>> - On the other hand, the interface between AS and AE can be >>>>>>>>> inter-domain, which also makes the life easier concerning the >>>>>>>>> inter-domain enforcement interface. >>>>>>>>>=20 >>>>>>>>> - The policy communications between different domains is quite >>>>>>>>> important, for example, for the roaming scenario. However, it >>>>>>>>> is outside the scope of this application if my understanding >>>>>>>>> is correct. I feel it is better to be solved through >>>>>>>>> inter-Authorizing Entity interface rather than this interface. >>>>>>>>> Certainly, the command and AVPs >>>>>>>=20 >>>>>>>>> might be shared, but I would rather not mix them together for >>>>>>>>> the time being.=20 >>>>>>>>>=20 >>>>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree >>>>>>>>> that it >>>>>>=20 >>>>>>>>> is a tricky issue and also support to describe the issue in >>>>>>>>> the document. However, I'd like to point out, this document >>>>>>>>> should concentrate on the protocol related issue and allow the >>>>>>>>> flexibility to use the other discovery mechanism beyond the >>>>>>>>> Diameter protocol capability. In other words, we mainly need >>>>>>>>> to define some mechanism based on Diameter protocol's >>>>>>>>> capability, such as the realm based routing, and leave the >>>>>>>>> door open for other advanced discovery schemes. >>>>>>>>>=20 >>>>>>>>> See additional comment in line... >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Dong >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>>>>> Sent: Tuesday, June 12, 2007 5:26 PM >>>>>>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina >>>>>>>>> TSOU; >>>>>>=20 >>>>>>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the >>>>>>>>> integration of QoS application >>>>>>>>>=20 >>>>>>>>> Hi, all, >>>>>>>>>=20 >>>>>>>>> Please see my comments in line. >>>>>>>>>=20 >>>>>>>>> Hannes Tschofenig wrote: >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> could you please take a look at the proposal by Dong? >>>>>>>>>>=20 >>>>>>>>>> They are available here: >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>=20 >> http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft >>>>>> -i >>>>>>>>> etf-dime-diameter-qos-01-ds.txt >>>>>>>>>>=20 >>>>>>>>>> The XML file is in the same directory, as usual. >>>>>>>>>>=20 >>>>>>>>>> Ciao >>>>>>>>>> Hannes >>>>>>>>>>=20 >>>>>>>>>> Sun, Dong (Dong) wrote: >>>>>>>>>>> Hi Hannes et al, >>>>>>>>>>>=20 >>>>>>>>>>> Attached is the first cut to integrate two I-Ds. The change >>>>>>>>>>> is a minimum set based on the comments from the exploder >>>>>>>>>>> (Tina, Christian >>>>>>>>=20 >>>>>>>>>>> and Tolga). There are some open issues to be done, I'd like >>>>>>>>>>> to get >>>>>>=20 >>>>>>>>>>> your comments on changes first and discuss how to proceed on >>>>>>>>>>> those >>>>>>=20 >>>>>>>>>>> open items before making any further editings. Main changes: >>>>>>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push >>>>>>>>>>> modes=20 >>>>>>>>>=20 >>>>>>>>> In the definition of Pull mode, the following sentence >>>>>>>>> The Authorizing Entity then installs the QoS >>>>>>>>> authorization decision to the Network Element >>>>>>>>> initiatively. needs work. "initiatively" is not a word. >>>>>>>>>=20 >>>>>>>>> [DS] ok. Any good word? Basically I don't like some words such >>>>>>>>> as unsolicited since it is used by 3GPP for different >>>>>>>>> meaning. Maybe "directly" instead?=20 >>>>>>>>>=20 >>>>>>>>>>> 2. section 3.1/2: modify the architecture diagram to >>>>>>>>>>> separate the Authorizing Entity from AS (further alignment >>>>>>>>>>> is needed in the context); and add new subsections to >>>>>>>>>>> addressing the endpoint features >>>>>>>>>=20 >>>>>>>>>>> and push/pull modes. >>>>>>>>>=20 >>>>>>>>> Breaking up the AS and AE implies that there will be another >>>>>>>>> interface >>>>>>>>=20 >>>>>>>>> yet to be defined. I would rather not open up this >>>>>>>>> possibility. The >>>>>>>=20 >>>>>>>>> Diameter QoS application should be usable all the way from >>>>>>>>> network element to application server, perhaps passing through >>>>>>>>> an arbitrary number of proxies that enforce their own >>>>>>>>> policies, but there should be >>>>>>>>=20 >>>>>>>>> 1 interface not 2. Also, it is important to note that the AS >>>>>>>>> need not >>>>>>>>=20 >>>>>>>>> be present at all in some >>>>>>>>> scenarios: for example, when authorizing requests from a >>>>>>>>> static subscriber database.=20 >>>>>>>>>=20 >>>>>>>>> [DS] First of all, I don't intend to standardize the interface >>>>>>>>> between >>>>>>>>=20 >>>>>>>>> AS and AE in this application. Second, I am not sure why the >>>>>>>>> separate >>>>>>>=20 >>>>>>>>> of AS and AE prevents the AE access to a static subscriber >>>>>>>>> database. The basic rationale is address as aforementioned. >>>>>>>>>=20 >>>>>>>>>>> 3. section 3.3: minor revision on the models for pull; >>>>>>>>>>> rewrite the >>>>>>=20 >>>>>>>>>>> push model (Tina, pls take a look) >>>>>>>>>=20 >>>>>>>>> 3.2 looks new. It seems to be overly weighted in favor of the >>>>>>>>> push model. I would like to point out that there is a big >>>>>>>>> discovery problem with the push model, especially when the AE >>>>>>>>> and NE are in different administrative domains. The push >>>>>>>>> model is only applicable >>>>>>=20 >>>>>>>>> to the case where the AE and the NE are in the same >>>>>>>>> administrative domain and therefore it is a special case. >>>>>>>>>=20 >>>>>>>>> [DS] I think in reality the operators mainly look at the >>>>>>>>> intra-domain >>>>>>>=20 >>>>>>>>> policy enforcement interface, whatever pull or push models. I >>>>>>>>> am not >>>>>>=20 >>>>>>>>> in favor of any specific models, just analyze the impact of >>>>>>>>> endpoint's >>>>>>>>=20 >>>>>>>>> capability. If you have any words that can enhance the pull >>>>>>>>> model, it >>>>>>>=20 >>>>>>>>> is very welcome :-). >>>>>>>>>=20 >>>>>>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from >>>>>>>>>>> section=20 >>>>>>>>>>> 7.4 and >>>>>>>>>=20 >>>>>>>>>>> table. But the name still remains in some texts. >>>>>>>>>>>=20 >>>>>>>>>>> To be done: >>>>>>>>>>> 1. state mechanism for Push mode: server initiated policy >>>>>>>>>>> installation 2. should section 4.4 be merged with section >>>>>>>>>>> 4.2 since >>>>>>>=20 >>>>>>>>>>> both them discuss how to initiate a new Diameter session? In >>>>>>>>>>> addition, the text needs to be beefed up for server >>>>>>>>>>> initiated session.=20 >>>>>>>>>>> 3. authorization schemes/models for Pull: inter-domain >>>>>>>>>>> authorization >>>>>>>>=20 >>>>>>>>>>> between authorizing entity and NE is not envisaged as the >>>>>>>>>>> basic model, should be revised in the context; Token based >>>>>>>>>>> approach is not >>>>>>>>=20 >>>>>>>>>>> the main trend, should be shortened. >>>>>>>>>=20 >>>>>>>>> We need to have inter-domain authorization as the basic >>>>>>>>> scenario; local authorization should be treated as a special >>>>>>>>> case. The whole point is to leverage the inter-domain >>>>>>>>> capability of Diameter to mediate between network elements and >>>>>>>>> authorizing entities, whether the AEs are application servers >>>>>>>>> or static subscriber databases. >>>>>>>>>=20 >>>>>>>>> [DS] I agree that inter-domain authorization/policy >>>>>>>>> communication is >>>>>>=20 >>>>>>>>> important, but the mechanism and scope of this document is >>>>>>>>> inappropriate to solve that issue, since it is not the right >>>>>>>>> way forward envisioned by the industry and operators. >>>>>>>>>=20 >>>>>>>>> If we only solve the local case it will mean that an >>>>>>>>> application server has to be co-located in the local domain.=20 >>>>>>>>> This is not the way >>>>>>>=20 >>>>>>>>> the Internet is supposed to work: services should be >>>>>>>>> deployable end-to-end, without modifying elements of the >>>>>>>>> network along the path. It should be possible for the >>>>>>>>> application server to be located >>>>>>=20 >>>>>>>>> anywhere in the network and the AAA part should just work. >>>>>>>>>=20 >>>>>>>>> [DS] as I said, the AS and AE can be in different domains. On >>>>>>>>> the other hand, if we integrate the AS with AE together, it >>>>>>>>> impose a tight >>>>>>>>=20 >>>>>>>>> coupled service model, i.e. AS and AE always have to be in the >>>>>>>>> same domain. Exactly the issue you are concerned. >>>>>>>>>=20 >>>>>>>>>>> 4. The current doc mainly talks about the QoS, should add >>>>>>>>>>> some tint >>>>>>>=20 >>>>>>>>>>> on the policy control side. >>>>>>>>>>>=20 >>>>>>>>>>> Please let me know your opinion and how to proceed. >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Dong >>>>>>>>>=20 >>>>>>>>> -Pete >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 19 18:09:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ltR-0004ag-9m; Tue, 19 Jun 2007 18:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ltQ-0004ab-6r for dime@ietf.org; Tue, 19 Jun 2007 18:09:44 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ltP-0002fi-B7 for dime@ietf.org; Tue, 19 Jun 2007 18:09:44 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l5JM9gTH021230; Tue, 19 Jun 2007 18:09:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] FW: First draft on the integration of QoS application Date: Tue, 19 Jun 2007 18:09:42 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7187FBC@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: First draft on the integration of QoS application Thread-Index: AcetISvGTMneLoT9RHySt6sElj/kSQADAwBAAAQSw0AAIhfZoAAA/rRwAAA4YPAAALX/UAAEvulgAAHFv2AAAzbrgAAEo/mQACyi5MAA9NG4UAALIyWwAABIoPAAAL63UA== References: <033458F56EC2A64E8D2D7B759FA3E7E7187F9F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7187FBB@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f5e3f76ec5b90a46b9b8bc53da20ed8e Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Pete, I fully agree with the approach of providing information inline with existing Diameter base protocol mechanisms. My worry was about defining detailed procedures more on application level, e.g. how QoS AVPs need to be processed/analyzed for routing decision. It may be an idea to touch this topic briefly without normative text but I guess other than that, this is really implementation dependent. Thanks, Tolga > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, June 19, 2007 5:58 PM > To: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] FW: First draft on the integration of QoS application >=20 > Hi, Tolga, >=20 > I think the next-hop for a session will be based on Diameter > routing based on the application ID and Destination-Realm AVP, > as specified in section 2.7 of the base protocol. As such, > we need to provide guidance in how to set these parameters > in any request message used by the Diameter QoS application. > If this information is required from the underlying network > element that receives a QoS request, we should state that. > Similarly, if the information comes from an application server, > we should at least give some overview of how the AS learns > this information in the inter-domain case. >=20 > -Pete >=20 > Asveren, Tolga wrote: > > Hi Pete, > > > > I think I agree with you overall just I think we need to be careful > > about what we mean with "discovery". It could be that it is better to > > leave it implementation dependent/out of scope of Diameter QoS > > protocol, how a Diameter node selects the next-hop for the initial > > request for a session. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >> Sent: Tuesday, June 19, 2007 12:16 PM > >> To: Asveren, Tolga; dime@ietf.org > >> Subject: RE: [Dime] FW: First draft on the integration of QoS > >> application > >> > >> Hi, Tolga, > >> > >> I agree that we should have the flexibility for the diameter-qos > >> application to be inter-domain. As such, we need to define > >> everything needed to make that work for both the push and pull > >> modes, including discovery and routing of messages end-to-end. > >> > >> -Pete > >> > >> > >> Asveren, Tolga wrote: > >>> IMHO it makes sense to separate AF and PDF functionalities depending > >>> on the network topology/business model. It provides a single point > >>> of contact for AF, if the service instance requires QoS > >>> reservations in multiple networks/devices etc... > >>> > >>> OTOH, I have no strong opinion in terms of where the inter-domain > >>> boundary is going to be. It could be that both AF/PDF and PDF/PEP > >>> interfaces are inter-domain for a specific service instance. > >>> Probably this is not something for us to decide but we need to have > >>> the flexibility to support all models (if possible). > >>> > >>> I guess IETF QoS work can address both interfaces. PDF can act as a > >>> Diameter proxy, Diameter B2BUA type of entity etc... or may not be > >>> in the picture at all depending on the business model. What problem > >>> do we see with this approach? > >>> > >>> Thanks, > >>> Tolga > >>> > >>>> -----Original Message----- > >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>> Sent: Wednesday, June 13, 2007 6:08 PM > >>>> To: dime@ietf.org > >>>> Subject: [Dime] FW: First draft on the integration of QoS > >>>> application > >>>> > >>>> Below is a discussion thread that has been taking place among > >>>> authors of the diameter-qos draft. We thought it important that > >>>> the mailing list have some visibility to the discussion. Comments > >>>> welcome. > >>>> > >>>> -Pete > >>>> > >>>> McCann Peter-A001034 wrote: > >>>>> Hi, Dong, > >>>>> > >>>>> I guess I don't see why we need two separate interfaces. They are > >>>>> each transporting roughly the same information and doing the same > >>>>> sort of job. > >>>>> > >>>>> The current document in my mind has always been an inter-domain > >>>>> interface. See the abstract: > >>>>> > >>>>> ...Clients that implement the Diameter QoS application contact an > >>>>> authorizing entity/application server that is located somewhere > >>>>> in the network, allowing for a wide variety of flexible > >>>>> deployment models. > >>>>> > >>>>> And the following text in Section 3.2: > >>>>> > >>>>> Inter-domain support > >>>>> > >>>>> In particular, users may roam outside their home network, > >>>>> leading to a situation where the network element and > >>>>> authorizing entity are in different administrative domains. > >>>>> > >>>>> -Pete > >>>>> > >>>>> Sun, Dong (Dong) wrote: > >>>>>> Hi Pete, > >>>>>> I have no doubt about the importance of inter-domain policy > >>>>>> communications, and it might be better to use the Diameter broker > >>>>>> instead of SIP proxy to deal with inter-domain resource > >>>>>> management. In fact, I think 3GPP does use the similar model as > >>>>>> you described, that a Diameter broker (client) is embedded in > >>>>>> the AF (e.g. P-CSCF), and the interface between AF and > >>>>>> underlying Policy engine (e.g. PCRF) is an inter-domain > >>>>>> interface per se. certainly, since they (SIP and Diameter > >>>>>> brokers) are grouped together, it is less flexible and scalable > >>>>>> for the implementation. > >>>>>> > >>>>>> However, I think this interface (named as Rx in 3GPP, Gq' in > >>>>>> TISPAN, Rs in ITU) is not for the control of policy enforcement > >>>>>> directly. In my view, this interface (Rx) is a peering interface > >>>>>> between policy servers rather than between policy server and > >>>>>> enforcement point as described in the current QoS application, > >>>>>> and I believe it is more appropriate to model the inter-domain > >>>>>> interface as the policy server to policy server (PDF-PDF) > >>>>>> peering interface. > >>>>>> > >>>>>> I have no problem to develop a doc to address this inter-domain > >>>>>> application, however, if you look around the current document, I > >>>>>> did not see any indication from that perspective. > >>>>>> > >>>>>> Dong > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>> Sent: Wednesday, June 13, 2007 2:11 PM > >>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>> the integration of QoS application > >>>>>> > >>>>>> Hi, Dong, > >>>>>> > >>>>>> Sun, Dong (Dong) wrote: > >>>>>>> Hi Pete, > >>>>>>> > >>>>>>> Thanks for clarification. Just wondering if you can give an > >>>>>>> example who will use the "inter-domain" model for policy > >>>>>>> enforcement control, i.e. PDP and PEP reside in the different > >>>>>>> operator's administrative domains. Since the inter-domain is to > >>>>>>> serve for the operator's domain, I don't know how to create an > >>>>>>> application without considering their need. (BTW, I have no > >>>>>>> strong view to limit it to intra-domain only if the use case can > >>>>>>> be identified). > >>>>>> > >>>>>> Arbitrary third parties should be allowed to deploy application > >>>>>> servers and interface to the Diameter cloud to get QoS from the > >>>>>> network. The Diameter QoS Application should play this role. > >>>>>> In the extreme case, I should be allowed to put a SIP server in > >>>>>> my basement, sign up with a Diameter broker, and run my > >>>>>> application end-to-end. > >>>>>> > >>>>>>> I agree that this application should support "a generic mediator > >>>>>>> that can handle many applications". However, Given the > >>>>>>> integrated AS and AE, it makes the AE has to be collocated with > >>>>>>> the application content providers rather than the network > >>>>>>> itself, I feel it is also too limited and not the common case > >>>>>>> in reality. (As far as I know, all deployed or emerging network > >>>>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view > >>>>>>> this solution as the main trend). I am wondering who will use > >>>>>>> this application eventually. > >>>>>> > >>>>>> I am not ruling out a PDP in the network local to the PEP. I am > >>>>>> just saying that this PDP should be viewed as a Diameter proxy on > >>>>>> the path to the Authorizing Entity, which itself may be either a > >>>>>> static subscriber database or an active application server. > >>>>>> I don't want to work only on the localized protocol, I want to > >>>>>> define the inter-domain one. If you insist on separating the AE > >>>>>> from the AS then I would say that the important Diameter > >>>>>> interface is the one between AE and AS. It is much more > >>>>>> important to standardize the inter-domain interface because this > >>>>>> is the one that will be used between operators. > >>>>>> > >>>>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they > >>>>>> are going down the path of using SIP proxies as the inter-domain > >>>>>> interface. I think this architecture is bad for the Internet, > >>>>>> and will limit the kinds of applications that can be deployed. > >>>>>> The Internet model is that applications should be deployable > >>>>>> without modifying the middleboxes. Tying SIP servers to the > >>>>>> network traffic path also doesn't work well with Mobile IP. > >>>>>> > >>>>>>> In addition, the scalable roaming agreements sound like a > >>>>>>> general algorithm that may be applicable for any inter-domain > >>>>>>> issue in the context of Diameter applications, or it is only > >>>>>>> the fundament to this application? > >>>>>> > >>>>>> The Diameter NASREQ application (similar to the basic RADIUS > >>>>>> protocol) has always been about inter-domain operation. Diameter > >>>>>> is used as the mediating protocol between different operator > >>>>>> domains. I think we should be following the same model with the > >>>>>> Diameter QoS application. > >>>>>> > >>>>>> -Pete > >>>>>> > >>>>>>> Dong > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>> Sent: Wednesday, June 13, 2007 11:06 AM > >>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>>> the integration of QoS application > >>>>>>> > >>>>>>> Hi, Dong, > >>>>>>> > >>>>>>> An "Autonomous System" has a very specific meaning in the > >>>>>>> context of routing protocols; I would not want to say that they > >>>>>>> correspond one-to-one with the "domains" that exist when I talk > >>>>>>> about "inter-domain" in the context of diameter-qos. I would > >>>>>>> say that "operator's administrative domain" is a better term. > >>>>>>> > >>>>>>> In any case, I think that the Diameter cloud from the figure 1 > >>>>>>> should be a generic inter-domain mediator that can handle many > >>>>>>> applications, of which Diameter QoS is one. The scalable > >>>>>>> roaming agreements embodied in this cloud should allow the > >>>>>>> Authorizing Entity to be anywhere in the network. There may be > >>>>>>> proxies in the Diameter cloud that enforce their own policy > >>>>>>> decisions, some of which will be local to the Network Element's > >>>>>>> administrative domain. However, that should not impact the > >>>>>>> specification of the Diameter QoS Application. This > >>>>>>> inter-domain operation has been at the core of the document > >>>>>>> since I started it: see Section 3.2 in the -00 version. > >>>>>>> > >>>>>>> -Pete > >>>>>>> > >>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>> Hi Pete, > >>>>>>>> > >>>>>>>> Before making any conclusion, I'd like to clarify some terms: > >>>>>>>> Since you mentioned this is IETF, Internet and such, the domain > >>>>>>>> you refer to is in the context of the "Autonomous System" or > >>>>>>>> "operator's administrative domain". > >>>>>>>> > >>>>>>>> Dong > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>>> Sent: Wednesday, June 13, 2007 10:27 AM > >>>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>>>> the integration of QoS application > >>>>>>>> > >>>>>>>> Hi, Dong, > >>>>>>>> > >>>>>>>> I think you and I have a fundamental disagreement on the scope > >>>>>>>> and purpose of this document. I really don't see the need to > >>>>>>>> standardize > >>>>>> > >>>>>>>> an intra-domain localized solution to the problem. This is > >>>>>>>> IETF we should be solving the problem for the whole Internet, > >>>>>>>> which means inter-domain is the target. I understand that some > >>>>>>>> operators might not want to open their networks, but we should > >>>>>>>> not be defining standards for these closed architectures. > >>>>>>>> > >>>>>>>> I also feel strongly that we should have adequate discovery > >>>>>>>> mechanisms > >>>>>>> > >>>>>>>> for all modes of operation specified in this document; > >>>>>>>> otherwise it could lead to inter-operability problems. > >>>>>>>> > >>>>>>>> Hannes, I would like to note this as a serious issue that > >>>>>>>> should be resolved before we proceed any further. I would > >>>>>>>> like to check with the mailing list and the ADs on their > >>>>>>>> preferences. What do you think > >>>>>> > >>>>>>>> would be the appropriate way to introduce the issue? Would you > >>>>>>>> like to introduce the question to the mailing list? > >>>>>>>> > >>>>>>>> -Pete > >>>>>>>> > >>>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>>> Hi Pete, > >>>>>>>>> > >>>>>>>>> First of all, Thanks for the review and comments. > >>>>>>>>> > >>>>>>>>> 1. Concerning the split of Application Server and Authorizing > >>>>>>>>> Entity, > >>>>>>> > >>>>>>>>> which is somewhat related to another main comment you brought > >>>>>>>>> up i.e. the relationship between Authorizing Entity and NE - > >>>>>>>>> inter-domain Vs. intra-domain, the rationale in my mind is as > >>>>>>>>> follow: - In the real network (or the vision of NGN, or > >>>>>>>>> somewhat the > >>>>>> > >>>>>>>>> net neutrality perspective), the packet (transport) network > >>>>>>>>> should support > >>>>>>>> > >>>>>>>>> a variety of applications which may belong to different SPs > >>>>>>>>> i.e. in different domain. The PDP (i.e. Authorizing entity in > >>>>>>>>> the context of > >>>>>> > >>>>>>>>> QoS application) can act as the arbitrator to isolate the > >>>>>>>>> diversity of application attributes from the speciality of > >>>>>>>>> network functionality. The authorizing entity is typically > >>>>>>>>> part of transport > >>>>>> > >>>>>>>>> network domain along with the NEs since the network operators > >>>>>>>>> are commonly willing to > >>>>>>>> > >>>>>>>>> neither rely on the third party to control the use of their > >>>>>>>>> network resources nor disclose the network details (e.g. > >>>>>>>>> topology, resource usage and policies) to other carriers/SPs. > >>>>>>>>> Therefore, the common case is that the interface between > >>>>>>>>> Authorizing entity and NE (enforcement point) should be > >>>>>>>>> intra-domain in nature. > >>>>>>>>> > >>>>>>>>> - On the other hand, the interface between AS and AE can be > >>>>>>>>> inter-domain, which also makes the life easier concerning the > >>>>>>>>> inter-domain enforcement interface. > >>>>>>>>> > >>>>>>>>> - The policy communications between different domains is quite > >>>>>>>>> important, for example, for the roaming scenario. However, it > >>>>>>>>> is outside the scope of this application if my understanding > >>>>>>>>> is correct. I feel it is better to be solved through > >>>>>>>>> inter-Authorizing Entity interface rather than this interface. > >>>>>>>>> Certainly, the command and AVPs > >>>>>>> > >>>>>>>>> might be shared, but I would rather not mix them together for > >>>>>>>>> the time being. > >>>>>>>>> > >>>>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree > >>>>>>>>> that it > >>>>>> > >>>>>>>>> is a tricky issue and also support to describe the issue in > >>>>>>>>> the document. However, I'd like to point out, this document > >>>>>>>>> should concentrate on the protocol related issue and allow the > >>>>>>>>> flexibility to use the other discovery mechanism beyond the > >>>>>>>>> Diameter protocol capability. In other words, we mainly need > >>>>>>>>> to define some mechanism based on Diameter protocol's > >>>>>>>>> capability, such as the realm based routing, and leave the > >>>>>>>>> door open for other advanced discovery schemes. > >>>>>>>>> > >>>>>>>>> See additional comment in line... > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Dong > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>>>> Sent: Tuesday, June 12, 2007 5:26 PM > >>>>>>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina > >>>>>>>>> TSOU; > >>>>>> > >>>>>>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > >>>>>>>>> integration of QoS application > >>>>>>>>> > >>>>>>>>> Hi, all, > >>>>>>>>> > >>>>>>>>> Please see my comments in line. > >>>>>>>>> > >>>>>>>>> Hannes Tschofenig wrote: > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> could you please take a look at the proposal by Dong? > >>>>>>>>>> > >>>>>>>>>> They are available here: > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft > >>>>>> -i > >>>>>>>>> etf-dime-diameter-qos-01-ds.txt > >>>>>>>>>> > >>>>>>>>>> The XML file is in the same directory, as usual. > >>>>>>>>>> > >>>>>>>>>> Ciao > >>>>>>>>>> Hannes > >>>>>>>>>> > >>>>>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>>>>> Hi Hannes et al, > >>>>>>>>>>> > >>>>>>>>>>> Attached is the first cut to integrate two I-Ds. The change > >>>>>>>>>>> is a minimum set based on the comments from the exploder > >>>>>>>>>>> (Tina, Christian > >>>>>>>> > >>>>>>>>>>> and Tolga). There are some open issues to be done, I'd like > >>>>>>>>>>> to get > >>>>>> > >>>>>>>>>>> your comments on changes first and discuss how to proceed on > >>>>>>>>>>> those > >>>>>> > >>>>>>>>>>> open items before making any further editings. Main changes: > >>>>>>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push > >>>>>>>>>>> modes > >>>>>>>>> > >>>>>>>>> In the definition of Pull mode, the following sentence > >>>>>>>>> The Authorizing Entity then installs the QoS > >>>>>>>>> authorization decision to the Network Element > >>>>>>>>> initiatively. needs work. "initiatively" is not a word. > >>>>>>>>> > >>>>>>>>> [DS] ok. Any good word? Basically I don't like some words such > >>>>>>>>> as unsolicited since it is used by 3GPP for different > >>>>>>>>> meaning. Maybe "directly" instead? > >>>>>>>>> > >>>>>>>>>>> 2. section 3.1/2: modify the architecture diagram to > >>>>>>>>>>> separate the Authorizing Entity from AS (further alignment > >>>>>>>>>>> is needed in the context); and add new subsections to > >>>>>>>>>>> addressing the endpoint features > >>>>>>>>> > >>>>>>>>>>> and push/pull modes. > >>>>>>>>> > >>>>>>>>> Breaking up the AS and AE implies that there will be another > >>>>>>>>> interface > >>>>>>>> > >>>>>>>>> yet to be defined. I would rather not open up this > >>>>>>>>> possibility. The > >>>>>>> > >>>>>>>>> Diameter QoS application should be usable all the way from > >>>>>>>>> network element to application server, perhaps passing through > >>>>>>>>> an arbitrary number of proxies that enforce their own > >>>>>>>>> policies, but there should be > >>>>>>>> > >>>>>>>>> 1 interface not 2. Also, it is important to note that the AS > >>>>>>>>> need not > >>>>>>>> > >>>>>>>>> be present at all in some > >>>>>>>>> scenarios: for example, when authorizing requests from a > >>>>>>>>> static subscriber database. > >>>>>>>>> > >>>>>>>>> [DS] First of all, I don't intend to standardize the interface > >>>>>>>>> between > >>>>>>>> > >>>>>>>>> AS and AE in this application. Second, I am not sure why the > >>>>>>>>> separate > >>>>>>> > >>>>>>>>> of AS and AE prevents the AE access to a static subscriber > >>>>>>>>> database. The basic rationale is address as aforementioned. > >>>>>>>>> > >>>>>>>>>>> 3. section 3.3: minor revision on the models for pull; > >>>>>>>>>>> rewrite the > >>>>>> > >>>>>>>>>>> push model (Tina, pls take a look) > >>>>>>>>> > >>>>>>>>> 3.2 looks new. It seems to be overly weighted in favor of the > >>>>>>>>> push model. I would like to point out that there is a big > >>>>>>>>> discovery problem with the push model, especially when the AE > >>>>>>>>> and NE are in different administrative domains. The push > >>>>>>>>> model is only applicable > >>>>>> > >>>>>>>>> to the case where the AE and the NE are in the same > >>>>>>>>> administrative domain and therefore it is a special case. > >>>>>>>>> > >>>>>>>>> [DS] I think in reality the operators mainly look at the > >>>>>>>>> intra-domain > >>>>>>> > >>>>>>>>> policy enforcement interface, whatever pull or push models. I > >>>>>>>>> am not > >>>>>> > >>>>>>>>> in favor of any specific models, just analyze the impact of > >>>>>>>>> endpoint's > >>>>>>>> > >>>>>>>>> capability. If you have any words that can enhance the pull > >>>>>>>>> model, it > >>>>>>> > >>>>>>>>> is very welcome :-). > >>>>>>>>> > >>>>>>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from > >>>>>>>>>>> section > >>>>>>>>>>> 7.4 and > >>>>>>>>> > >>>>>>>>>>> table. But the name still remains in some texts. > >>>>>>>>>>> > >>>>>>>>>>> To be done: > >>>>>>>>>>> 1. state mechanism for Push mode: server initiated policy > >>>>>>>>>>> installation 2. should section 4.4 be merged with section > >>>>>>>>>>> 4.2 since > >>>>>>> > >>>>>>>>>>> both them discuss how to initiate a new Diameter session? In > >>>>>>>>>>> addition, the text needs to be beefed up for server > >>>>>>>>>>> initiated session. > >>>>>>>>>>> 3. authorization schemes/models for Pull: inter-domain > >>>>>>>>>>> authorization > >>>>>>>> > >>>>>>>>>>> between authorizing entity and NE is not envisaged as the > >>>>>>>>>>> basic model, should be revised in the context; Token based > >>>>>>>>>>> approach is not > >>>>>>>> > >>>>>>>>>>> the main trend, should be shortened. > >>>>>>>>> > >>>>>>>>> We need to have inter-domain authorization as the basic > >>>>>>>>> scenario; local authorization should be treated as a special > >>>>>>>>> case. The whole point is to leverage the inter-domain > >>>>>>>>> capability of Diameter to mediate between network elements and > >>>>>>>>> authorizing entities, whether the AEs are application servers > >>>>>>>>> or static subscriber databases. > >>>>>>>>> > >>>>>>>>> [DS] I agree that inter-domain authorization/policy > >>>>>>>>> communication is > >>>>>> > >>>>>>>>> important, but the mechanism and scope of this document is > >>>>>>>>> inappropriate to solve that issue, since it is not the right > >>>>>>>>> way forward envisioned by the industry and operators. > >>>>>>>>> > >>>>>>>>> If we only solve the local case it will mean that an > >>>>>>>>> application server has to be co-located in the local domain. > >>>>>>>>> This is not the way > >>>>>>> > >>>>>>>>> the Internet is supposed to work: services should be > >>>>>>>>> deployable end-to-end, without modifying elements of the > >>>>>>>>> network along the path. It should be possible for the > >>>>>>>>> application server to be located > >>>>>> > >>>>>>>>> anywhere in the network and the AAA part should just work. > >>>>>>>>> > >>>>>>>>> [DS] as I said, the AS and AE can be in different domains. On > >>>>>>>>> the other hand, if we integrate the AS with AE together, it > >>>>>>>>> impose a tight > >>>>>>>> > >>>>>>>>> coupled service model, i.e. AS and AE always have to be in the > >>>>>>>>> same domain. Exactly the issue you are concerned. > >>>>>>>>> > >>>>>>>>>>> 4. The current doc mainly talks about the QoS, should add > >>>>>>>>>>> some tint > >>>>>>> > >>>>>>>>>>> on the policy control side. > >>>>>>>>>>> > >>>>>>>>>>> Please let me know your opinion and how to proceed. > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Dong > >>>>>>>>> > >>>>>>>>> -Pete > >>>> > >>>> > >>>> _______________________________________________ > >>>> DiME mailing list > >>>> DiME@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 19 18:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mA6-0001PH-Pu; Tue, 19 Jun 2007 18:26:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mA5-0001PB-Or for dime@ietf.org; Tue, 19 Jun 2007 18:26:57 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mA2-0007IY-PA for dime@ietf.org; Tue, 19 Jun 2007 18:26:57 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5JMQpkA013619; Tue, 19 Jun 2007 17:26:52 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 17:26:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Date: Tue, 19 Jun 2007 17:26:51 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520936@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: FW: First draft on the integration of QoS application Thread-Index: AceutWPOQbUxj1/bQ4Krh8NNWpduIwD1l7dwAAzQYPA= References: <9b0e41640706141150i640dd29cy89ad225881907627@mail.gmail.com><9b0e41640706141153g677d33e7o6ddb3f53da606939@mail.gmail.com> From: "Sun, Dong \(Dong\)" To: "McCann Peter-A001034" , "Christian Esteve" , X-OriginalArrivalTime: 19 Jun 2007 22:26:51.0783 (UTC) FILETIME=[EF134170:01C7B2C0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea10c7a57c6f5d0512401188e6188235 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Pete, et al, Although I have no objection to define the inter-domain interface, it seems to me the Rx in 3GPP does not fit well with the modeling defined in QoS application: - Rx is defined between Application Function and Policy Decision function (i.e. part of Authorizing entity in QoS application) - QoS application concerns the control of policy enforcement, the interface between authorizing entity and Network element, which is the Gx in 3GPP term. If we really like to cover both inter-domain and intra-domain scenarios in the single QoS application, I think it should be a Gx-like interface. In the inter-domain case, the Gx-like interface will be used between home PCRF and visited PCRF as well; besides it can be used between PCRF and PCEF for intra-domain case. In addition, I think we should allow the flexibility to have Application Server separated from the Authorizing entity (but not mandatory), and maybe no need to standardize that interface between AS and Authorizing entity in this QoS application. If you agree on this proposal, I'd like to edit the latest draft I sent out to reflect this notion. Dong -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Tuesday, June 19, 2007 12:14 PM To: Christian Esteve; dime@ietf.org Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Hi, Christian, Thanks for your comments, I would certainly like to take a look at your paper. I suppose I could be convinced that local policy should be taken care of with a separate interface, but I think it's important that IETF standardize the inter-domain case as a first priority. The local interface is less important to standardize now, because it could easily be taken care of with a proprietary interface based on purchasing decisions made by the operator, or it could easily be incorporated in to the Network Element itself. One of my goals for the diameter-qos draft has been to facilitate the inter-working of disparate application functions in different networks, and I think that should be the focus of this draft. If we really want to add a new local PDP element to the draft I would be ok with a modified Figure 1 that shows this. However, the Diameter cloud would then need to be shown between that entity and the application server, and the document should focus on this latter interface. In other words, we should be standardizing Rx now. -Pete Christian Esteve wrote: > Hi folks, >=20 > the discussion thread reflects once again the confrontation between=20 > the operator SDO and the IETF worlds, and as it usually happens,=20 > disagreements are not only motivated by network engineering issues > but by scope and nomenclature divergences. =20 >=20 >>> I guess I don't see why we need two separate interfaces. They are=20 >>> each transporting roughly the same information and doing the same=20 >>> sort of job. >=20 > It is true that the job and type of infomation are similar, however=20 > the separation of the interfaces makes sense to me. While one=20 > interface is used only to request QoS, the other is expected to carry=20 > and install QoS policy information (with different QoS descriptors). >=20 > The AF-PDP-PEP model (also referred to as AS-AE-NE) reflects the=20 > architecture evolution of the SDOs that introduce policy-based=20 > resource control functions. >=20 > It has been said that: >>>>> There may be proxies in the >>>>> Diameter cloud that enforce their own policy decisions, some of=20 >>>>> which will be local to the Network Element's administrative=20 >>>>> domain. >=20 > To my understanding that is why the separated interfaces make sense. >=20 > An intermediate PDP (also referred to as PDF) may enforce further=20 > policies (network type specific, user profile related, > operator-based) in conjunction with other network elements (resource=20 > information, user database). >=20 > Furthermore, the QoS description over the AF-PDP interface is likely=20 > to differ from the QoS information describing the policy to be=20 > instaslled in the NE, harmonizing and easing AF QoS requests and=20 > enabling the QoS policy installation mechanism to evolve separately > in accordance to the transport network specifics. =20 >=20 > The PDP would certainly have an inter-domain interface to AFs and=20 > other inter- an intra PDPs. I bnelieve that the Diameter QoS=20 > application running between the AF and the PDP could be defined in a=20 > way that it could be applied for the inter-domain PDP-PDP peering > interface. =20 >=20 > Unfortunately my contribution to the discussion at this point is not=20 > enriching the discussion regarding the implications to the Diameter=20 > functionality (e.g. command and AVPs, realm routing, discovery > schemes, etc.). =20 >=20 > However, I am sharing under > http://www.dca.fee.unicamp.br/~pasquini/dime-qos-app/ > some figures depicting the abstracted SDOs architectures that could=20 > help in the following discussions around the Diameter QoS application. > The figures have been extracted > from the the paper "A review on policy-based resource and admission=20 > control functions in evolving access and next generation networks",=20 > recently accepted for publication (draft copy can be provided if > interested). =20 >=20 >=20 > Best regards, > Christian >>=20 >>=20 >>> ------------------------------ >>>=20 >>> Message: 5 >>> Date: Wed, 13 Jun 2007 18:08:21 -0400 >>> From: "McCann Peter-A001034" >>> Subject: [Dime] FW: First draft on the integration of QoS=20 >>> application >>> To: >>> Message-ID: >>> =20 >>> >>> Content-Type: text/plain; charset=3D"us-ascii"=20 >>>=20 >>> Below is a discussion thread that has been taking place among=20 >>> authors of the diameter-qos draft. We thought it important that the >>> mailing list have some visibility to the discussion. Comments=20 >>> welcome. >>>=20 >>> -Pete >>>=20 >>> McCann Peter-A001034 wrote: >>>> Hi, Dong, >>>>=20 >>>> I guess I don't see why we need two separate interfaces. They are=20 >>>> each transporting roughly the same information and doing the same=20 >>>> sort of job. >>>>=20 >>>> The current document in my mind has always been an inter-domain=20 >>>> interface. See the abstract: >>>>=20 >>>> ...Clients that implement the Diameter QoS application contact an >>>> authorizing entity/application server that is located somewhere >>>> in the network, allowing for a wide variety of flexible >>>> deployment models.=20 >>>>=20 >>>> And the following text in Section 3.2: >>>>=20 >>>> Inter-domain support >>>>=20 >>>> In particular, users may roam outside their home network, >>>> leading to a situation where the network element and >>>> authorizing entity are in different administrative domains. >>>>=20 >>>> -Pete >>>>=20 >>>> Sun, Dong (Dong) wrote: >>>>> Hi Pete, >>>>> I have no doubt about the importance of inter-domain policy=20 >>>>> communications, and it might be better to use the Diameter broker=20 >>>>> instead of SIP proxy to deal with inter-domain resource=20 >>>>> management. >>>>> In fact, I think 3GPP does use the similar model as you described, >>>>> that a Diameter broker (client) is embedded in the AF (e.g.=20 >>>>> P-CSCF), and the interface between AF and underlying Policy engine >>>>> (e.g. PCRF) is an inter-domain interface per se. >>>>> certainly, since they (SIP and Diameter brokers) are grouped=20 >>>>> together, it is less flexible and scalable for the implementation. >>>>>=20 >>>>> However, I think this interface (named as Rx in 3GPP, Gq' in=20 >>>>> TISPAN, Rs in ITU) is not for the control of policy enforcement=20 >>>>> directly. In my view, this interface (Rx) is a peering interface=20 >>>>> between policy servers rather than between policy server and=20 >>>>> enforcement point as described in the current QoS application, and >>>>> I believe it is more appropriate to model the inter-domain=20 >>>>> interface as the policy server to policy server (PDF-PDF) peering=20 >>>>> interface. >>>>>=20 >>>>> I have no problem to develop a doc to address this inter-domain=20 >>>>> application, however, if you look around the current document, I=20 >>>>> did not see any indication from that perspective. >>>>>=20 >>>>> Dong >>>>>=20 >>>>> -----Original Message----- >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>> Sent: Wednesday, June 13, 2007 2:11 PM >>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina=20 >>>>> TSOU; Avri Doria Cc: Victor Fajardo >>>>> Subject: RE: First draft on the integration of QoS application >>>>>=20 >>>>> Hi, Dong, >>>>>=20 >>>>> Sun, Dong (Dong) wrote: >>>>>> Hi Pete, >>>>>>=20 >>>>>> Thanks for clarification. Just wondering if you can give an=20 >>>>>> example who will use the "inter-domain" model for policy=20 >>>>>> enforcement control, i.e. PDP and PEP reside in the different=20 >>>>>> operator's administrative domains. Since the inter-domain is to=20 >>>>>> serve for the operator's domain, I don't know how to create an=20 >>>>>> application without considering their need. (BTW, I have no=20 >>>>>> strong view to limit it to intra-domain only if the use case can=20 >>>>>> be identified). >>>>>=20 >>>>> Arbitrary third parties should be allowed to deploy application=20 >>>>> servers and interface to the Diameter cloud to get QoS from the=20 >>>>> network. The Diameter QoS Application should play this role. >>>>> In the extreme case, I should be allowed to put a SIP server in my >>>>> basement, sign up with a Diameter broker, and run my application=20 >>>>> end-to-end. >>>>>=20 >>>>>> I agree that this application should support "a generic mediator=20 >>>>>> that can handle many applications". However, Given the integrated >>>>>> AS and AE, it makes the AE has to be collocated with the=20 >>>>>> application content providers rather than the network itself, I=20 >>>>>> feel it is also too limited and not the common case in reality.=20 >>>>>> (As far as I know, all deployed or emerging network=20 >>>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view=20 >>>>>> this solution as the main trend). I am wondering who will use=20 >>>>>> this application eventually. >>>>>=20 >>>>> I am not ruling out a PDP in the network local to the PEP. I am=20 >>>>> just saying that this PDP should be viewed as a Diameter proxy on=20 >>>>> the path to the Authorizing Entity, which itself may be either a=20 >>>>> static subscriber database or an active application server. >>>>> I don't want to work only on the localized protocol, I want to=20 >>>>> define the inter-domain one. If you insist on separating the AE=20 >>>>> from the AS then I would say that the important Diameter interface >>>>> is the one between AE and AS. It is much more important to=20 >>>>> standardize the inter-domain interface because this is the one=20 >>>>> that will be used between operators. >>>>>=20 >>>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they are >>>>> going down the path of using SIP proxies as the inter-domain=20 >>>>> interface. I think this architecture is bad for the Internet, and >>>>> will limit the kinds of applications that can be deployed. >>>>> The Internet model is that applications should be deployable=20 >>>>> without modifying the middleboxes. Tying SIP servers to the=20 >>>>> network traffic path also doesn't work well with Mobile IP. >>>>>=20 >>>>>> In addition, the scalable roaming agreements sound like a general >>>>>> algorithm that may be applicable for any inter-domain issue in=20 >>>>>> the context of Diameter applications, or it is only the fundament >>>>>> to this application? >>>>>=20 >>>>> The Diameter NASREQ application (similar to the basic RADIUS >>>>> protocol) has always been about inter-domain operation. Diameter=20 >>>>> is used as the mediating protocol between different operator=20 >>>>> domains. I think we should be following the same model with the=20 >>>>> Diameter QoS application. >>>>>=20 >>>>> -Pete >>>>>=20 >>>>>> Dong >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>> Sent: Wednesday, June 13, 2007 11:06 AM >>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina=20 >>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on=20 >>>>>> the integration of QoS application >>>>>>=20 >>>>>> Hi, Dong, >>>>>>=20 >>>>>> An "Autonomous System" has a very specific meaning in the context >>>>>> of routing protocols; I would not want to say that they=20 >>>>>> correspond one-to-one with the "domains" that exist when I talk=20 >>>>>> about "inter-domain" in the context of diameter-qos. I would say >>>>>> that "operator's administrative domain" is a better term. >>>>>>=20 >>>>>> In any case, I think that the Diameter cloud from the figure 1=20 >>>>>> should be a generic inter-domain mediator that can handle many=20 >>>>>> applications, of which Diameter QoS is one. The scalable roaming >>>>>> agreements embodied in this cloud should allow the Authorizing=20 >>>>>> Entity to be anywhere in the network. There may be proxies in=20 >>>>>> the Diameter cloud that enforce their own policy decisions, some=20 >>>>>> of which will be local to the Network Element's administrative=20 >>>>>> domain. However, that should not impact the specification of the=20 >>>>>> Diameter QoS Application. This inter-domain operation has been at >>>>>> the core of the document since I started it: see Section 3.2 in=20 >>>>>> the -00 version. >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>> Sun, Dong (Dong) wrote: >>>>>>> Hi Pete, >>>>>>>=20 >>>>>>> Before making any conclusion, I'd like to clarify some terms: >>>>>>> Since you mentioned this is IETF, Internet and such, the domain=20 >>>>>>> you refer to is in the context of the "Autonomous System" or=20 >>>>>>> "operator's administrative domain". >>>>>>>=20 >>>>>>> Dong >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>>> Sent: Wednesday, June 13, 2007 10:27 AM >>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina=20 >>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on=20 >>>>>>> the integration of QoS application >>>>>>>=20 >>>>>>> Hi, Dong, >>>>>>>=20 >>>>>>> I think you and I have a fundamental disagreement on the scope=20 >>>>>>> and purpose of this document. I really don't see the need to=20 >>>>>>> standardize >>>>>=20 >>>>>>> an intra-domain localized solution to the problem. This is IETF >>>>>>> we should be solving the problem for the whole Internet, which=20 >>>>>>> means inter-domain is the target. I understand that some=20 >>>>>>> operators might not want to open their networks, but we should=20 >>>>>>> not be defining standards for these closed architectures. >>>>>>>=20 >>>>>>> I also feel strongly that we should have adequate discovery=20 >>>>>>> mechanisms >>>>>>=20 >>>>>>> for all modes of operation specified in this document; otherwise >>>>>>> it could lead to inter-operability problems. >>>>>>>=20 >>>>>>> Hannes, I would like to note this as a serious issue that should >>>>>>> be resolved before we proceed any further. I would like to=20 >>>>>>> check with the mailing list and the ADs on their preferences. =20 >>>>>>> What do you think >>>>>=20 >>>>>>> would be the appropriate way to introduce the issue? Would you=20 >>>>>>> like to introduce the question to the mailing list? >>>>>>>=20 >>>>>>> -Pete >>>>>>>=20 >>>>>>> Sun, Dong (Dong) wrote: >>>>>>>> Hi Pete, >>>>>>>>=20 >>>>>>>> First of all, Thanks for the review and comments. >>>>>>>>=20 >>>>>>>> 1. Concerning the split of Application Server and Authorizing=20 >>>>>>>> Entity, >>>>>>=20 >>>>>>>> which is somewhat related to another main comment you brought=20 >>>>>>>> up i.e. the relationship between Authorizing Entity and NE -=20 >>>>>>>> inter-domain Vs. intra-domain, the rationale in my mind is as >>>>>>>> follow: - In the real network (or the vision of NGN, or=20 >>>>>>>> somewhat the >>>>>=20 >>>>>>>> net neutrality perspective), the packet (transport) network=20 >>>>>>>> should support >>>>>>>=20 >>>>>>>> a variety of applications which may belong to different SPs=20 >>>>>>>> i.e. in different domain. The PDP (i.e. Authorizing entity in=20 >>>>>>>> the context of >>>>>=20 >>>>>>>> QoS application) can act as the arbitrator to isolate the=20 >>>>>>>> diversity of application attributes from the speciality of=20 >>>>>>>> network functionality. The authorizing entity is typically part >>>>>>>> of transport >>>>>=20 >>>>>>>> network domain along with the NEs since the network operators=20 >>>>>>>> are commonly willing to >>>>>>>=20 >>>>>>>> neither rely on the third party to control the use of their=20 >>>>>>>> network resources nor disclose the network details (e.g. >>>>>>>> topology, resource usage and policies) to other carriers/SPs. >>>>>>>> Therefore, the common case is that the interface between=20 >>>>>>>> Authorizing entity and NE (enforcement point) should be=20 >>>>>>>> intra-domain in nature. >>>>>>>>=20 >>>>>>>> - On the other hand, the interface between AS and AE can be=20 >>>>>>>> inter-domain, which also makes the life easier concerning the=20 >>>>>>>> inter-domain enforcement interface. >>>>>>>>=20 >>>>>>>> - The policy communications between different domains is quite=20 >>>>>>>> important, for example, for the roaming scenario. However, it=20 >>>>>>>> is outside the scope of this application if my understanding is >>>>>>>> correct. I feel it is better to be solved through=20 >>>>>>>> inter-Authorizing Entity interface rather than this interface. >>>>>>>> Certainly, the command and AVPs >>>>>>=20 >>>>>>>> might be shared, but I would rather not mix them together for=20 >>>>>>>> the time being. >>>>>>>>=20 >>>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree=20 >>>>>>>> that it >>>>>=20 >>>>>>>> is a tricky issue and also support to describe the issue in the >>>>>>>> document. However, I'd like to point out, this document should=20 >>>>>>>> concentrate on the protocol related issue and allow the=20 >>>>>>>> flexibility to use the other discovery mechanism beyond the=20 >>>>>>>> Diameter protocol capability. In other words, we mainly need to >>>>>>>> define some mechanism based on Diameter protocol's capability,=20 >>>>>>>> such as the realm based routing, and leave the door open for=20 >>>>>>>> other advanced discovery schemes. >>>>>>>>=20 >>>>>>>> See additional comment in line... >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Dong >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >>>>>>>> Sent: Tuesday, June 12, 2007 5:26 PM >>>>>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina=20 >>>>>>>> TSOU; >>>>>=20 >>>>>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the=20 >>>>>>>> integration of QoS application >>>>>>>>=20 >>>>>>>> Hi, all, >>>>>>>>=20 >>>>>>>> Please see my comments in line. >>>>>>>>=20 >>>>>>>> Hannes Tschofenig wrote: >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> could you please take a look at the proposal by Dong? >>>>>>>>>=20 >>>>>>>>> They are available here: >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>> http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/dra >>> ft >>>>> -i >>>>>>>> etf-dime-diameter-qos-01-ds.txt >>>>>>>>>=20 >>>>>>>>> The XML file is in the same directory, as usual. >>>>>>>>>=20 >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>>=20 >>>>>>>>> Sun, Dong (Dong) wrote: >>>>>>>>>> Hi Hannes et al, >>>>>>>>>>=20 >>>>>>>>>> Attached is the first cut to integrate two I-Ds. The change=20 >>>>>>>>>> is a minimum set based on the comments from the exploder=20 >>>>>>>>>> (Tina, Christian >>>>>>>=20 >>>>>>>>>> and Tolga). There are some open issues to be done, I'd like=20 >>>>>>>>>> to get >>>>>=20 >>>>>>>>>> your comments on changes first and discuss how to proceed on=20 >>>>>>>>>> those >>>>>=20 >>>>>>>>>> open items before making any further editings. Main changes: >>>>>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push modes >>>>>>>>=20 >>>>>>>> In the definition of Pull mode, the following sentence >>>>>>>> The Authorizing Entity then installs the QoS >>>>>>>> authorization decision to the Network Element=20 >>>>>>>> initiatively. needs work. "initiatively" is not a word. >>>>>>>>=20 >>>>>>>> [DS] ok. Any good word? Basically I don't like some words such=20 >>>>>>>> as unsolicited since it is used by 3GPP for different meaning. >>>>>>>> Maybe "directly" instead?=20 >>>>>>>>=20 >>>>>>>>>> 2. section 3.1/2: modify the architecture diagram to separate >>>>>>>>>> the Authorizing Entity from AS (further alignment is needed=20 >>>>>>>>>> in the context); and add new subsections to addressing the=20 >>>>>>>>>> endpoint features >>>>>>>>=20 >>>>>>>>>> and push/pull modes. >>>>>>>>=20 >>>>>>>> Breaking up the AS and AE implies that there will be another=20 >>>>>>>> interface >>>>>>>=20 >>>>>>>> yet to be defined. I would rather not open up this=20 >>>>>>>> possibility. The >>>>>>=20 >>>>>>>> Diameter QoS application should be usable all the way from=20 >>>>>>>> network element to application server, perhaps passing through=20 >>>>>>>> an arbitrary number of proxies that enforce their own policies, >>>>>>>> but there should be >>>>>>>=20 >>>>>>>> 1 interface not 2. Also, it is important to note that the AS=20 >>>>>>>> need not >>>>>>>=20 >>>>>>>> be present at all in some >>>>>>>> scenarios: for example, when authorizing requests from a static >>>>>>>> subscriber database. >>>>>>>>=20 >>>>>>>> [DS] First of all, I don't intend to standardize the interface=20 >>>>>>>> between >>>>>>>=20 >>>>>>>> AS and AE in this application. Second, I am not sure why the=20 >>>>>>>> separate >>>>>>=20 >>>>>>>> of AS and AE prevents the AE access to a static subscriber=20 >>>>>>>> database. The basic rationale is address as aforementioned. >>>>>>>>=20 >>>>>>>>>> 3. section 3.3: minor revision on the models for pull;=20 >>>>>>>>>> rewrite the >>>>>=20 >>>>>>>>>> push model (Tina, pls take a look) >>>>>>>>=20 >>>>>>>> 3.2 looks new. It seems to be overly weighted in favor of the=20 >>>>>>>> push model. I would like to point out that there is a big=20 >>>>>>>> discovery problem with the push model, especially when the AE=20 >>>>>>>> and NE are in different administrative domains. The push model >>>>>>>> is only applicable >>>>>=20 >>>>>>>> to the case where the AE and the NE are in the same=20 >>>>>>>> administrative domain and therefore it is a special case. >>>>>>>>=20 >>>>>>>> [DS] I think in reality the operators mainly look at the=20 >>>>>>>> intra-domain >>>>>>=20 >>>>>>>> policy enforcement interface, whatever pull or push models. I=20 >>>>>>>> am not >>>>>=20 >>>>>>>> in favor of any specific models, just analyze the impact of=20 >>>>>>>> endpoint's >>>>>>>=20 >>>>>>>> capability. If you have any words that can enhance the pull=20 >>>>>>>> model, it >>>>>>=20 >>>>>>>> is very welcome :-). >>>>>>>>=20 >>>>>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section >>>>>>>>>> 7.4 and >>>>>>>>=20 >>>>>>>>>> table. But the name still remains in some texts. >>>>>>>>>>=20 >>>>>>>>>> To be done: >>>>>>>>>> 1. state mechanism for Push mode: server initiated policy=20 >>>>>>>>>> installation 2. should section 4.4 be merged with section >>>>>>>>>> 4.2 since >>>>>>=20 >>>>>>>>>> both them discuss how to initiate a new Diameter session? In=20 >>>>>>>>>> addition, the text needs to be beefed up for server initiated >>>>>>>>>> session. >>>>>>>>>> 3. authorization schemes/models for Pull: inter-domain=20 >>>>>>>>>> authorization >>>>>>>=20 >>>>>>>>>> between authorizing entity and NE is not envisaged as the=20 >>>>>>>>>> basic model, should be revised in the context; Token based=20 >>>>>>>>>> approach is not >>>>>>>=20 >>>>>>>>>> the main trend, should be shortened. >>>>>>>>=20 >>>>>>>> We need to have inter-domain authorization as the basic=20 >>>>>>>> scenario; local authorization should be treated as a special=20 >>>>>>>> case. The whole point is to leverage the inter-domain=20 >>>>>>>> capability of Diameter to mediate between network elements and=20 >>>>>>>> authorizing entities, whether the AEs are application servers=20 >>>>>>>> or static subscriber databases. >>>>>>>>=20 >>>>>>>> [DS] I agree that inter-domain authorization/policy=20 >>>>>>>> communication is >>>>>=20 >>>>>>>> important, but the mechanism and scope of this document is=20 >>>>>>>> inappropriate to solve that issue, since it is not the right=20 >>>>>>>> way forward envisioned by the industry and operators. >>>>>>>>=20 >>>>>>>> If we only solve the local case it will mean that an=20 >>>>>>>> application server has to be co-located in the local domain. >>>>>>>> This is not the way >>>>>>=20 >>>>>>>> the Internet is supposed to work: services should be deployable >>>>>>>> end-to-end, without modifying elements of the network along the >>>>>>>> path. It should be possible for the application server to be=20 >>>>>>>> located >>>>>=20 >>>>>>>> anywhere in the network and the AAA part should just work. >>>>>>>>=20 >>>>>>>> [DS] as I said, the AS and AE can be in different domains. On=20 >>>>>>>> the other hand, if we integrate the AS with AE together, it=20 >>>>>>>> impose a tight >>>>>>>=20 >>>>>>>> coupled service model, i.e. AS and AE always have to be in the=20 >>>>>>>> same domain. Exactly the issue you are concerned. >>>>>>>>=20 >>>>>>>>>> 4. The current doc mainly talks about the QoS, should add=20 >>>>>>>>>> some tint >>>>>>=20 >>>>>>>>>> on the policy control side. >>>>>>>>>>=20 >>>>>>>>>> Please let me know your opinion and how to proceed. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Dong >>>>>>>>=20 >>>>>>>> -Pete >>>=20 >>>=20 >>>=20 >>>=20 >>> ------------------------------ >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>>=20 >>>=20 >>> End of DiME Digest, Vol 18, Issue 13 >>> ************************************ >>>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 19 18:31:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mEI-0002CC-Qj; Tue, 19 Jun 2007 18:31:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mEH-0002C4-EQ for dime@ietf.org; Tue, 19 Jun 2007 18:31:17 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mEG-0000MG-I5 for dime@ietf.org; Tue, 19 Jun 2007 18:31:17 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5JMVC10021110; Tue, 19 Jun 2007 17:31:12 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 17:31:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] FW: First draft on the integration of QoS application Date: Tue, 19 Jun 2007 17:31:11 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520937@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7187FBC@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: First draft on the integration of QoS application Thread-Index: AcetISvGTMneLoT9RHySt6sElj/kSQADAwBAAAQSw0AAIhfZoAAA/rRwAAA4YPAAALX/UAAEvulgAAHFv2AAAzbrgAAEo/mQACyi5MAA9NG4UAALIyWwAABIoPAAAL63UAAA3Dag References: <033458F56EC2A64E8D2D7B759FA3E7E7187F9F@sonusmail04.sonusnet.com><033458F56EC2A64E8D2D7B759FA3E7E7187FBB@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7187FBC@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" , "McCann Peter-A001034" , X-OriginalArrivalTime: 19 Jun 2007 22:31:12.0188 (UTC) FILETIME=[8A49E7C0:01C7B2C1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 04ebe73024b6be81174765e91aced811 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, I fully agree on this idea. As stated in the discussion with Pete, I think we only need to state how to support the discovery/routing from the Diameter protocol capability perspective. How to configure the network and detailed parameters/algorithms beyond Diameter protocol level is out of scope in this doc. Dong=20 -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Tuesday, June 19, 2007 6:10 PM To: McCann Peter-A001034; dime@ietf.org Subject: RE: [Dime] FW: First draft on the integration of QoS application Hi Pete, I fully agree with the approach of providing information inline with existing Diameter base protocol mechanisms. My worry was about defining detailed procedures more on application level, e.g. how QoS AVPs need to be processed/analyzed for routing decision. It may be an idea to touch this topic briefly without normative text but I guess other than that, this is really implementation dependent. Thanks, Tolga > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, June 19, 2007 5:58 PM > To: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] FW: First draft on the integration of QoS application >=20 > Hi, Tolga, >=20 > I think the next-hop for a session will be based on Diameter routing=20 > based on the application ID and Destination-Realm AVP, as specified in > section 2.7 of the base protocol. As such, we need to provide=20 > guidance in how to set these parameters in any request message used by > the Diameter QoS application. > If this information is required from the underlying network element=20 > that receives a QoS request, we should state that. > Similarly, if the information comes from an application server, we=20 > should at least give some overview of how the AS learns this=20 > information in the inter-domain case. >=20 > -Pete >=20 > Asveren, Tolga wrote: > > Hi Pete, > > > > I think I agree with you overall just I think we need to be careful=20 > > about what we mean with "discovery". It could be that it is better to > > leave it implementation dependent/out of scope of Diameter QoS=20 > > protocol, how a Diameter node selects the next-hop for the initial=20 > > request for a session. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >> Sent: Tuesday, June 19, 2007 12:16 PM > >> To: Asveren, Tolga; dime@ietf.org > >> Subject: RE: [Dime] FW: First draft on the integration of QoS=20 > >> application > >> > >> Hi, Tolga, > >> > >> I agree that we should have the flexibility for the diameter-qos=20 > >> application to be inter-domain. As such, we need to define=20 > >> everything needed to make that work for both the push and pull=20 > >> modes, including discovery and routing of messages end-to-end. > >> > >> -Pete > >> > >> > >> Asveren, Tolga wrote: > >>> IMHO it makes sense to separate AF and PDF functionalities depending > >>> on the network topology/business model. It provides a single point > >>> of contact for AF, if the service instance requires QoS=20 > >>> reservations in multiple networks/devices etc... > >>> > >>> OTOH, I have no strong opinion in terms of where the inter-domain=20 > >>> boundary is going to be. It could be that both AF/PDF and PDF/PEP=20 > >>> interfaces are inter-domain for a specific service instance. > >>> Probably this is not something for us to decide but we need to have > >>> the flexibility to support all models (if possible). > >>> > >>> I guess IETF QoS work can address both interfaces. PDF can act as a > >>> Diameter proxy, Diameter B2BUA type of entity etc... or may not be > >>> in the picture at all depending on the business model. What problem > >>> do we see with this approach? > >>> > >>> Thanks, > >>> Tolga > >>> > >>>> -----Original Message----- > >>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>> Sent: Wednesday, June 13, 2007 6:08 PM > >>>> To: dime@ietf.org > >>>> Subject: [Dime] FW: First draft on the integration of QoS=20 > >>>> application > >>>> > >>>> Below is a discussion thread that has been taking place among=20 > >>>> authors of the diameter-qos draft. We thought it important that=20 > >>>> the mailing list have some visibility to the discussion. Comments > >>>> welcome. > >>>> > >>>> -Pete > >>>> > >>>> McCann Peter-A001034 wrote: > >>>>> Hi, Dong, > >>>>> > >>>>> I guess I don't see why we need two separate interfaces. They are > >>>>> each transporting roughly the same information and doing the same > >>>>> sort of job. > >>>>> > >>>>> The current document in my mind has always been an inter-domain=20 > >>>>> interface. See the abstract: > >>>>> > >>>>> ...Clients that implement the Diameter QoS application contact an > >>>>> authorizing entity/application server that is located somewhere > >>>>> in the network, allowing for a wide variety of flexible > >>>>> deployment models. > >>>>> > >>>>> And the following text in Section 3.2: > >>>>> > >>>>> Inter-domain support > >>>>> > >>>>> In particular, users may roam outside their home network, > >>>>> leading to a situation where the network element and > >>>>> authorizing entity are in different administrative domains. > >>>>> > >>>>> -Pete > >>>>> > >>>>> Sun, Dong (Dong) wrote: > >>>>>> Hi Pete, > >>>>>> I have no doubt about the importance of inter-domain policy=20 > >>>>>> communications, and it might be better to use the Diameter broker > >>>>>> instead of SIP proxy to deal with inter-domain resource=20 > >>>>>> management. In fact, I think 3GPP does use the similar model as > >>>>>> you described, that a Diameter broker (client) is embedded in=20 > >>>>>> the AF (e.g. P-CSCF), and the interface between AF and=20 > >>>>>> underlying Policy engine (e.g. PCRF) is an inter-domain=20 > >>>>>> interface per se. certainly, since they (SIP and Diameter > >>>>>> brokers) are grouped together, it is less flexible and scalable > >>>>>> for the implementation. > >>>>>> > >>>>>> However, I think this interface (named as Rx in 3GPP, Gq' in=20 > >>>>>> TISPAN, Rs in ITU) is not for the control of policy enforcement > >>>>>> directly. In my view, this interface (Rx) is a peering interface > >>>>>> between policy servers rather than between policy server and=20 > >>>>>> enforcement point as described in the current QoS application,=20 > >>>>>> and I believe it is more appropriate to model the inter-domain=20 > >>>>>> interface as the policy server to policy server (PDF-PDF)=20 > >>>>>> peering interface. > >>>>>> > >>>>>> I have no problem to develop a doc to address this inter-domain > >>>>>> application, however, if you look around the current document, I > >>>>>> did not see any indication from that perspective. > >>>>>> > >>>>>> Dong > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>> Sent: Wednesday, June 13, 2007 2:11 PM > >>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina=20 > >>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>> the integration of QoS application > >>>>>> > >>>>>> Hi, Dong, > >>>>>> > >>>>>> Sun, Dong (Dong) wrote: > >>>>>>> Hi Pete, > >>>>>>> > >>>>>>> Thanks for clarification. Just wondering if you can give an=20 > >>>>>>> example who will use the "inter-domain" model for policy=20 > >>>>>>> enforcement control, i.e. PDP and PEP reside in the different=20 > >>>>>>> operator's administrative domains. Since the inter-domain is to > >>>>>>> serve for the operator's domain, I don't know how to create an > >>>>>>> application without considering their need. (BTW, I have no=20 > >>>>>>> strong view to limit it to intra-domain only if the use case can > >>>>>>> be identified). > >>>>>> > >>>>>> Arbitrary third parties should be allowed to deploy application > >>>>>> servers and interface to the Diameter cloud to get QoS from the > >>>>>> network. The Diameter QoS Application should play this role. > >>>>>> In the extreme case, I should be allowed to put a SIP server in > >>>>>> my basement, sign up with a Diameter broker, and run my=20 > >>>>>> application end-to-end. > >>>>>> > >>>>>>> I agree that this application should support "a generic mediator > >>>>>>> that can handle many applications". However, Given the=20 > >>>>>>> integrated AS and AE, it makes the AE has to be collocated with > >>>>>>> the application content providers rather than the network=20 > >>>>>>> itself, I feel it is also too limited and not the common case=20 > >>>>>>> in reality. (As far as I know, all deployed or emerging network > >>>>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view > >>>>>>> this solution as the main trend). I am wondering who will use=20 > >>>>>>> this application eventually. > >>>>>> > >>>>>> I am not ruling out a PDP in the network local to the PEP. I am > >>>>>> just saying that this PDP should be viewed as a Diameter proxy on > >>>>>> the path to the Authorizing Entity, which itself may be either a > >>>>>> static subscriber database or an active application server. > >>>>>> I don't want to work only on the localized protocol, I want to=20 > >>>>>> define the inter-domain one. If you insist on separating the AE > >>>>>> from the AS then I would say that the important Diameter=20 > >>>>>> interface is the one between AE and AS. It is much more=20 > >>>>>> important to standardize the inter-domain interface because this > >>>>>> is the one that will be used between operators. > >>>>>> > >>>>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they=20 > >>>>>> are going down the path of using SIP proxies as the inter-domain > >>>>>> interface. I think this architecture is bad for the Internet,=20 > >>>>>> and will limit the kinds of applications that can be deployed. > >>>>>> The Internet model is that applications should be deployable=20 > >>>>>> without modifying the middleboxes. Tying SIP servers to the=20 > >>>>>> network traffic path also doesn't work well with Mobile IP. > >>>>>> > >>>>>>> In addition, the scalable roaming agreements sound like a=20 > >>>>>>> general algorithm that may be applicable for any inter-domain=20 > >>>>>>> issue in the context of Diameter applications, or it is only=20 > >>>>>>> the fundament to this application? > >>>>>> > >>>>>> The Diameter NASREQ application (similar to the basic RADIUS > >>>>>> protocol) has always been about inter-domain operation. Diameter > >>>>>> is used as the mediating protocol between different operator=20 > >>>>>> domains. I think we should be following the same model with the > >>>>>> Diameter QoS application. > >>>>>> > >>>>>> -Pete > >>>>>> > >>>>>>> Dong > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>> Sent: Wednesday, June 13, 2007 11:06 AM > >>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>>> the integration of QoS application > >>>>>>> > >>>>>>> Hi, Dong, > >>>>>>> > >>>>>>> An "Autonomous System" has a very specific meaning in the=20 > >>>>>>> context of routing protocols; I would not want to say that they > >>>>>>> correspond one-to-one with the "domains" that exist when I talk > >>>>>>> about "inter-domain" in the context of diameter-qos. I would=20 > >>>>>>> say that "operator's administrative domain" is a better term. > >>>>>>> > >>>>>>> In any case, I think that the Diameter cloud from the figure 1 > >>>>>>> should be a generic inter-domain mediator that can handle many > >>>>>>> applications, of which Diameter QoS is one. The scalable=20 > >>>>>>> roaming agreements embodied in this cloud should allow the=20 > >>>>>>> Authorizing Entity to be anywhere in the network. There may be > >>>>>>> proxies in the Diameter cloud that enforce their own policy=20 > >>>>>>> decisions, some of which will be local to the Network Element's > >>>>>>> administrative domain. However, that should not impact the=20 > >>>>>>> specification of the Diameter QoS Application. This=20 > >>>>>>> inter-domain operation has been at the core of the document=20 > >>>>>>> since I started it: see Section 3.2 in the -00 version. > >>>>>>> > >>>>>>> -Pete > >>>>>>> > >>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>> Hi Pete, > >>>>>>>> > >>>>>>>> Before making any conclusion, I'd like to clarify some terms: > >>>>>>>> Since you mentioned this is IETF, Internet and such, the domain > >>>>>>>> you refer to is in the context of the "Autonomous System" or=20 > >>>>>>>> "operator's administrative domain". > >>>>>>>> > >>>>>>>> Dong > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>>> Sent: Wednesday, June 13, 2007 10:27 AM > >>>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>>>> the integration of QoS application > >>>>>>>> > >>>>>>>> Hi, Dong, > >>>>>>>> > >>>>>>>> I think you and I have a fundamental disagreement on the scope > >>>>>>>> and purpose of this document. I really don't see the need to > >>>>>>>> standardize > >>>>>> > >>>>>>>> an intra-domain localized solution to the problem. This is=20 > >>>>>>>> IETF we should be solving the problem for the whole Internet, > >>>>>>>> which means inter-domain is the target. I understand that some > >>>>>>>> operators might not want to open their networks, but we should > >>>>>>>> not be defining standards for these closed architectures. > >>>>>>>> > >>>>>>>> I also feel strongly that we should have adequate discovery=20 > >>>>>>>> mechanisms > >>>>>>> > >>>>>>>> for all modes of operation specified in this document;=20 > >>>>>>>> otherwise it could lead to inter-operability problems. > >>>>>>>> > >>>>>>>> Hannes, I would like to note this as a serious issue that=20 > >>>>>>>> should be resolved before we proceed any further. I would=20 > >>>>>>>> like to check with the mailing list and the ADs on their=20 > >>>>>>>> preferences. What do you think > >>>>>> > >>>>>>>> would be the appropriate way to introduce the issue? Would you > >>>>>>>> like to introduce the question to the mailing list? > >>>>>>>> > >>>>>>>> -Pete > >>>>>>>> > >>>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>>> Hi Pete, > >>>>>>>>> > >>>>>>>>> First of all, Thanks for the review and comments. > >>>>>>>>> > >>>>>>>>> 1. Concerning the split of Application Server and Authorizing > >>>>>>>>> Entity, > >>>>>>> > >>>>>>>>> which is somewhat related to another main comment you brought > >>>>>>>>> up i.e. the relationship between Authorizing Entity and NE - > >>>>>>>>> inter-domain Vs. intra-domain, the rationale in my mind is as > >>>>>>>>> follow: - In the real network (or the vision of NGN, or=20 > >>>>>>>>> somewhat the > >>>>>> > >>>>>>>>> net neutrality perspective), the packet (transport) network=20 > >>>>>>>>> should support > >>>>>>>> > >>>>>>>>> a variety of applications which may belong to different SPs=20 > >>>>>>>>> i.e. in different domain. The PDP (i.e. Authorizing entity in > >>>>>>>>> the context of > >>>>>> > >>>>>>>>> QoS application) can act as the arbitrator to isolate the=20 > >>>>>>>>> diversity of application attributes from the speciality of=20 > >>>>>>>>> network functionality. The authorizing entity is typically=20 > >>>>>>>>> part of transport > >>>>>> > >>>>>>>>> network domain along with the NEs since the network operators > >>>>>>>>> are commonly willing to > >>>>>>>> > >>>>>>>>> neither rely on the third party to control the use of their=20 > >>>>>>>>> network resources nor disclose the network details (e.g. > >>>>>>>>> topology, resource usage and policies) to other carriers/SPs. > >>>>>>>>> Therefore, the common case is that the interface between=20 > >>>>>>>>> Authorizing entity and NE (enforcement point) should be=20 > >>>>>>>>> intra-domain in nature. > >>>>>>>>> > >>>>>>>>> - On the other hand, the interface between AS and AE can be=20 > >>>>>>>>> inter-domain, which also makes the life easier concerning the > >>>>>>>>> inter-domain enforcement interface. > >>>>>>>>> > >>>>>>>>> - The policy communications between different domains is quite > >>>>>>>>> important, for example, for the roaming scenario. However, it > >>>>>>>>> is outside the scope of this application if my understanding > >>>>>>>>> is correct. I feel it is better to be solved through=20 > >>>>>>>>> inter-Authorizing Entity interface rather than this interface. > >>>>>>>>> Certainly, the command and AVPs > >>>>>>> > >>>>>>>>> might be shared, but I would rather not mix them together for > >>>>>>>>> the time being. > >>>>>>>>> > >>>>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree > >>>>>>>>> that it > >>>>>> > >>>>>>>>> is a tricky issue and also support to describe the issue in=20 > >>>>>>>>> the document. However, I'd like to point out, this document=20 > >>>>>>>>> should concentrate on the protocol related issue and allow the > >>>>>>>>> flexibility to use the other discovery mechanism beyond the=20 > >>>>>>>>> Diameter protocol capability. In other words, we mainly need > >>>>>>>>> to define some mechanism based on Diameter protocol's=20 > >>>>>>>>> capability, such as the realm based routing, and leave the=20 > >>>>>>>>> door open for other advanced discovery schemes. > >>>>>>>>> > >>>>>>>>> See additional comment in line... > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Dong > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>>>> Sent: Tuesday, June 12, 2007 5:26 PM > >>>>>>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina > >>>>>>>>> TSOU; > >>>>>> > >>>>>>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > >>>>>>>>> integration of QoS application > >>>>>>>>> > >>>>>>>>> Hi, all, > >>>>>>>>> > >>>>>>>>> Please see my comments in line. > >>>>>>>>> > >>>>>>>>> Hannes Tschofenig wrote: > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> could you please take a look at the proposal by Dong? > >>>>>>>>>> > >>>>>>>>>> They are available here: > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft > >>>>>> -i > >>>>>>>>> etf-dime-diameter-qos-01-ds.txt > >>>>>>>>>> > >>>>>>>>>> The XML file is in the same directory, as usual. > >>>>>>>>>> > >>>>>>>>>> Ciao > >>>>>>>>>> Hannes > >>>>>>>>>> > >>>>>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>>>>> Hi Hannes et al, > >>>>>>>>>>> > >>>>>>>>>>> Attached is the first cut to integrate two I-Ds. The change > >>>>>>>>>>> is a minimum set based on the comments from the exploder=20 > >>>>>>>>>>> (Tina, Christian > >>>>>>>> > >>>>>>>>>>> and Tolga). There are some open issues to be done, I'd like > >>>>>>>>>>> to get > >>>>>> > >>>>>>>>>>> your comments on changes first and discuss how to proceed on > >>>>>>>>>>> those > >>>>>> > >>>>>>>>>>> open items before making any further editings. Main changes: > >>>>>>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push=20 > >>>>>>>>>>> modes > >>>>>>>>> > >>>>>>>>> In the definition of Pull mode, the following sentence > >>>>>>>>> The Authorizing Entity then installs the QoS > >>>>>>>>> authorization decision to the Network Element=20 > >>>>>>>>> initiatively. needs work. "initiatively" is not a word. > >>>>>>>>> > >>>>>>>>> [DS] ok. Any good word? Basically I don't like some words such > >>>>>>>>> as unsolicited since it is used by 3GPP for different=20 > >>>>>>>>> meaning. Maybe "directly" instead? > >>>>>>>>> > >>>>>>>>>>> 2. section 3.1/2: modify the architecture diagram to=20 > >>>>>>>>>>> separate the Authorizing Entity from AS (further alignment > >>>>>>>>>>> is needed in the context); and add new subsections to=20 > >>>>>>>>>>> addressing the endpoint features > >>>>>>>>> > >>>>>>>>>>> and push/pull modes. > >>>>>>>>> > >>>>>>>>> Breaking up the AS and AE implies that there will be another > >>>>>>>>> interface > >>>>>>>> > >>>>>>>>> yet to be defined. I would rather not open up this=20 > >>>>>>>>> possibility. The > >>>>>>> > >>>>>>>>> Diameter QoS application should be usable all the way from=20 > >>>>>>>>> network element to application server, perhaps passing through > >>>>>>>>> an arbitrary number of proxies that enforce their own=20 > >>>>>>>>> policies, but there should be > >>>>>>>> > >>>>>>>>> 1 interface not 2. Also, it is important to note that the AS > >>>>>>>>> need not > >>>>>>>> > >>>>>>>>> be present at all in some > >>>>>>>>> scenarios: for example, when authorizing requests from a=20 > >>>>>>>>> static subscriber database. > >>>>>>>>> > >>>>>>>>> [DS] First of all, I don't intend to standardize the interface > >>>>>>>>> between > >>>>>>>> > >>>>>>>>> AS and AE in this application. Second, I am not sure why the > >>>>>>>>> separate > >>>>>>> > >>>>>>>>> of AS and AE prevents the AE access to a static subscriber=20 > >>>>>>>>> database. The basic rationale is address as aforementioned. > >>>>>>>>> > >>>>>>>>>>> 3. section 3.3: minor revision on the models for pull;=20 > >>>>>>>>>>> rewrite the > >>>>>> > >>>>>>>>>>> push model (Tina, pls take a look) > >>>>>>>>> > >>>>>>>>> 3.2 looks new. It seems to be overly weighted in favor of the > >>>>>>>>> push model. I would like to point out that there is a big=20 > >>>>>>>>> discovery problem with the push model, especially when the AE > >>>>>>>>> and NE are in different administrative domains. The push=20 > >>>>>>>>> model is only applicable > >>>>>> > >>>>>>>>> to the case where the AE and the NE are in the same=20 > >>>>>>>>> administrative domain and therefore it is a special case. > >>>>>>>>> > >>>>>>>>> [DS] I think in reality the operators mainly look at the=20 > >>>>>>>>> intra-domain > >>>>>>> > >>>>>>>>> policy enforcement interface, whatever pull or push models. I > >>>>>>>>> am not > >>>>>> > >>>>>>>>> in favor of any specific models, just analyze the impact of=20 > >>>>>>>>> endpoint's > >>>>>>>> > >>>>>>>>> capability. If you have any words that can enhance the pull=20 > >>>>>>>>> model, it > >>>>>>> > >>>>>>>>> is very welcome :-). > >>>>>>>>> > >>>>>>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from=20 > >>>>>>>>>>> section > >>>>>>>>>>> 7.4 and > >>>>>>>>> > >>>>>>>>>>> table. But the name still remains in some texts. > >>>>>>>>>>> > >>>>>>>>>>> To be done: > >>>>>>>>>>> 1. state mechanism for Push mode: server initiated policy=20 > >>>>>>>>>>> installation 2. should section 4.4 be merged with section > >>>>>>>>>>> 4.2 since > >>>>>>> > >>>>>>>>>>> both them discuss how to initiate a new Diameter session? In > >>>>>>>>>>> addition, the text needs to be beefed up for server=20 > >>>>>>>>>>> initiated session. > >>>>>>>>>>> 3. authorization schemes/models for Pull: inter-domain=20 > >>>>>>>>>>> authorization > >>>>>>>> > >>>>>>>>>>> between authorizing entity and NE is not envisaged as the=20 > >>>>>>>>>>> basic model, should be revised in the context; Token based > >>>>>>>>>>> approach is not > >>>>>>>> > >>>>>>>>>>> the main trend, should be shortened. > >>>>>>>>> > >>>>>>>>> We need to have inter-domain authorization as the basic=20 > >>>>>>>>> scenario; local authorization should be treated as a special > >>>>>>>>> case. The whole point is to leverage the inter-domain=20 > >>>>>>>>> capability of Diameter to mediate between network elements and > >>>>>>>>> authorizing entities, whether the AEs are application servers > >>>>>>>>> or static subscriber databases. > >>>>>>>>> > >>>>>>>>> [DS] I agree that inter-domain authorization/policy=20 > >>>>>>>>> communication is > >>>>>> > >>>>>>>>> important, but the mechanism and scope of this document is=20 > >>>>>>>>> inappropriate to solve that issue, since it is not the right > >>>>>>>>> way forward envisioned by the industry and operators. > >>>>>>>>> > >>>>>>>>> If we only solve the local case it will mean that an=20 > >>>>>>>>> application server has to be co-located in the local domain. > >>>>>>>>> This is not the way > >>>>>>> > >>>>>>>>> the Internet is supposed to work: services should be=20 > >>>>>>>>> deployable end-to-end, without modifying elements of the=20 > >>>>>>>>> network along the path. It should be possible for the=20 > >>>>>>>>> application server to be located > >>>>>> > >>>>>>>>> anywhere in the network and the AAA part should just work. > >>>>>>>>> > >>>>>>>>> [DS] as I said, the AS and AE can be in different domains. On > >>>>>>>>> the other hand, if we integrate the AS with AE together, it=20 > >>>>>>>>> impose a tight > >>>>>>>> > >>>>>>>>> coupled service model, i.e. AS and AE always have to be in the > >>>>>>>>> same domain. Exactly the issue you are concerned. > >>>>>>>>> > >>>>>>>>>>> 4. The current doc mainly talks about the QoS, should add=20 > >>>>>>>>>>> some tint > >>>>>>> > >>>>>>>>>>> on the policy control side. > >>>>>>>>>>> > >>>>>>>>>>> Please let me know your opinion and how to proceed. > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Dong > >>>>>>>>> > >>>>>>>>> -Pete > >>>> > >>>> > >>>> _______________________________________________ > >>>> DiME mailing list > >>>> DiME@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 20 03:22:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uWV-0000Pq-Qr; Wed, 20 Jun 2007 03:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uWU-0000Pg-5g for dime@ietf.org; Wed, 20 Jun 2007 03:22:38 -0400 Received: from hu-out-0506.google.com ([72.14.214.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0uWS-0004fq-Rv for dime@ietf.org; Wed, 20 Jun 2007 03:22:38 -0400 Received: by hu-out-0506.google.com with SMTP id 31so76206huc for ; Wed, 20 Jun 2007 00:22:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=GB0SbTDmhqByeKIkyqTrHHYBYlobAL+IMcWu4kvVY/587T9MrF4UeXKCP1AwvoYpaLdoR9yAZIIRcXSTrKRqa7CJHv5pmKFPdZQFaCuzdqtqlkQcu3vtAKJoE9H2ziTBO4WdyXqnQscqxPe/6KIFeM+MTrWIdGBtcw7PtyxXCyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JABtsNRqLLDRLkXBqjziMcbn+oezZgSQEvZR0vU9PQ5anWrFW/+lUVOd8rZ41wYfj5v2hfScElhb8p/mMLrxYWOQPJER3/MfaRW41dX+1SwU/ecmaDkiDtGgeTvAT20JTrXoEjyVdHeypAAi4C4vDCqveMjjBAdcKMx6b1X/Ehc= Received: by 10.82.160.2 with SMTP id i2mr815768bue.1182324155717; Wed, 20 Jun 2007 00:22:35 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Wed, 20 Jun 2007 00:22:35 -0700 (PDT) Message-ID: Date: Wed, 20 Jun 2007 12:52:35 +0530 From: "harish raghuveer" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Dime] group avp length encoding X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1683188838==" Errors-To: dime-bounces@ietf.org --===============1683188838== Content-Type: multipart/alternative; boundary="----=_Part_119701_26710111.1182324155696" ------=_Part_119701_26710111.1182324155696 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In the page number 56 the grouped avp seem to have a length of 468. Could someone please explain how this value is obtained? If we consider the total encoded length of all the sub-avps (including padding - 19+50+51+223+137+8 padding bytes + 8 bytes header) it comes to 496. If we exclude the header lengths in the excluded AVPs from the total encoded length, it should be 496 - (5 * 8) = 456 bytes. What am I missing? thanks, Harish ------=_Part_119701_26710111.1182324155696 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In the page number 56 the grouped avp seem to have a length of 468. Could someone please explain how this value is obtained? If we consider the total encoded length of all the sub-avps (including padding - 19+50+51+223+137+8 padding bytes + 8 bytes header) it comes to 496.  If we exclude the header lengths in the excluded AVPs from the total encoded length, it should be 496 - (5 * 8) = 456 bytes. What am I missing?

thanks,
Harish
------=_Part_119701_26710111.1182324155696-- --===============1683188838== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1683188838==-- From dime-bounces@ietf.org Wed Jun 20 04:43:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vmw-0004NC-3Q; Wed, 20 Jun 2007 04:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vmv-0004Ly-4j for dime@ietf.org; Wed, 20 Jun 2007 04:43:41 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0vmt-0001rA-Bm for dime@ietf.org; Wed, 20 Jun 2007 04:43:41 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJX00MFDEVD4Y@szxga01-in.huawei.com> for dime@ietf.org; Wed, 20 Jun 2007 16:42:49 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJX004AEEVBK4@szxga01-in.huawei.com> for dime@ietf.org; Wed, 20 Jun 2007 16:42:49 +0800 (CST) Received: from huawei1515 ([10.18.4.137]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJX00060EV769@szxml04-in.huawei.com> for dime@ietf.org; Wed, 20 Jun 2007 16:42:47 +0800 (CST) Date: Wed, 20 Jun 2007 14:12:42 +0530 From: Rajith R Subject: RE: [Dime] group avp length encoding In-reply-to: To: 'harish raghuveer' , dime@ietf.org Message-id: <009f01c7b316$f81de670$8904120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcezC87dpjkXbxZQTA6CuGMZf3RNuAACoXsQ X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1546336701==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1546336701== Content-type: multipart/alternative; boundary="Boundary_(ID_aAP5c+udUHz8VO1F7LWgXw)" This is a multi-part message in MIME format. --Boundary_(ID_aAP5c+udUHz8VO1F7LWgXw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT For the given example of group AVP with the 5 sub AVPs, the length must be 496. The offset of some sub-AVPs must also be changed accordingly. _____ From: harish raghuveer [mailto:harish.r.prabhu@gmail.com] Sent: Wednesday, June 20, 2007 12:53 PM To: dime@ietf.org Subject: [Dime] group avp length encoding Hello, I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In the page number 56 the grouped avp seem to have a length of 468. Could someone please explain how this value is obtained? If we consider the total encoded length of all the sub-avps (including padding - 19+50+51+223+137+8 padding bytes + 8 bytes header) it comes to 496. If we exclude the header lengths in the excluded AVPs from the total encoded length, it should be 496 - (5 * 8) = 456 bytes. What am I missing? thanks, Harish --Boundary_(ID_aAP5c+udUHz8VO1F7LWgXw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
For the given example of group AVP with the 5 sub AVPs, the length must be 496. The offset of some sub-AVPs must also be changed accordingly.
 
 

From: harish raghuveer [mailto:harish.r.prabhu@gmail.com]
Sent: Wednesday, June 20, 2007 12:53 PM
To: dime@ietf.org
Subject: [Dime] group avp length encoding

Hello,

I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In the page number 56 the grouped avp seem to have a length of 468. Could someone please explain how this value is obtained? If we consider the total encoded length of all the sub-avps (including padding - 19+50+51+223+137+8 padding bytes + 8 bytes header) it comes to 496.  If we exclude the header lengths in the excluded AVPs from the total encoded length, it should be 496 - (5 * 8) = 456 bytes. What am I missing?

thanks,
Harish
--Boundary_(ID_aAP5c+udUHz8VO1F7LWgXw)-- --===============1546336701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1546336701==-- From dime-bounces@ietf.org Wed Jun 20 05:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0w7b-0008M7-J9; Wed, 20 Jun 2007 05:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0w7a-0008Lz-9u for dime@ietf.org; Wed, 20 Jun 2007 05:05:02 -0400 Received: from hu-out-0506.google.com ([72.14.214.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0w7Y-0004rp-Qf for dime@ietf.org; Wed, 20 Jun 2007 05:05:02 -0400 Received: by hu-out-0506.google.com with SMTP id 31so95339huc for ; Wed, 20 Jun 2007 02:05:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=kLQ4jm1+YM8zyVmjNaDByD+UcaoC7I2oHvm4x2YOEohHu0khDNc2TWshB/m6GqSUuXq/nXUshG4noNVMSeYiDDjZkNjeD29Ppz4AHKPG01U3LWQxLhA+/8a778Z2jbZkV7K08CCoQ74f5Cn6HEl3zEBFKhkNToiqziMmqR6g++8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NL5X/XE54a6CZxjEui1n+1R0T+oZs8OFq/wPI6+s8QyIlD9uSGAqBlcWCAsgMRTpa61SNgt2jef8Tkpr4hzYSY67rSkmdJI6+YRS2oJ/xfX6hCpW5f9P6TggzjqLqEXlfgpcFDUuVABKD85l5sDyXlLmMJFFbrZHMtguNdh5i8s= Received: by 10.82.183.19 with SMTP id g19mr1004578buf.1182330299789; Wed, 20 Jun 2007 02:04:59 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Wed, 20 Jun 2007 02:04:59 -0700 (PDT) Message-ID: Date: Wed, 20 Jun 2007 14:34:59 +0530 From: "harish raghuveer" To: rajithr@huawei.com Subject: Re: [Dime] group avp length encoding In-Reply-To: <009f01c7b316$f81de670$8904120a@china.huawei.com> MIME-Version: 1.0 References: <009f01c7b316$f81de670$8904120a@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1658042799==" Errors-To: dime-bounces@ietf.org --===============1658042799== Content-Type: multipart/alternative; boundary="----=_Part_120666_29579512.1182330299718" ------=_Part_120666_29579512.1182330299718 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for the clarification, Rajith. The padding seems to be OK in the example as I can see that they are all 32-bit aligned. cheers, Harish On 6/20/07, Rajith R wrote: > > For the given example of group AVP with the 5 sub AVPs, the length must > be 496. The offset of some sub-AVPs must also be changed accordingly. > > > > ------------------------------ > *From:* harish raghuveer [mailto:harish.r.prabhu@gmail.com] > *Sent:* Wednesday, June 20, 2007 12:53 PM > *To:* dime@ietf.org > *Subject:* [Dime] group avp length encoding > > Hello, > > I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In the page number > 56 the grouped avp seem to have a length of 468. Could someone please > explain how this value is obtained? If we consider the total encoded length > of all the sub-avps (including padding - 19+50+51+223+137+8 padding bytes + > 8 bytes header) it comes to 496. If we exclude the header lengths in the > excluded AVPs from the total encoded length, it should be 496 - (5 * 8) = > 456 bytes. What am I missing? > > thanks, > Harish > > -- Harish R Prabhu Ph:98457-34737 (M) ------=_Part_120666_29579512.1182330299718 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for the clarification, Rajith. The padding seems to be OK in the example as I can see that they are all 32-bit aligned.

cheers,
Harish

On 6/20/07, Rajith R <rajithr@huawei.com> wrote:
For the given example of group AVP with the 5 sub AVPs, the length must be 496. The offset of some sub-AVPs must also be changed accordingly.
 
 

From: harish raghuveer [mailto:harish.r.prabhu@gmail.com]
Sent: Wednesday, June 20, 2007 12:53 PM
To: dime@ietf.org
Subject: [Dime] group avp length encoding

Hello,

I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In the page number 56 the grouped avp seem to have a length of 468. Could someone please explain how this value is obtained? If we consider the total encoded length of all the sub-avps (including padding - 19+50+51+223+137+8 padding bytes + 8 bytes header) it comes to 496.  If we exclude the header lengths in the excluded AVPs from the total encoded length, it should be 496 - (5 * 8) = 456 bytes. What am I missing?

thanks,
Harish



--
Harish R Prabhu
Ph:98457-34737 (M) ------=_Part_120666_29579512.1182330299718-- --===============1658042799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1658042799==-- From dime-bounces@ietf.org Wed Jun 20 05:11:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wDi-0005Dh-7A; Wed, 20 Jun 2007 05:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wDg-0005DT-TF for dime@ietf.org; Wed, 20 Jun 2007 05:11:20 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0wDZ-0007Gl-PS for dime@ietf.org; Wed, 20 Jun 2007 05:11:20 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJX00HY9G5G98@szxga03-in.huawei.com> for dime@ietf.org; Wed, 20 Jun 2007 17:10:28 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJX00CW6G5FSF@szxga03-in.huawei.com> for dime@ietf.org; Wed, 20 Jun 2007 17:10:28 +0800 (CST) Received: from huawei1515 ([10.18.4.137]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJX00JY7G5B83@szxml03-in.huawei.com> for dime@ietf.org; Wed, 20 Jun 2007 17:10:27 +0800 (CST) Date: Wed, 20 Jun 2007 14:40:23 +0530 From: Rajith R Subject: RE: [Dime] group avp length encoding In-reply-to: To: 'harish raghuveer' Message-id: <00ad01c7b31a$d5f05ed0$8904120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcezGheczovBx7mjS+GExIOt4BgJyQAACRMw X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0121215527==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0121215527== Content-type: multipart/alternative; boundary="Boundary_(ID_duCMyaHbBeD8+2J9mY4tDw)" This is a multi-part message in MIME format. --Boundary_(ID_duCMyaHbBeD8+2J9mY4tDw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT the padding is certainly ok, I am talking about the offset, for eg: the 2nd session Id avp (of length 51) starts at byte offset of '72', actually it should start at '80' & so on ... _____ From: harish raghuveer [mailto:harish.r.prabhu@gmail.com] Sent: Wednesday, June 20, 2007 2:35 PM To: rajithr@huawei.com Cc: dime@ietf.org Subject: Re: [Dime] group avp length encoding Thanks for the clarification, Rajith. The padding seems to be OK in the example as I can see that they are all 32-bit aligned. cheers, Harish On 6/20/07, Rajith R wrote: For the given example of group AVP with the 5 sub AVPs, the length must be 496. The offset of some sub-AVPs must also be changed accordingly. _____ From: harish raghuveer [mailto:harish.r.prabhu@gmail.com] Sent: Wednesday, June 20, 2007 12:53 PM To: dime@ietf.org Subject: [Dime] group avp length encoding Hello, I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In the page number 56 the grouped avp seem to have a length of 468. Could someone please explain how this value is obtained? If we consider the total encoded length of all the sub-avps (including padding - 19+50+51+223+137+8 padding bytes + 8 bytes header) it comes to 496. If we exclude the header lengths in the excluded AVPs from the total encoded length, it should be 496 - (5 * 8) = 456 bytes. What am I missing? thanks, Harish -- Harish R Prabhu Ph:98457-34737 (M) --Boundary_(ID_duCMyaHbBeD8+2J9mY4tDw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
the padding is certainly ok, I am talking about the offset, for eg: the 2nd session Id avp (of length 51) starts at byte offset of '72', actually it should start at '80' & so on ...
From: harish raghuveer [mailto:harish.r.prabhu@gmail.com]
Sent: Wednesday, June 20, 2007 2:35 PM
To: rajithr@huawei.com
Cc: dime@ietf.org
Subject: Re: [Dime] group avp length encoding

Thanks for the clarification, Rajith. The padding seems to be OK in the example as I can see that they are all 32-bit aligned.

cheers,
Harish

On 6/20/07, Rajith R <rajithr@huawei.com> wrote:
For the given example of group AVP with the 5 sub AVPs, the length must be 496. The offset of some sub-AVPs must also be changed accordingly.
 
 

From: harish raghuveer [mailto:harish.r.prabhu@gmail.com]
Sent: Wednesday, June 20, 2007 12:53 PM
To: dime@ietf.org
Subject: [Dime] group avp length encoding

Hello,

I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In the page number 56 the grouped avp seem to have a length of 468. Could someone please explain how this value is obtained? If we consider the total encoded length of all the sub-avps (including padding - 19+50+51+223+137+8 padding bytes + 8 bytes header) it comes to 496.  If we exclude the header lengths in the excluded AVPs from the total encoded length, it should be 496 - (5 * 8) = 456 bytes. What am I missing?

thanks,
Harish



--
Harish R Prabhu
Ph:98457-34737 (M)
--Boundary_(ID_duCMyaHbBeD8+2J9mY4tDw)-- --===============0121215527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0121215527==-- From dime-bounces@ietf.org Wed Jun 20 08:08:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0yyq-0003dI-Mv; Wed, 20 Jun 2007 08:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0yyp-0003d6-Tx for dime@ietf.org; Wed, 20 Jun 2007 08:08:11 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0yym-00060X-V8 for dime@ietf.org; Wed, 20 Jun 2007 08:08:11 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l5KC88Xb032284 for ; Wed, 20 Jun 2007 08:08:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Date: Wed, 20 Jun 2007 08:08:08 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7187FBE@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D520936@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: FW: First draft on the integration of QoS application Thread-Index: AceutWPOQbUxj1/bQ4Krh8NNWpduIwD1l7dwAAzQYPAAG+4SIA== References: <9b0e41640706141150i640dd29cy89ad225881907627@mail.gmail.com><9b0e41640706141153g677d33e7o6ddb3f53da606939@mail.gmail.com> <09C9068466B79E4C938DC7737562404D520936@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 20c6ed26ee4f226a67d90641b17dfc32 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Dong, I personally don't see any conceptual difference between interdomain and intradomain requests regarding Diameter QoS. Both interfaces are used to communicate the desire to reserve QoS with characteristics as described by the AVPs in the corresponding messages. The rest is probably dependent on policy, e.g. how interdomain requests are handled v.s. intradomain requests.=20 IMHO, authorization can be treated as an integral part of QoS reservation. It could be optionally omitted depending on the business model. Probably, from QoS application point of view, the impact would be to have an AVP identifying the user/subscriber in the message. IMHO, the rest (whether and how the value in this AVP is used by the server/proxy etc..., e.g. consulting an external database) is implementation dependent. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, June 19, 2007 6:27 PM > To: McCann Peter-A001034; Christian Esteve; dime@ietf.org > Subject: RE: [Dime] Re: FW: First draft on the integration of QoS > application >=20 > Pete, et al, >=20 > Although I have no objection to define the inter-domain interface, it > seems to me the Rx in 3GPP does not fit well with the modeling defined > in QoS application: > - Rx is defined between Application Function and Policy Decision > function (i.e. part of Authorizing entity in QoS application) > - QoS application concerns the control of policy enforcement, the > interface between authorizing entity and Network element, which is the > Gx in 3GPP term. >=20 > If we really like to cover both inter-domain and intra-domain scenarios > in the single QoS application, I think it should be a Gx-like interface. > In the inter-domain case, the Gx-like interface will be used between > home PCRF and visited PCRF as well; besides it can be used between PCRF > and PCEF for intra-domain case. >=20 > In addition, I think we should allow the flexibility to have Application > Server separated from the Authorizing entity (but not mandatory), and > maybe no need to standardize that interface between AS and Authorizing > entity in this QoS application. >=20 > If you agree on this proposal, I'd like to edit the latest draft I sent > out to reflect this notion. >=20 > Dong >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, June 19, 2007 12:14 PM > To: Christian Esteve; dime@ietf.org > Subject: RE: [Dime] Re: FW: First draft on the integration of QoS > application >=20 > Hi, Christian, >=20 > Thanks for your comments, I would certainly like to take a look at your > paper. >=20 > I suppose I could be convinced that local policy should be taken care of > with a separate interface, but I think it's important that IETF > standardize the inter-domain case as a first priority. > The local interface is less important to standardize now, because it > could easily be taken care of with a proprietary interface based on > purchasing decisions made by the operator, or it could easily be > incorporated in to the Network Element itself. One of my goals for the > diameter-qos draft has been to facilitate the inter-working of disparate > application functions in different networks, and I think that should be > the focus of this draft. >=20 > If we really want to add a new local PDP element to the draft I would be > ok with a modified Figure 1 that shows this. However, the Diameter > cloud would then need to be shown between that entity and the > application server, and the document should focus on this latter > interface. In other words, we should be standardizing Rx now. >=20 > -Pete >=20 > Christian Esteve wrote: > > Hi folks, > > > > the discussion thread reflects once again the confrontation between > > the operator SDO and the IETF worlds, and as it usually happens, > > disagreements are not only motivated by network engineering issues > > but by scope and nomenclature divergences. > > > >>> I guess I don't see why we need two separate interfaces. They are > >>> each transporting roughly the same information and doing the same > >>> sort of job. > > > > It is true that the job and type of infomation are similar, however > > the separation of the interfaces makes sense to me. While one > > interface is used only to request QoS, the other is expected to carry > > and install QoS policy information (with different QoS descriptors). > > > > The AF-PDP-PEP model (also referred to as AS-AE-NE) reflects the > > architecture evolution of the SDOs that introduce policy-based > > resource control functions. > > > > It has been said that: > >>>>> There may be proxies in the > >>>>> Diameter cloud that enforce their own policy decisions, some of > >>>>> which will be local to the Network Element's administrative > >>>>> domain. > > > > To my understanding that is why the separated interfaces make sense. > > > > An intermediate PDP (also referred to as PDF) may enforce further > > policies (network type specific, user profile related, > > operator-based) in conjunction with other network elements (resource > > information, user database). > > > > Furthermore, the QoS description over the AF-PDP interface is likely > > to differ from the QoS information describing the policy to be > > instaslled in the NE, harmonizing and easing AF QoS requests and > > enabling the QoS policy installation mechanism to evolve separately > > in accordance to the transport network specifics. > > > > The PDP would certainly have an inter-domain interface to AFs and > > other inter- an intra PDPs. I bnelieve that the Diameter QoS > > application running between the AF and the PDP could be defined in a > > way that it could be applied for the inter-domain PDP-PDP peering > > interface. > > > > Unfortunately my contribution to the discussion at this point is not > > enriching the discussion regarding the implications to the Diameter > > functionality (e.g. command and AVPs, realm routing, discovery > > schemes, etc.). > > > > However, I am sharing under > > http://www.dca.fee.unicamp.br/~pasquini/dime-qos-app/ > > some figures depicting the abstracted SDOs architectures that could > > help in the following discussions around the Diameter QoS application. > > The figures have been extracted > > from the the paper "A review on policy-based resource and admission > > control functions in evolving access and next generation networks", > > recently accepted for publication (draft copy can be provided if > > interested). > > > > > > Best regards, > > Christian > >> > >> > >>> ------------------------------ > >>> > >>> Message: 5 > >>> Date: Wed, 13 Jun 2007 18:08:21 -0400 > >>> From: "McCann Peter-A001034" > >>> Subject: [Dime] FW: First draft on the integration of QoS > >>> application > >>> To: > >>> Message-ID: > >>> > >>> > >>> Content-Type: text/plain; charset=3D"us-ascii" > >>> > >>> Below is a discussion thread that has been taking place among > >>> authors of the diameter-qos draft. We thought it important that the >=20 > >>> mailing list have some visibility to the discussion. Comments > >>> welcome. > >>> > >>> -Pete > >>> > >>> McCann Peter-A001034 wrote: > >>>> Hi, Dong, > >>>> > >>>> I guess I don't see why we need two separate interfaces. They are > >>>> each transporting roughly the same information and doing the same > >>>> sort of job. > >>>> > >>>> The current document in my mind has always been an inter-domain > >>>> interface. See the abstract: > >>>> > >>>> ...Clients that implement the Diameter QoS application contact an > >>>> authorizing entity/application server that is located somewhere > >>>> in the network, allowing for a wide variety of flexible > >>>> deployment models. > >>>> > >>>> And the following text in Section 3.2: > >>>> > >>>> Inter-domain support > >>>> > >>>> In particular, users may roam outside their home network, > >>>> leading to a situation where the network element and > >>>> authorizing entity are in different administrative domains. > >>>> > >>>> -Pete > >>>> > >>>> Sun, Dong (Dong) wrote: > >>>>> Hi Pete, > >>>>> I have no doubt about the importance of inter-domain policy > >>>>> communications, and it might be better to use the Diameter broker > >>>>> instead of SIP proxy to deal with inter-domain resource > >>>>> management. > >>>>> In fact, I think 3GPP does use the similar model as you described, >=20 > >>>>> that a Diameter broker (client) is embedded in the AF (e.g. > >>>>> P-CSCF), and the interface between AF and underlying Policy engine >=20 > >>>>> (e.g. PCRF) is an inter-domain interface per se. > >>>>> certainly, since they (SIP and Diameter brokers) are grouped > >>>>> together, it is less flexible and scalable for the implementation. > >>>>> > >>>>> However, I think this interface (named as Rx in 3GPP, Gq' in > >>>>> TISPAN, Rs in ITU) is not for the control of policy enforcement > >>>>> directly. In my view, this interface (Rx) is a peering interface > >>>>> between policy servers rather than between policy server and > >>>>> enforcement point as described in the current QoS application, and >=20 > >>>>> I believe it is more appropriate to model the inter-domain > >>>>> interface as the policy server to policy server (PDF-PDF) peering > >>>>> interface. > >>>>> > >>>>> I have no problem to develop a doc to address this inter-domain > >>>>> application, however, if you look around the current document, I > >>>>> did not see any indication from that perspective. > >>>>> > >>>>> Dong > >>>>> > >>>>> -----Original Message----- > >>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>> Sent: Wednesday, June 13, 2007 2:11 PM > >>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>> TSOU; Avri Doria Cc: Victor Fajardo > >>>>> Subject: RE: First draft on the integration of QoS application > >>>>> > >>>>> Hi, Dong, > >>>>> > >>>>> Sun, Dong (Dong) wrote: > >>>>>> Hi Pete, > >>>>>> > >>>>>> Thanks for clarification. Just wondering if you can give an > >>>>>> example who will use the "inter-domain" model for policy > >>>>>> enforcement control, i.e. PDP and PEP reside in the different > >>>>>> operator's administrative domains. Since the inter-domain is to > >>>>>> serve for the operator's domain, I don't know how to create an > >>>>>> application without considering their need. (BTW, I have no > >>>>>> strong view to limit it to intra-domain only if the use case can > >>>>>> be identified). > >>>>> > >>>>> Arbitrary third parties should be allowed to deploy application > >>>>> servers and interface to the Diameter cloud to get QoS from the > >>>>> network. The Diameter QoS Application should play this role. > >>>>> In the extreme case, I should be allowed to put a SIP server in my >=20 > >>>>> basement, sign up with a Diameter broker, and run my application > >>>>> end-to-end. > >>>>> > >>>>>> I agree that this application should support "a generic mediator > >>>>>> that can handle many applications". However, Given the integrated >=20 > >>>>>> AS and AE, it makes the AE has to be collocated with the > >>>>>> application content providers rather than the network itself, I > >>>>>> feel it is also too limited and not the common case in reality. > >>>>>> (As far as I know, all deployed or emerging network > >>>>>> infrastructures such as 3GPP/PP2, WiMAX, TISPAN/ITU do not view > >>>>>> this solution as the main trend). I am wondering who will use > >>>>>> this application eventually. > >>>>> > >>>>> I am not ruling out a PDP in the network local to the PEP. I am > >>>>> just saying that this PDP should be viewed as a Diameter proxy on > >>>>> the path to the Authorizing Entity, which itself may be either a > >>>>> static subscriber database or an active application server. > >>>>> I don't want to work only on the localized protocol, I want to > >>>>> define the inter-domain one. If you insist on separating the AE > >>>>> from the AS then I would say that the important Diameter interface >=20 > >>>>> is the one between AE and AS. It is much more important to > >>>>> standardize the inter-domain interface because this is the one > >>>>> that will be used between operators. > >>>>> > >>>>> I am aware of work in 3GPP/PP2/TISPAN/ITU etc and I think they are >=20 > >>>>> going down the path of using SIP proxies as the inter-domain > >>>>> interface. I think this architecture is bad for the Internet, and >=20 > >>>>> will limit the kinds of applications that can be deployed. > >>>>> The Internet model is that applications should be deployable > >>>>> without modifying the middleboxes. Tying SIP servers to the > >>>>> network traffic path also doesn't work well with Mobile IP. > >>>>> > >>>>>> In addition, the scalable roaming agreements sound like a general >=20 > >>>>>> algorithm that may be applicable for any inter-domain issue in > >>>>>> the context of Diameter applications, or it is only the fundament >=20 > >>>>>> to this application? > >>>>> > >>>>> The Diameter NASREQ application (similar to the basic RADIUS > >>>>> protocol) has always been about inter-domain operation. Diameter > >>>>> is used as the mediating protocol between different operator > >>>>> domains. I think we should be following the same model with the > >>>>> Diameter QoS application. > >>>>> > >>>>> -Pete > >>>>> > >>>>>> Dong > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>> Sent: Wednesday, June 13, 2007 11:06 AM > >>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>> the integration of QoS application > >>>>>> > >>>>>> Hi, Dong, > >>>>>> > >>>>>> An "Autonomous System" has a very specific meaning in the context >=20 > >>>>>> of routing protocols; I would not want to say that they > >>>>>> correspond one-to-one with the "domains" that exist when I talk > >>>>>> about "inter-domain" in the context of diameter-qos. I would say >=20 > >>>>>> that "operator's administrative domain" is a better term. > >>>>>> > >>>>>> In any case, I think that the Diameter cloud from the figure 1 > >>>>>> should be a generic inter-domain mediator that can handle many > >>>>>> applications, of which Diameter QoS is one. The scalable roaming >=20 > >>>>>> agreements embodied in this cloud should allow the Authorizing > >>>>>> Entity to be anywhere in the network. There may be proxies in > >>>>>> the Diameter cloud that enforce their own policy decisions, some > >>>>>> of which will be local to the Network Element's administrative > >>>>>> domain. However, that should not impact the specification of the > >>>>>> Diameter QoS Application. This inter-domain operation has been at >=20 > >>>>>> the core of the document since I started it: see Section 3.2 in > >>>>>> the -00 version. > >>>>>> > >>>>>> -Pete > >>>>>> > >>>>>> Sun, Dong (Dong) wrote: > >>>>>>> Hi Pete, > >>>>>>> > >>>>>>> Before making any conclusion, I'd like to clarify some terms: > >>>>>>> Since you mentioned this is IETF, Internet and such, the domain > >>>>>>> you refer to is in the context of the "Autonomous System" or > >>>>>>> "operator's administrative domain". > >>>>>>> > >>>>>>> Dong > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>> Sent: Wednesday, June 13, 2007 10:27 AM > >>>>>>> To: Sun, Dong (Dong); Hannes Tschofenig; Glen Zorn (gwz); Tina > >>>>>>> TSOU; Avri Doria Cc: Victor Fajardo Subject: RE: First draft on > >>>>>>> the integration of QoS application > >>>>>>> > >>>>>>> Hi, Dong, > >>>>>>> > >>>>>>> I think you and I have a fundamental disagreement on the scope > >>>>>>> and purpose of this document. I really don't see the need to > >>>>>>> standardize > >>>>> > >>>>>>> an intra-domain localized solution to the problem. This is IETF >=20 > >>>>>>> we should be solving the problem for the whole Internet, which > >>>>>>> means inter-domain is the target. I understand that some > >>>>>>> operators might not want to open their networks, but we should > >>>>>>> not be defining standards for these closed architectures. > >>>>>>> > >>>>>>> I also feel strongly that we should have adequate discovery > >>>>>>> mechanisms > >>>>>> > >>>>>>> for all modes of operation specified in this document; otherwise >=20 > >>>>>>> it could lead to inter-operability problems. > >>>>>>> > >>>>>>> Hannes, I would like to note this as a serious issue that should >=20 > >>>>>>> be resolved before we proceed any further. I would like to > >>>>>>> check with the mailing list and the ADs on their preferences. > >>>>>>> What do you think > >>>>> > >>>>>>> would be the appropriate way to introduce the issue? Would you > >>>>>>> like to introduce the question to the mailing list? > >>>>>>> > >>>>>>> -Pete > >>>>>>> > >>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>> Hi Pete, > >>>>>>>> > >>>>>>>> First of all, Thanks for the review and comments. > >>>>>>>> > >>>>>>>> 1. Concerning the split of Application Server and Authorizing > >>>>>>>> Entity, > >>>>>> > >>>>>>>> which is somewhat related to another main comment you brought > >>>>>>>> up i.e. the relationship between Authorizing Entity and NE - > >>>>>>>> inter-domain Vs. intra-domain, the rationale in my mind is as > >>>>>>>> follow: - In the real network (or the vision of NGN, or > >>>>>>>> somewhat the > >>>>> > >>>>>>>> net neutrality perspective), the packet (transport) network > >>>>>>>> should support > >>>>>>> > >>>>>>>> a variety of applications which may belong to different SPs > >>>>>>>> i.e. in different domain. The PDP (i.e. Authorizing entity in > >>>>>>>> the context of > >>>>> > >>>>>>>> QoS application) can act as the arbitrator to isolate the > >>>>>>>> diversity of application attributes from the speciality of > >>>>>>>> network functionality. The authorizing entity is typically part >=20 > >>>>>>>> of transport > >>>>> > >>>>>>>> network domain along with the NEs since the network operators > >>>>>>>> are commonly willing to > >>>>>>> > >>>>>>>> neither rely on the third party to control the use of their > >>>>>>>> network resources nor disclose the network details (e.g. > >>>>>>>> topology, resource usage and policies) to other carriers/SPs. > >>>>>>>> Therefore, the common case is that the interface between > >>>>>>>> Authorizing entity and NE (enforcement point) should be > >>>>>>>> intra-domain in nature. > >>>>>>>> > >>>>>>>> - On the other hand, the interface between AS and AE can be > >>>>>>>> inter-domain, which also makes the life easier concerning the > >>>>>>>> inter-domain enforcement interface. > >>>>>>>> > >>>>>>>> - The policy communications between different domains is quite > >>>>>>>> important, for example, for the roaming scenario. However, it > >>>>>>>> is outside the scope of this application if my understanding is >=20 > >>>>>>>> correct. I feel it is better to be solved through > >>>>>>>> inter-Authorizing Entity interface rather than this interface. > >>>>>>>> Certainly, the command and AVPs > >>>>>> > >>>>>>>> might be shared, but I would rather not mix them together for > >>>>>>>> the time being. > >>>>>>>> > >>>>>>>> 2. Concerning the discovery mechanism for Push mode, I agree > >>>>>>>> that it > >>>>> > >>>>>>>> is a tricky issue and also support to describe the issue in the >=20 > >>>>>>>> document. However, I'd like to point out, this document should > >>>>>>>> concentrate on the protocol related issue and allow the > >>>>>>>> flexibility to use the other discovery mechanism beyond the > >>>>>>>> Diameter protocol capability. In other words, we mainly need to >=20 > >>>>>>>> define some mechanism based on Diameter protocol's capability, > >>>>>>>> such as the realm based routing, and leave the door open for > >>>>>>>> other advanced discovery schemes. > >>>>>>>> > >>>>>>>> See additional comment in line... > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Dong > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >>>>>>>> Sent: Tuesday, June 12, 2007 5:26 PM > >>>>>>>> To: Hannes Tschofenig; Sun, Dong (Dong); Glen Zorn (gwz); Tina > >>>>>>>> TSOU; > >>>>> > >>>>>>>> Avri Doria Cc: Victor Fajardo Subject: RE: First draft on the > >>>>>>>> integration of QoS application > >>>>>>>> > >>>>>>>> Hi, all, > >>>>>>>> > >>>>>>>> Please see my comments in line. > >>>>>>>> > >>>>>>>> Hannes Tschofenig wrote: > >>>>>>>>> Hi all, > >>>>>>>>> > >>>>>>>>> could you please take a look at the proposal by Dong? > >>>>>>>>> > >>>>>>>>> They are available here: > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>> http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/dra > >>> ft > >>>>> -i > >>>>>>>> etf-dime-diameter-qos-01-ds.txt > >>>>>>>>> > >>>>>>>>> The XML file is in the same directory, as usual. > >>>>>>>>> > >>>>>>>>> Ciao > >>>>>>>>> Hannes > >>>>>>>>> > >>>>>>>>> Sun, Dong (Dong) wrote: > >>>>>>>>>> Hi Hannes et al, > >>>>>>>>>> > >>>>>>>>>> Attached is the first cut to integrate two I-Ds. The change > >>>>>>>>>> is a minimum set based on the comments from the exploder > >>>>>>>>>> (Tina, Christian > >>>>>>> > >>>>>>>>>> and Tolga). There are some open issues to be done, I'd like > >>>>>>>>>> to get > >>>>> > >>>>>>>>>> your comments on changes first and discuss how to proceed on > >>>>>>>>>> those > >>>>> > >>>>>>>>>> open items before making any further editings. Main changes: > >>>>>>>>>> 1. section 2: tuning-up of terminologies, add Pull&Push modes > >>>>>>>> > >>>>>>>> In the definition of Pull mode, the following sentence > >>>>>>>> The Authorizing Entity then installs the QoS > >>>>>>>> authorization decision to the Network Element > >>>>>>>> initiatively. needs work. "initiatively" is not a word. > >>>>>>>> > >>>>>>>> [DS] ok. Any good word? Basically I don't like some words such > >>>>>>>> as unsolicited since it is used by 3GPP for different meaning. > >>>>>>>> Maybe "directly" instead? > >>>>>>>> > >>>>>>>>>> 2. section 3.1/2: modify the architecture diagram to separate >=20 > >>>>>>>>>> the Authorizing Entity from AS (further alignment is needed > >>>>>>>>>> in the context); and add new subsections to addressing the > >>>>>>>>>> endpoint features > >>>>>>>> > >>>>>>>>>> and push/pull modes. > >>>>>>>> > >>>>>>>> Breaking up the AS and AE implies that there will be another > >>>>>>>> interface > >>>>>>> > >>>>>>>> yet to be defined. I would rather not open up this > >>>>>>>> possibility. The > >>>>>> > >>>>>>>> Diameter QoS application should be usable all the way from > >>>>>>>> network element to application server, perhaps passing through > >>>>>>>> an arbitrary number of proxies that enforce their own policies, >=20 > >>>>>>>> but there should be > >>>>>>> > >>>>>>>> 1 interface not 2. Also, it is important to note that the AS > >>>>>>>> need not > >>>>>>> > >>>>>>>> be present at all in some > >>>>>>>> scenarios: for example, when authorizing requests from a static >=20 > >>>>>>>> subscriber database. > >>>>>>>> > >>>>>>>> [DS] First of all, I don't intend to standardize the interface > >>>>>>>> between > >>>>>>> > >>>>>>>> AS and AE in this application. Second, I am not sure why the > >>>>>>>> separate > >>>>>> > >>>>>>>> of AS and AE prevents the AE access to a static subscriber > >>>>>>>> database. The basic rationale is address as aforementioned. > >>>>>>>> > >>>>>>>>>> 3. section 3.3: minor revision on the models for pull; > >>>>>>>>>> rewrite the > >>>>> > >>>>>>>>>> push model (Tina, pls take a look) > >>>>>>>> > >>>>>>>> 3.2 looks new. It seems to be overly weighted in favor of the > >>>>>>>> push model. I would like to point out that there is a big > >>>>>>>> discovery problem with the push model, especially when the AE > >>>>>>>> and NE are in different administrative domains. The push model >=20 > >>>>>>>> is only applicable > >>>>> > >>>>>>>> to the case where the AE and the NE are in the same > >>>>>>>> administrative domain and therefore it is a special case. > >>>>>>>> > >>>>>>>> [DS] I think in reality the operators mainly look at the > >>>>>>>> intra-domain > >>>>>> > >>>>>>>> policy enforcement interface, whatever pull or push models. I > >>>>>>>> am not > >>>>> > >>>>>>>> in favor of any specific models, just analyze the impact of > >>>>>>>> endpoint's > >>>>>>> > >>>>>>>> capability. If you have any words that can enhance the pull > >>>>>>>> model, it > >>>>>> > >>>>>>>> is very welcome :-). > >>>>>>>> > >>>>>>>>>> 4. section 7.4: Removal of ExtendedQoSFilterRule from section > >>>>>>>>>> 7.4 and > >>>>>>>> > >>>>>>>>>> table. But the name still remains in some texts. > >>>>>>>>>> > >>>>>>>>>> To be done: > >>>>>>>>>> 1. state mechanism for Push mode: server initiated policy > >>>>>>>>>> installation 2. should section 4.4 be merged with section > >>>>>>>>>> 4.2 since > >>>>>> > >>>>>>>>>> both them discuss how to initiate a new Diameter session? In > >>>>>>>>>> addition, the text needs to be beefed up for server initiated >=20 > >>>>>>>>>> session. > >>>>>>>>>> 3. authorization schemes/models for Pull: inter-domain > >>>>>>>>>> authorization > >>>>>>> > >>>>>>>>>> between authorizing entity and NE is not envisaged as the > >>>>>>>>>> basic model, should be revised in the context; Token based > >>>>>>>>>> approach is not > >>>>>>> > >>>>>>>>>> the main trend, should be shortened. > >>>>>>>> > >>>>>>>> We need to have inter-domain authorization as the basic > >>>>>>>> scenario; local authorization should be treated as a special > >>>>>>>> case. The whole point is to leverage the inter-domain > >>>>>>>> capability of Diameter to mediate between network elements and > >>>>>>>> authorizing entities, whether the AEs are application servers > >>>>>>>> or static subscriber databases. > >>>>>>>> > >>>>>>>> [DS] I agree that inter-domain authorization/policy > >>>>>>>> communication is > >>>>> > >>>>>>>> important, but the mechanism and scope of this document is > >>>>>>>> inappropriate to solve that issue, since it is not the right > >>>>>>>> way forward envisioned by the industry and operators. > >>>>>>>> > >>>>>>>> If we only solve the local case it will mean that an > >>>>>>>> application server has to be co-located in the local domain. > >>>>>>>> This is not the way > >>>>>> > >>>>>>>> the Internet is supposed to work: services should be deployable >=20 > >>>>>>>> end-to-end, without modifying elements of the network along the >=20 > >>>>>>>> path. It should be possible for the application server to be > >>>>>>>> located > >>>>> > >>>>>>>> anywhere in the network and the AAA part should just work. > >>>>>>>> > >>>>>>>> [DS] as I said, the AS and AE can be in different domains. On > >>>>>>>> the other hand, if we integrate the AS with AE together, it > >>>>>>>> impose a tight > >>>>>>> > >>>>>>>> coupled service model, i.e. AS and AE always have to be in the > >>>>>>>> same domain. Exactly the issue you are concerned. > >>>>>>>> > >>>>>>>>>> 4. The current doc mainly talks about the QoS, should add > >>>>>>>>>> some tint > >>>>>> > >>>>>>>>>> on the policy control side. > >>>>>>>>>> > >>>>>>>>>> Please let me know your opinion and how to proceed. > >>>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> Dong > >>>>>>>> > >>>>>>>> -Pete > >>> > >>> > >>> > >>> > >>> ------------------------------ > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > >>> End of DiME Digest, Vol 18, Issue 13 > >>> ************************************ > >>> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 20 08:32:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zLy-0000Ht-US; Wed, 20 Jun 2007 08:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zLy-0000Hn-2F for dime@ietf.org; Wed, 20 Jun 2007 08:32:06 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0zLw-00025h-F5 for dime@ietf.org; Wed, 20 Jun 2007 08:32:06 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5KCVDrR063434; Wed, 20 Jun 2007 08:31:13 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46791E11.10809@tari.toshiba.com> Date: Wed, 20 Jun 2007 08:31:13 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] group avp length encoding References: <00ad01c7b31a$d5f05ed0$8904120a@china.huawei.com> In-Reply-To: <00ad01c7b31a$d5f05ed0$8904120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Thanks for noticing. It should be updated. regards, victor > the padding is certainly ok, I am talking about the offset, for eg: > the 2nd session Id avp (of length 51) starts at byte offset of '72', > actually it should start at '80' & so on ... > > ------------------------------------------------------------------------ > *From:* harish raghuveer [mailto:harish.r.prabhu@gmail.com] > *Sent:* Wednesday, June 20, 2007 2:35 PM > *To:* rajithr@huawei.com > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] group avp length encoding > > Thanks for the clarification, Rajith. The padding seems to be OK > in the example as I can see that they are all 32-bit aligned. > > cheers, > Harish > > On 6/20/07, *Rajith R* > wrote: > > For the given example of group AVP with the 5 sub AVPs, the > length must be 496. The offset of some sub-AVPs must also be > changed accordingly. > > > > ------------------------------------------------------------------------ > *From:* harish raghuveer [mailto:harish.r.prabhu@gmail.com > ] > *Sent:* Wednesday, June 20, 2007 12:53 PM > *To:* dime@ietf.org > *Subject:* [Dime] group avp length encoding > > Hello, > > I was going thru the draft-ietf-dime-rfc3588bis-04.txt. In > the page number 56 the grouped avp seem to have a length > of 468. Could someone please explain how this value is > obtained? If we consider the total encoded length of all > the sub-avps (including padding - 19+50+51+223+137+8 > padding bytes + 8 bytes header) it comes to 496. If we > exclude the header lengths in the excluded AVPs from the > total encoded length, it should be 496 - (5 * 8) = 456 > bytes. What am I missing? > > thanks, > Harish > > > > > -- > Harish R Prabhu > Ph:98457-34737 (M) > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 20 09:29:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10FJ-0002pS-7e; Wed, 20 Jun 2007 09:29:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10FH-0002mw-G2 for dime@ietf.org; Wed, 20 Jun 2007 09:29:15 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10FG-0008NG-DQ for dime@ietf.org; Wed, 20 Jun 2007 09:29:15 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l5KDT5gX023016 for ; Wed, 20 Jun 2007 15:29:05 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter auditing - PART 1 Date: Wed, 20 Jun 2007 15:29:03 +0200 Message-ID: <33656995C5C5094A983DE84DA649A9240164172F@lulex02.ad.operax.com> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02604A2C3C7@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter auditing - PART 1 Thread-Index: Acep5dCmWImxFqp+QR20+AFV7RfBYAFXPKmwAPJ8bQA= References: <33656995C5C5094A983DE84DA649A92401590C17@lulex02.ad.operax.com> <7DBAFEC6A76F3E42817DF1EBE64CB02604A2C3C7@FTRDMEL2.rd.francetelecom.fr> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 20 Jun 2007 15:29:05 +0200 (CEST) X-Spam-Status: No, score=-152.1 required=4.7 tests=ALL_TRUSTED,BAYES_00, HTML_40_50, HTML_MESSAGE, USER_IN_BLACKLIST, USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3477/Wed Jun 20 08:47:18 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103651449==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2103651449== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B33E.F91231A3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B33E.F91231A3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lionel,=20 =20 Pls find replies below [Ulf1].=20 =20 Best regards,=20 Ulf=20 ________________________________ From: MORAND Lionel RD-CORE-ISS [mailto:lionel.morand@orange-ftgroup.com]=20 Sent: den 17 juni 2007 13:02 To: Ulf Bodin; dime@ietf.org Subject: RE: [Dime] Diameter auditing - PART 1=20 Hi Ulf, =20 Some comments below. =20 BR, =20 Lionel ________________________________ De : Ulf Bodin [mailto:Ulf.Bodin@operax.com]=20 Envoy=E9 : vendredi 8 juin 2007 17:58 =C0 : dime@ietf.org Objet : [Dime] Diameter auditing - PART 1=20 =09 =09 All,=20 I've been looking in whether the original work on Diameter resource management extensions now captured in http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-02.tx t [RM-ext] would meet the demands identified in http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-01 .txt [SR] on Diameter state recovery considerations. Comments on this analyze are very wellcome.=20 Going through section 5.2.1 and 5.2.2 (PART 1) of [SR] and matching against [RM-ext] I noted the following (remaing sections/PARTs in following mail):=20 1) Having a standby node informing remote peers of the failure of an active instance (i.e. 5.2.1 in [SR]) is not covered by [RM-ext], not in any other spec (as far as I know). I'm not sure what kind of message would be appropriate for this purpose (i.e. a new mesage or an existing one such as CER). Any views on this?=20 [Lionel Morand] CER/CEA are used to initiate a transport connection between diameter peers. In this specific case, we may assume that the Standby node may actually also indicate the active instance failure by sending a CER to the remote peers. The transport connection establishment would be a hint for the remote peers to detect that the Standby node is now active and that therefore the previous active node is down. The only problem is that CER/CAA messages can not be proxied, redirected or relayed i.e. it would be not possible to use this mechanism if a proxy/redirect/relay agent is present in the Diameter path between remote peers and Stanby/active node. This can not be therefore defined as a generic mechanism. =20 [Ulf1] You're right of course. Informing remote peers of the failure of an active instance would henece require a new message I guess. that is, a message the be sent immediately after the CER/CAA message exchange directly following the detection of that an Active instance has become permanetly inavailable.=20 2) Synchronizing state (i.e. 5.2.2, first paragraph in [SR]) is not natively supported by [RM-ext], but could be suppored with a small change/addition I beleive. E.g. through a flag in the SRQ saying whether all session information is requested for all active sessions (all information on all sessions is requested when no Session-Id is provided in the SRQ), or just the session-Id of all active sesisons (i.e. an SRR without any Resource-bag AVPs).=20 [Lionel Morand] if needed, I think that this could be easily fulfilled with an optional AVP in SQR e.g. "State Synchronization AVP" of Enumarated type, that would clearly indicate the granularity of requested information about active sessions.=20 [Ulf1] Yes. I agree. I forsee a potential value in having a set of predefined values for different granularities. For example, (a) all information on all active sessions, (b) session ids only for all active sessions, (c) all information or session ids only for all sessions that'll time out with x seconds, (d) all information or session ids only for all sessions with application property x (related to one or more application specific AVPs), etc. While I see a clear need for differentiating between (a) and (b), I think (c) and (d) type of values would be interesting to discuss to found out whether that can be useful or just makes the solution more complex. =20 3) Reconstructing session state using application messages (i.e. 5.2.2, Using Application Messages in [SR]) is generally not supported by Diameter nor in [RM-ext]. As I understand the protocol a AAR updating an existing session is identified by that the Session-Id is known by the server (i.e. is active), while an AAR establishing a new session provides a new Session-Id not currently being used for any active session. Hence, a flag indicating that the message is for an existing sesison (or a separate message) would be needed to facilitate state reconstruction using mid-session messages. =20 4) Reconstructing session state using generic messages (i.e. 5.2.2, Using a Generic Message in [SR]) is indeed supported by [RM-ext] (i.e. through SRQ and SRR in which state information for several sessions can be requested and provided respectively).=20 Best regards, Ulf=20 ------_=_NextPart_001_01C7B33E.F91231A3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Diameter auditing - PART 1
Hi Lionel,
 
Pls find replies below [Ulf1]. =
 
Best regards,
Ulf

From: MORAND Lionel RD-CORE-ISS=20 [mailto:lionel.morand@orange-ftgroup.com]
Sent: den 17 juni = 2007=20 13:02
To: Ulf Bodin; dime@ietf.org
Subject: RE: = [Dime]=20 Diameter auditing - PART 1

Hi Ulf,
 
Some comments below.
 
BR,
 
Lionel

De : Ulf Bodin=20 [mailto:Ulf.Bodin@operax.com]
Envoy=E9 : vendredi 8 = juin 2007=20 17:58
=C0 : dime@ietf.org
Objet : [Dime] = Diameter=20 auditing - PART 1

All,

I've been looking in = whether the=20 original work on Diameter resource management extensions now captured = in=20 http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-re= qs-02.txt [RM-ext] would meet the demands = identified in=20 http://www.ietf.org/internet-drafts/draft-asveren-dime-state-rec= overy-01.txt [SR] on Diameter state recovery = considerations. Comments on this analyze are very wellcome. =

Going through section = 5.2.1 and 5.2.2=20 (PART 1) of [SR] and matching against [RM-ext] I noted the following = (remaing=20 sections/PARTs in following mail):

1) Having a = standby node=20 informing remote peers of the failure of an active instance (i.e. = 5.2.1 in=20 [SR]) is not covered by [RM-ext], not in any other spec (as far as I = know).=20 I'm not sure what kind of message would be appropriate for this = purpose (i.e.=20 a new mesage or an existing one such as CER). Any views on this? =
[Lionel = Morand] CER/CEA are=20 used to initiate a transport connection between diameter peers. In = this=20 specific case, we may assume that the Standby node may = actually also=20 indicate the active instance failure by sending a CER to the remote = peers. The=20 transport connection establishment would be a hint for the remote = peers to=20 detect that the Standby node is now active and that = therefore the=20 previous active node is down. The only problem is that CER/CAA = messages can=20 not be proxied, redirected or relayed i.e. it would be not possible to = use=20 this mechanism if a proxy/redirect/relay agent is present in the = Diameter path=20 between remote peers and Stanby/active node. This can not be = therefore=20 defined as a generic mechanism.  

[Ulf1] You're right = of course.=20 Informing remote peers of the failure of an active instance would = henece=20 require a new message I guess. that is, a message the be sent = immediately=20 after the CER/CAA message exchange directly following the detection of = that an=20 Active instance has become permanetly inavailable.=20

2) Synchronizing = state (i.e.=20 5.2.2, first paragraph in [SR]) is not natively supported by [RM-ext], = but=20 could be suppored with a small change/addition I beleive. E.g. through = a flag=20 in the SRQ saying whether all session information is requested for all = active=20 sessions (all information on all sessions is requested when no = Session-Id is=20 provided in the SRQ), or just the session-Id of all active sesisons = (i.e. an=20 SRR without any Resource-bag AVPs).
[Lionel Morand] if needed, I think that this = could be=20 easily fulfilled with an optional AVP in SQR e.g. "State = Synchronization AVP"=20 of Enumarated type, that would clearly indicate the granularity of = requested=20 information about active sessions. 

[Ulf1] Yes. I agree. = I forsee a=20 potential value in having a set of predefined values for different=20 granularities. For example, (a) all information on all active = sessions, (b)=20 session ids only for all active sessions, (c) all information or = session ids=20 only for all sessions that'll time out with x seconds, (d) all=20 information or session ids only for all sessions with application = property x (related to one or more application specific AVPs), etc. = While I=20 see a clear need for differentiating between (a) and (b), I think (c) = and (d)=20 type of values would be interesting to discuss to found out = whether that=20 can be useful or just makes the solution more complex.=20  

3) Reconstructing = session state=20 using application messages (i.e. 5.2.2, Using Application Messages in = [SR]) is=20 generally not supported by Diameter nor in [RM-ext]. As I understand = the=20 protocol a AAR updating an existing session is identified by that the=20 Session-Id is known by the server (i.e. is active), while an AAR = establishing=20 a new session provides a new Session-Id not currently being used for = any=20 active session. Hence, a flag indicating that the message is for an = existing=20 sesison (or a separate message) would be needed to facilitate state=20 reconstruction using mid-session messages.  

4) Reconstructing = session state using=20 generic messages (i.e. 5.2.2, Using a Generic Message in [SR]) is = indeed=20 supported by [RM-ext] (i.e. through SRQ and SRR in which state = information for=20 several sessions can be requested and provided respectively).=20

Best regards,
Ulf=20



------_=_NextPart_001_01C7B33E.F91231A3-- --===============2103651449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2103651449==-- From dime-bounces@ietf.org Wed Jun 20 12:25:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1305-00026d-OW; Wed, 20 Jun 2007 12:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1304-00026V-85 for dime@ietf.org; Wed, 20 Jun 2007 12:25:44 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1301-00069A-QR for dime@ietf.org; Wed, 20 Jun 2007 12:25:44 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1182356736!23344394!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32415 invoked from network); 20 Jun 2007 16:25:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 20 Jun 2007 16:25:36 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5KGPaAK001717 for ; Wed, 20 Jun 2007 09:25:36 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l5KGPYql001042 for ; Wed, 20 Jun 2007 11:25:35 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5KGPXJT001023 for ; Wed, 20 Jun 2007 11:25:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Date: Wed, 20 Jun 2007 12:25:32 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7187FBE@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: FW: First draft on the integration of QoS application thread-index: AceutWPOQbUxj1/bQ4Krh8NNWpduIwD1l7dwAAzQYPAAG+4SIAAJyVQA References: <9b0e41640706141150i640dd29cy89ad225881907627@mail.gmail.com><9b0e41640706141153g677d33e7o6ddb3f53da606939@mail.gmail.com><09C9068466B79E4C938DC7737562404D520936@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7187FBE@sonusmail04.sonusnet.com> From: "McCann Peter-A001034" To: "Asveren, Tolga" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Tolga, Dong, The existing text assumes that the Authorizing Entity is either a static subscriber database or is itself an Application Server. The term "Authorizing Entity" was introduced to abstract away from either of these two implementations. I would rather not introduce an additional interface, especially if it goes unspecified for now. I would rather have just one protocol that=20 can serve as an inter-domain or intra-domain interface depending on the business model, as Tolga says. In=20 3GPP terms, this would be one application that can=20 serve as either Gx or Rx. The "Diameter Cloud" shown in Figure 1 implies the location of the inter-domain interface. We could write into the draft some considerations for how proxies can handle Diameter QoS messages, in case they want to impose their own policies. As the base protocol allows, intermediate proxies can add AVPs to a command to indicate such local policies. -Pete Asveren, Tolga wrote: > Hi Dong, >=20 > I personally don't see any conceptual difference between interdomain > and intradomain requests regarding Diameter QoS. Both interfaces are > used to communicate the desire to reserve QoS with characteristics as > described by the AVPs in the corresponding messages. The rest is > probably dependent on policy, e.g. how interdomain requests are > handled v.s. =20 > intradomain requests. >=20 > IMHO, authorization can be treated as an integral part of QoS > reservation. It could be optionally omitted depending on the business > model. Probably, from QoS application point of view, the impact would > be to have an AVP identifying the user/subscriber in the message. > IMHO, the rest (whether and how the value in this AVP is used by the > server/proxy etc..., e.g. consulting an external database) is > implementation dependent. =20 >=20 > Thanks, > Tolga >=20 >=20 >=20 >> -----Original Message----- >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] >> Sent: Tuesday, June 19, 2007 6:27 PM >> To: McCann Peter-A001034; Christian Esteve; dime@ietf.org >> Subject: RE: [Dime] Re: FW: First draft on the integration of QoS >> application=20 >>=20 >> Pete, et al, >>=20 >> Although I have no objection to define the inter-domain interface, it >> seems to me the Rx in 3GPP does not fit well with the modeling >> defined in QoS application: - Rx is defined between Application >> Function and Policy Decision function (i.e. part of Authorizing >> entity in QoS application) - QoS application concerns the control of >> policy enforcement, the interface between authorizing entity and >> Network element, which is the Gx in 3GPP term.=20 >>=20 >> If we really like to cover both inter-domain and intra-domain >> scenarios in the single QoS application, I think it should be a >> Gx-like interface. In the inter-domain case, the Gx-like interface >> will be used between home PCRF and visited PCRF as well; besides it >> can be used between PCRF and PCEF for intra-domain case. >>=20 >> In addition, I think we should allow the flexibility to have >> Application Server separated from the Authorizing entity (but not >> mandatory), and maybe no need to standardize that interface between >> AS and Authorizing entity in this QoS application. >>=20 >> If you agree on this proposal, I'd like to edit the latest draft I >> sent out to reflect this notion.=20 >>=20 >> Dong >>=20 >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Tuesday, June 19, 2007 12:14 PM >> To: Christian Esteve; dime@ietf.org >> Subject: RE: [Dime] Re: FW: First draft on the integration of QoS >> application=20 >>=20 >> Hi, Christian, >>=20 >> Thanks for your comments, I would certainly like to take a look at >> your paper.=20 >>=20 >> I suppose I could be convinced that local policy should be taken >> care of with a separate interface, but I think it's important that >> IETF standardize the inter-domain case as a first priority. >> The local interface is less important to standardize now, because it >> could easily be taken care of with a proprietary interface based on >> purchasing decisions made by the operator, or it could easily be >> incorporated in to the Network Element itself. One of my goals for >> the diameter-qos draft has been to facilitate the inter-working of >> disparate application functions in different networks, and I think >> that should be the focus of this draft.=20 >>=20 >> If we really want to add a new local PDP element to the draft I >> would be ok with a modified Figure 1 that shows this. However, the >> Diameter cloud would then need to be shown between that entity and >> the application server, and the document should focus on this latter >> interface. In other words, we should be standardizing Rx now. >>=20 >> -Pete >>=20 >> Christian Esteve wrote: >>> Hi folks, >>>=20 >>> the discussion thread reflects once again the confrontation between >>> the operator SDO and the IETF worlds, and as it usually happens, >>> disagreements are not only motivated by network engineering issues >>> but by scope and nomenclature divergences. >>>=20 >>>>> I guess I don't see why we need two separate interfaces. They are >>>>> each transporting roughly the same information and doing the same >>>>> sort of job. >>>=20 >>> It is true that the job and type of infomation are similar, however >>> the separation of the interfaces makes sense to me. While one >>> interface is used only to request QoS, the other is expected to >>> carry and install QoS policy information (with different QoS >>> descriptors).=20 >>>=20 >>> The AF-PDP-PEP model (also referred to as AS-AE-NE) reflects the >>> architecture evolution of the SDOs that introduce policy-based >>> resource control functions.=20 >>>=20 >>> It has been said that: >>>>>>> There may be proxies in the >>>>>>> Diameter cloud that enforce their own policy decisions, some of >>>>>>> which will be local to the Network Element's administrative >>>>>>> domain. >>>=20 >>> To my understanding that is why the separated interfaces make sense. >>>=20 >>> An intermediate PDP (also referred to as PDF) may enforce further >>> policies (network type specific, user profile related, >>> operator-based) in conjunction with other network elements >>> (resource information, user database).=20 >>>=20 >>> Furthermore, the QoS description over the AF-PDP interface is likely >>> to differ from the QoS information describing the policy to be >>> instaslled in the NE, harmonizing and easing AF QoS requests and >>> enabling the QoS policy installation mechanism to evolve separately >>> in accordance to the transport network specifics. >>>=20 >>> The PDP would certainly have an inter-domain interface to AFs and >>> other inter- an intra PDPs. I bnelieve that the Diameter QoS >>> application running between the AF and the PDP could be defined in a >>> way that it could be applied for the inter-domain PDP-PDP peering >>> interface.=20 >>>=20 >>> Unfortunately my contribution to the discussion at this point is not >>> enriching the discussion regarding the implications to the Diameter >>> functionality (e.g. command and AVPs, realm routing, discovery >>> schemes, etc.).=20 >>>=20 >>> However, I am sharing under >>> http://www.dca.fee.unicamp.br/~pasquini/dime-qos-app/ >>> some figures depicting the abstracted SDOs architectures that could >>> help in the following discussions around the Diameter QoS >>> application. The figures have been extracted >>> from the the paper "A review on policy-based resource and admission >>> control functions in evolving access and next generation networks", >>> recently accepted for publication (draft copy can be provided if >>> interested).=20 >>>=20 >>>=20 >>> Best regards, >>> Christian >>>>=20 >>>>=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 20 18:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I197B-0003k7-CO; Wed, 20 Jun 2007 18:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I197A-0003ai-0M for dime@ietf.org; Wed, 20 Jun 2007 18:57:28 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1977-000885-F9 for dime@ietf.org; Wed, 20 Jun 2007 18:57:27 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5KMvKI3009965; Wed, 20 Jun 2007 17:57:20 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 17:57:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Date: Wed, 20 Jun 2007 17:57:19 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520946@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: FW: First draft on the integration of QoS application Thread-Index: AceutWPOQbUxj1/bQ4Krh8NNWpduIwD1l7dwAAzQYPAAG+4SIAAJyVQAAA1OgSA= References: <9b0e41640706141150i640dd29cy89ad225881907627@mail.gmail.com><9b0e41640706141153g677d33e7o6ddb3f53da606939@mail.gmail.com><09C9068466B79E4C938DC7737562404D520936@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7187FBE@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "McCann Peter-A001034" , "Asveren, Tolga" , X-OriginalArrivalTime: 20 Jun 2007 22:57:20.0236 (UTC) FILETIME=[5B54CAC0:01C7B38E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Pete, Tolga, I agree that this QoS application does not need to cover the interface between Application Server and Policy Server, which is the Rx in the 3GPP term.=20 Although the protocol wise the same command codes can be used for both inter/intra-domain cases, I think there are some differences from the (policy control) functional perspective, such as security requirement; and the information exchanged through the interface - in the inter-domain case the information would be more abstract and generic e.g. independent of network technology; and the routing mechanism - in the inter-domain case an anchor point would be used instead of disclosing the internal topology. As I said, I am open to cover both inter-domain and intra-domain scenarios in the same application, but it makes sense to elaborate on the difference in the functional modeling.=20 Dong -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Wednesday, June 20, 2007 12:26 PM To: Asveren, Tolga; dime@ietf.org Subject: RE: [Dime] Re: FW: First draft on the integration of QoS application Hi, Tolga, Dong, The existing text assumes that the Authorizing Entity is either a static subscriber database or is itself an Application Server. The term "Authorizing Entity" was introduced to abstract away from either of these two implementations. I would rather not introduce an additional interface, especially if it goes unspecified for now. I would rather have just one protocol that can serve as an inter-domain or intra-domain interface depending on the business model, as Tolga says. In 3GPP terms, this would be one application that can serve as either Gx or Rx. The "Diameter Cloud" shown in Figure 1 implies the location of the inter-domain interface. We could write into the draft some considerations for how proxies can handle Diameter QoS messages, in case they want to impose their own policies. As the base protocol allows, intermediate proxies can add AVPs to a command to indicate such local policies. -Pete Asveren, Tolga wrote: > Hi Dong, >=20 > I personally don't see any conceptual difference between interdomain=20 > and intradomain requests regarding Diameter QoS. Both interfaces are=20 > used to communicate the desire to reserve QoS with characteristics as=20 > described by the AVPs in the corresponding messages. The rest is=20 > probably dependent on policy, e.g. how interdomain requests are > handled v.s. =20 > intradomain requests. >=20 > IMHO, authorization can be treated as an integral part of QoS=20 > reservation. It could be optionally omitted depending on the business=20 > model. Probably, from QoS application point of view, the impact would=20 > be to have an AVP identifying the user/subscriber in the message. > IMHO, the rest (whether and how the value in this AVP is used by the=20 > server/proxy etc..., e.g. consulting an external database) is > implementation dependent. =20 >=20 > Thanks, > Tolga >=20 >=20 >=20 >> -----Original Message----- >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] >> Sent: Tuesday, June 19, 2007 6:27 PM >> To: McCann Peter-A001034; Christian Esteve; dime@ietf.org >> Subject: RE: [Dime] Re: FW: First draft on the integration of QoS=20 >> application >>=20 >> Pete, et al, >>=20 >> Although I have no objection to define the inter-domain interface, it >> seems to me the Rx in 3GPP does not fit well with the modeling=20 >> defined in QoS application: - Rx is defined between Application=20 >> Function and Policy Decision function (i.e. part of Authorizing=20 >> entity in QoS application) - QoS application concerns the control of=20 >> policy enforcement, the interface between authorizing entity and=20 >> Network element, which is the Gx in 3GPP term. >>=20 >> If we really like to cover both inter-domain and intra-domain=20 >> scenarios in the single QoS application, I think it should be a=20 >> Gx-like interface. In the inter-domain case, the Gx-like interface=20 >> will be used between home PCRF and visited PCRF as well; besides it=20 >> can be used between PCRF and PCEF for intra-domain case. >>=20 >> In addition, I think we should allow the flexibility to have=20 >> Application Server separated from the Authorizing entity (but not=20 >> mandatory), and maybe no need to standardize that interface between=20 >> AS and Authorizing entity in this QoS application. >>=20 >> If you agree on this proposal, I'd like to edit the latest draft I=20 >> sent out to reflect this notion. >>=20 >> Dong >>=20 >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Tuesday, June 19, 2007 12:14 PM >> To: Christian Esteve; dime@ietf.org >> Subject: RE: [Dime] Re: FW: First draft on the integration of QoS=20 >> application >>=20 >> Hi, Christian, >>=20 >> Thanks for your comments, I would certainly like to take a look at=20 >> your paper. >>=20 >> I suppose I could be convinced that local policy should be taken care >> of with a separate interface, but I think it's important that IETF=20 >> standardize the inter-domain case as a first priority. >> The local interface is less important to standardize now, because it=20 >> could easily be taken care of with a proprietary interface based on=20 >> purchasing decisions made by the operator, or it could easily be=20 >> incorporated in to the Network Element itself. One of my goals for=20 >> the diameter-qos draft has been to facilitate the inter-working of=20 >> disparate application functions in different networks, and I think=20 >> that should be the focus of this draft. >>=20 >> If we really want to add a new local PDP element to the draft I would >> be ok with a modified Figure 1 that shows this. However, the=20 >> Diameter cloud would then need to be shown between that entity and=20 >> the application server, and the document should focus on this latter=20 >> interface. In other words, we should be standardizing Rx now. >>=20 >> -Pete >>=20 >> Christian Esteve wrote: >>> Hi folks, >>>=20 >>> the discussion thread reflects once again the confrontation between=20 >>> the operator SDO and the IETF worlds, and as it usually happens,=20 >>> disagreements are not only motivated by network engineering issues=20 >>> but by scope and nomenclature divergences. >>>=20 >>>>> I guess I don't see why we need two separate interfaces. They are >>>>> each transporting roughly the same information and doing the same=20 >>>>> sort of job. >>>=20 >>> It is true that the job and type of infomation are similar, however=20 >>> the separation of the interfaces makes sense to me. While one=20 >>> interface is used only to request QoS, the other is expected to=20 >>> carry and install QoS policy information (with different QoS=20 >>> descriptors). >>>=20 >>> The AF-PDP-PEP model (also referred to as AS-AE-NE) reflects the=20 >>> architecture evolution of the SDOs that introduce policy-based=20 >>> resource control functions. >>>=20 >>> It has been said that: >>>>>>> There may be proxies in the >>>>>>> Diameter cloud that enforce their own policy decisions, some of=20 >>>>>>> which will be local to the Network Element's administrative=20 >>>>>>> domain. >>>=20 >>> To my understanding that is why the separated interfaces make sense. >>>=20 >>> An intermediate PDP (also referred to as PDF) may enforce further=20 >>> policies (network type specific, user profile related, >>> operator-based) in conjunction with other network elements (resource >>> information, user database). >>>=20 >>> Furthermore, the QoS description over the AF-PDP interface is likely >>> to differ from the QoS information describing the policy to be=20 >>> instaslled in the NE, harmonizing and easing AF QoS requests and=20 >>> enabling the QoS policy installation mechanism to evolve separately=20 >>> in accordance to the transport network specifics. >>>=20 >>> The PDP would certainly have an inter-domain interface to AFs and=20 >>> other inter- an intra PDPs. I bnelieve that the Diameter QoS=20 >>> application running between the AF and the PDP could be defined in a >>> way that it could be applied for the inter-domain PDP-PDP peering=20 >>> interface. >>>=20 >>> Unfortunately my contribution to the discussion at this point is not >>> enriching the discussion regarding the implications to the Diameter=20 >>> functionality (e.g. command and AVPs, realm routing, discovery=20 >>> schemes, etc.). >>>=20 >>> However, I am sharing under >>> http://www.dca.fee.unicamp.br/~pasquini/dime-qos-app/ >>> some figures depicting the abstracted SDOs architectures that could=20 >>> help in the following discussions around the Diameter QoS=20 >>> application. The figures have been extracted from the the paper "A=20 >>> review on policy-based resource and admission control functions in=20 >>> evolving access and next generation networks", recently accepted for >>> publication (draft copy can be provided if interested). >>>=20 >>>=20 >>> Best regards, >>> Christian >>>>=20 >>>>=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 21 03:00:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Gf1-0002OZ-2y; Thu, 21 Jun 2007 03:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Gez-0002MA-EI for dime@ietf.org; Thu, 21 Jun 2007 03:00:53 -0400 Received: from mu-out-0910.google.com ([209.85.134.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Gey-0004qc-1t for dime@ietf.org; Thu, 21 Jun 2007 03:00:53 -0400 Received: by mu-out-0910.google.com with SMTP id w8so403498mue for ; Thu, 21 Jun 2007 00:00:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=O7YGZZ9uBerCD23oWihMyfm7b95tlgvrEQqH3sZaS16OEglfVP/QdYMvybuL07q+Fcsk6xG8GkYzHucZ4rAIkMK5oa5hJnokaEqv+t/qzg4brTY8+IGXMVQOa6+3uXFgvIJxDmfcLYcFq1j67S36yg5jj26Jm+AIsrtC6Rmo5cQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=gsMb9MuDJdBqorUFgQF4whCTpwKp0oB3UAd3rd4LWGTIYFuVYc+WoC3gGkgR2mFw2MSpMszBDg7gMGH8earvLNj0Tcg4gvBr0DXWeu/xumH08mdJmMuD/AAS0bRx+VSjpX2vXqdiBlmVvImSLRN3V/Yh1uXqPLoiKQBtvRfzIxc= Received: by 10.82.136.4 with SMTP id j4mr3202663bud.1182409250647; Thu, 21 Jun 2007 00:00:50 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Thu, 21 Jun 2007 00:00:50 -0700 (PDT) Message-ID: Date: Thu, 21 Jun 2007 12:30:50 +0530 From: "harish raghuveer" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Dime] Origin-Host and Origin-Realm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0792619335==" Errors-To: dime-bounces@ietf.org --===============0792619335== Content-Type: multipart/alternative; boundary="----=_Part_138869_2792743.1182409250631" ------=_Part_138869_2792743.1182409250631 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Pardon my newbie question. I have a query regarding the Origin-Host and Origin-Realm AVPs. Is there any requirement that Origin-Host has to be a hostname (for ex, foo.bar.com) within the Origin-Realm (ex, bar.com)? If not, could some explain a potential use-case for this? -- thanks and regards, Harish R ------=_Part_138869_2792743.1182409250631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Pardon my newbie question. I have a query regarding the Origin-Host and Origin-Realm AVPs.

Is there any requirement that Origin-Host has to be a hostname (for ex, foo.bar.com ) within  the Origin-Realm (ex, bar.com)? If not, could some explain a potential use-case for this?

--

thanks and regards,
Harish R
------=_Part_138869_2792743.1182409250631-- --===============0792619335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0792619335==-- From dime-bounces@ietf.org Thu Jun 21 06:41:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1K6u-0002zj-JV; Thu, 21 Jun 2007 06:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1K6t-0002zO-95 for dime@ietf.org; Thu, 21 Jun 2007 06:41:55 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1K6s-0000NE-AB for dime@ietf.org; Thu, 21 Jun 2007 06:41:55 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5LAbWZP028331 for ; Thu, 21 Jun 2007 16:07:32 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5LAbWYL028314 for ; Thu, 21 Jun 2007 16:07:32 +0530 To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Nimish Bhargava Date: Thu, 21 Jun 2007 16:13:01 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 21/06/2007 04:15:40 PM, Serialize complete at 21/06/2007 04:15:40 PM X-Spam-Score: 0.6 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Dime] Problems at relay agents X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1475169229==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1475169229== Content-Type: multipart/alternative; boundary="=_alternative 003AD91665257301_=" This is a multipart message in MIME format. --=_alternative 003AD91665257301_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgQWxsDQoNCkkgaGF2ZSBzb21lIGNvbmNlcm5zIHJlZ2FyZGluZyB0aGUgYmVoYXZpb3Igb3Ig cmVsYXkgYWdlbnQgaW4gY2FzZSBhbiANCmVycm9yIChzdXBwb3NlIGludmFsaWQgYXZwIGxlbmd0 aCkgb2NjdXJzIGluIHRoZSByZXF1ZXN0IG1lc3NhZ2UgYXQgcmVsYXkgDQphZ2VudCB3aGlsZSBm aW5kaW5nIHRoZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUC4NCg0KU2hvdWxkIHRoZSByZWxheSBhZ2Vu dCByZXNwb25kIHRvIHRoZSBvcmlnaW5hdG9yIG9mIHJlcXVlc3QgYnkgc2VuZGluZyBhbiANCmVy cm9yIHJlc3BvbnNlID8NCklmIHllcywgd2hpY2ggYWxsIEFWUHMgc2hvdWxkIGJlIHNlbnQgaW4g dGhlIHJlc3BvbnNlIG1lc3NhZ2UuDQoNCkFsc28gaWYgYSByZXNwb25zZSBpcyByZWNlaXZlZCBh dCB0aGUgcmVsYXkgYWdlbnQgYW5kIGludmFsaWQgYXZwIGxlbmd0aCANCmVycm9yIG9jY3Vycy4N CkluIHRoaXMgY2FzZSB0byB3aG9tIHNob3VsZCBpdCByZXNwb25kIGJhY2ssIHRvIHRoZSBvcmln aW5hdG9yIG9mIHRoZSANCnJlcXVlc3Qgb3IgdG8gdGhlIG9yaWdpbmF0b3Igb2YgdGhlIHJlc3Bv bnNlIGFuZCB3aXRoIHdoaWNoIGFsbCBBVlBzLg0KDQpSZWdhcmRzLA0KTmltaXNoDQoNCg0KKioq KioqKioqKioqKioqKioqKioqKiogIEFyaWNlbnQtVW5jbGFzc2lmaWVkICAgKioqKioqKioqKioq KioqKioqKioqKioNCiJESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8g QXJpY2VudCAgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2 aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQg b3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVk IG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5k ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBu b3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnBy b2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhl IGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmls aXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9y bWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZp cnVzLiIK --=_alternative 003AD91665257301_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsbDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBoYXZlIHNvbWUgY29uY2VybnMg cmVnYXJkaW5nIHRoZSBiZWhhdmlvcg0Kb3IgcmVsYXkgYWdlbnQgaW4gY2FzZSBhbiBlcnJvciAo c3VwcG9zZSBpbnZhbGlkIGF2cCBsZW5ndGgpIG9jY3VycyBpbg0KdGhlIHJlcXVlc3QgbWVzc2Fn ZSBhdCByZWxheSBhZ2VudCB3aGlsZSBmaW5kaW5nIHRoZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUC48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNob3VsZCB0 aGUgcmVsYXkgYWdlbnQgcmVzcG9uZCB0byB0aGUNCm9yaWdpbmF0b3Igb2YgcmVxdWVzdCBieSBz ZW5kaW5nIGFuIGVycm9yIHJlc3BvbnNlID88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPklmIHllcywgd2hpY2ggYWxsIEFWUHMgc2hvdWxkIGJlIHNlbnQNCmluIHRo ZSByZXNwb25zZSBtZXNzYWdlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+QWxzbyBpZiBhIHJlc3BvbnNlIGlzIHJlY2VpdmVkIGF0IHRoZQ0KcmVsYXkg YWdlbnQgYW5kIGludmFsaWQgYXZwIGxlbmd0aCBlcnJvciBvY2N1cnMuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbiB0aGlzIGNhc2UgdG8gd2hvbSBzaG91bGQg aXQgcmVzcG9uZA0KYmFjaywgdG8gdGhlIG9yaWdpbmF0b3Igb2YgdGhlIHJlcXVlc3Qgb3IgdG8g dGhlIG9yaWdpbmF0b3Igb2YgdGhlIHJlc3BvbnNlDQphbmQgd2l0aCB3aGljaCBhbGwgQVZQcy48 YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCk5pbWlzaDxicj4NCjxicj4NCjxicj4NCioqKioqKioq KioqKioqKioqKioqKioqICZuYnNwO0FyaWNlbnQtVW5jbGFzc2lmaWVkICZuYnNwOyAqKioqKioq KioqKioqKioqKioqKioqKjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48 Zm9udCBjb2xvcj0jMDAwMDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9w cmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4g cHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUg CmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBp dCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9y LCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUg c3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlz Y2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8g cmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBv ZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFt YWdlIGZyb20gdmlydXMuIgo8L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwvdGFibGU+ --=_alternative 003AD91665257301_=-- --===============1475169229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1475169229==-- From dime-bounces@ietf.org Thu Jun 21 12:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PBs-0001b2-Ku; Thu, 21 Jun 2007 12:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PBr-0001au-2c for dime@ietf.org; Thu, 21 Jun 2007 12:07:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1PBn-0005Jv-4g for dime@ietf.org; Thu, 21 Jun 2007 12:07:23 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2007 09:07:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAD4/ekarR7PEh2dsb2JhbAAUgk2MQwIJDiyOeA X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208,217"; a="163676970:sNHT161553348" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5LG7Ium027566; Thu, 21 Jun 2007 09:07:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LG7DnK013089; Thu, 21 Jun 2007 16:07:18 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 09:07:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Origin-Host and Origin-Realm Date: Thu, 21 Jun 2007 09:07:17 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625042EC26E@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Origin-Host and Origin-Realm Thread-Index: Acez0fTucsA7J19RRSifCPzdez+EEQAS659w References: From: "Glen Zorn \(gwz\)" To: "harish raghuveer" X-OriginalArrivalTime: 21 Jun 2007 16:07:16.0275 (UTC) FILETIME=[3CA40830:01C7B41E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1905; t=1182442038; x=1183306038; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Origin-Host=20and=20Origin-Realm |Sender:=20; bh=ZIdBLD7NiGO/4/M9MP7fVKw1+R13CJe5UXCwiqZu+wg=; b=pF6ly3ptMN3JbQpljVe2ylUpILsnwsdNXe+g1xxJvuLY8sUuxvOiBvbMZmiyj0uKWftJ3V3D OLZZeUY+UY2AmQ17h08dkqKZhE4O41yXrR5rpYvhAFNLHYIIvO5SsKTx; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1302758243==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1302758243== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B41E.3C69D0A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B41E.3C69D0A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Pardon my newbie question. I have a query regarding the Origin-Host and Origin-Realm AVPs.=20 Is there any requirement that Origin-Host has to be a hostname (for ex, foo.bar.com ) within the Origin-Realm (ex, bar.com)? =20 That's the idea, yes, but unfortunately the definition of the Origin-Realm AVP forbids it. If not, could some explain a potential use-case for this? --=20 thanks and regards, Harish R ------_=_NextPart_001_01C7B41E.3C69D0A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

Pardon my newbie question. I have = a query=20 regarding the Origin-Host and Origin-Realm AVPs.

Is there any=20 requirement that Origin-Host has to be a hostname (for ex, foo.bar.com ) within  the = Origin-Realm (ex,=20 bar.com)?  
That's the idea, yes, but unfortunately the = definition of=20 the Origin-Realm AVP forbids it.
 If not,=20 could some explain a potential use-case for this?

--=20

thanks and regards,
Harish R
------_=_NextPart_001_01C7B41E.3C69D0A2-- --===============1302758243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1302758243==-- From dime-bounces@ietf.org Thu Jun 21 13:46:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qk5-0007aq-8n; Thu, 21 Jun 2007 13:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qk3-0007X1-Sh for dime@ietf.org; Thu, 21 Jun 2007 13:46:47 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Qk2-0000CG-6m for dime@ietf.org; Thu, 21 Jun 2007 13:46:47 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2007 10:46:15 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMAPxVekarR7PD/2dsb2JhbAAUgk2bfw X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208,217"; a="496561187:sNHT81985826952" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5LHkCCX032444; Thu, 21 Jun 2007 10:46:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5LHkBkc017246; Thu, 21 Jun 2007 17:46:12 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 10:46:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Origin-Host and Origin-Realm Date: Thu, 21 Jun 2007 10:46:11 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625042EC313@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Origin-Host and Origin-Realm Thread-Index: Ace0JlgUmMhcQ4f9Q2qJ2MumIDrX1AABMUfg References: <4C0FAAC489C8B74F96BEAD85EAEB2625042EC26E@xmb-sjc-215.amer.cisco.com> From: "Glen Zorn \(gwz\)" To: "harish raghuveer" X-OriginalArrivalTime: 21 Jun 2007 17:46:11.0918 (UTC) FILETIME=[0E8F46E0:01C7B42C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5287; t=1182447975; x=1183311975; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Origin-Host=20and=20Origin-Realm |Sender:=20; bh=D/dFws4Vi8rnSzP04rHD33c++IgXmO5H1J5ShlaD0I8=; b=lOdy5foUH6oNrdFbVvVsR8mucK/5Rnu/tVVXUhysrtmSYDGlb1rUtUAzZwPbaobLYXvQr/+i /YICcEDbxFeDrCW0HD9IzPdBauqdrDv9NmXAozyGzp2OZ+DiEjdyebEu; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0387106413==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0387106413== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B42C.0E5E64EE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B42C.0E5E64EE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Glen. This gives rise to one additional question: if Origin-Host includes Origin-Realm why do we have to explicitly include Origin-Realm in the messages along with the Origin-Host (as it is implied/can be derived)?=20 I'm glad you replied because I think I made a mistake in my last response. Thinking back thousands of years to the original discussions, I seem to remember that the realm was thought to be independent of the DNS, so that the host diameter.isp.com might actually be in the realm bigco.com.=20 Only possibility I can think of is, lets say one Diameter mobile client has the 'local' or 'host' realm as, lets say bar.com and moved under a new realm foo.com. In this case, if Origin-Realm is the new realm (foo.com), then the Origin-Realm wont be proper suffix of Origin-Host. Were these decoupled (made into separate AVPs) to support these kind of scenarios? Please confirm. =20 Yup, I think that's it.=20 thanks, Harish On 6/21/07, Glen Zorn (gwz) wrote:=20 =09 Hi, =09 Pardon my newbie question. I have a query regarding the Origin-Host and Origin-Realm AVPs.=20 =09 Is there any requirement that Origin-Host has to be a hostname (for ex, foo.bar.com ) within the Origin-Realm (ex, bar.com)? =20 That's the idea, yes, but unfortunately the definition of the Origin-Realm AVP forbids it. =09 If not, could some explain a potential use-case for this? =09 --=20 =09 thanks and regards, Harish R =09 --=20 Harish R Prabhu Ph:98457-34737 (M)=20 ------_=_NextPart_001_01C7B42C.0E5E64EE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks, Glen. This gives rise to one = additional=20 question: if Origin-Host includes Origin-Realm why do we have to = explicitly=20 include Origin-Realm in the messages along with the Origin-Host (as it = is=20 implied/can be derived)? 
 I'm glad you replied because = I think I=20 made a mistake in my last response.  Thinking back thousands of = years to=20 the original discussions, I seem to remember that the realm was thought = to be=20 independent of the DNS, so that the host diameter.isp.com might = actually be=20 in the realm bigco.com. 
Only possibility I can = think of=20 is, lets say one Diameter mobile client has the 'local' or 'host' realm = as, lets=20 say bar.com=20 and moved under a new realm foo.com. In this case, if = Origin-Realm is the=20 new realm (foo.com), then the Origin-Realm wont = be proper=20 suffix of Origin-Host. Were these decoupled (made into separate = AVPs)  to=20 support these kind of scenarios? Please confirm.  
Yup, I think that's=20 it. 

thanks,
Harish


On 6/21/07, Glen Zorn=20 (gwz) <gwz@cisco.com> = wrote:
Hi,

Pardon my newbie question. I = have a query=20 regarding the Origin-Host and Origin-Realm AVPs.

Is there any=20 requirement that Origin-Host has to be a hostname (for ex, foo.bar.com ) = within  the=20 Origin-Realm (ex, bar.com)?  
That's the=20 idea, yes, but unfortunately the definition of the Origin-Realm AVP = forbids=20 it.
 If not, could some = explain a=20 potential use-case for this?

--

thanks and=20 regards,
Harish R


--
Harish R Prabhu
Ph:98457-34737 (M) = ------_=_NextPart_001_01C7B42C.0E5E64EE-- --===============0387106413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0387106413==-- From dime-bounces@ietf.org Thu Jun 21 15:16:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1S8r-0000wU-KK; Thu, 21 Jun 2007 15:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1S8q-0000wP-Cl for dime@ietf.org; Thu, 21 Jun 2007 15:16:28 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1S8o-0006ma-GP for dime@ietf.org; Thu, 21 Jun 2007 15:16:28 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5LJC4ZP009453 for ; Fri, 22 Jun 2007 00:42:04 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5LJC3N8009437 for ; Fri, 22 Jun 2007 00:42:04 +0530 In-Reply-To: To: Nimish Bhargava Subject: Re: [Dime] Problems at relay agents MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Himanshu Bahl Date: Fri, 22 Jun 2007 00:44:19 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 22/06/2007 12:50:12 AM, Serialize complete at 22/06/2007 12:50:12 AM X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: Preeti Shandilya , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0587050147==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0587050147== Content-Type: multipart/alternative; boundary="=_alternative 0069DCE565257301_=" This is a multipart message in MIME format. --=_alternative 0069DCE565257301_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20Nimish,=0D=0A=0D=0Aplease=20find=20my=20comments=20in-line.=0D=0Aals= o=20please=20note=20I`m=20referring=20to=20the=20following=20document.=0D= =0Adraft-ietf-dime-rfc3588bis-04.txt=0D=0A=0D=0AThanks.=0D=0A=0D=0ASincer= ely,=0D=0AHimanshu=20Bahl=0D=0ASoftware=20Engineer=0D=0A=20=0D=0AA=20R=20= I=20C=20E=20N=20T=0D=0A=0D=0A?You=20can't=20shake=20hands=20with=20a=20cl= enched=20fist.?=0D=0A=0D=0A=0D=0A=0D=0ANimish=20Bhargava/HSS@HSS=20=0D=0A= 06/21/2007=2004:13=20PM=0D=0A=0D=0A=0D=0ATo=0D=0Adime@ietf.org=0D=0Acc=0D= =0A=0D=0ASubject=0D=0A[Dime]=20Problems=20at=20relay=20agents=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AHi=20All=20=0D=0A=0D=0AI=20have=20som= e=20concerns=20regarding=20the=20behavior=20or=20relay=20agent=20in=20cas= e=20an=20=0D=0Aerror=20(suppose=20invalid=20AVP=20length)=20occurs=20in= =20the=20request=20message=20at=20relay=20=0D=0Aagent=20while=20finding= =20the=20Destination-Host=20AVP.=20=0D=0A=0D=0AShould=20the=20relay=20age= nt=20respond=20to=20the=20originator=20of=20request=20by=20sending=20an= =20=0D=0Aerror=20response=20?=20=0D=0A<<=0D=0AI=20think=20the=20above=20s= cenario=20should=20be=20considered=20as=20failure=20to=20get=20complete= =20=0D=0Arouting=20information=20by=20the=20relay=20agent.(=20due=20to=20= inability=20to=20decode=20the=20=0D=0Adestination=20Host=20AVP=20)=20.=0D= =0AI=20think=20this=20is=20somewhat=20similar=20to=20the=20situation=20de= picted=20in=20figure=207=20of=20=0D=0Athe=20RFC.=0D=0ASince=20you=20are= =20unable=20to=20find=20the=20routing=20information=20of=20the=20message= =20you=20=0D=0Ashould=20return=20the=20answer=20message=20with=20the=20AB= NF=20defined=20in=20section=207.2=20=20and=20=0D=0Aresult=20code=20as=20D= IAMETER_UNABLE_TO_DELIVER=0D=0Athis=20would=20also=20make=20the=20behavio= r=20confirm=20to=20the=20following=20bullet=20of=20=0D=0Asection=206.1=20= =0D=0A=20=20=20o=20=20If=20none=20of=20the=20above=20is=20successful,=20a= n=20answer=20is=20returned=20with=20the=20=0D=0AResult-Code=20set=20to=20= DIAMETER_UNABLE_TO_DELIVER,=20with=20the=20E-bit=20set.=0D=0A=0D=0A>>=0D= =0AIf=20yes,=20which=20all=20AVPs=20should=20be=20sent=20in=20the=20respo= nse=20message.=20=0D=0A<<=0D=0Aas=20stated=20above=20the=20answer=20shoul= d=20be=20in=20the=20ABNF=20defined=20in=20section=207.2=20=0D=0A>>=0D=0AA= lso=20if=20a=20response=20is=20received=20at=20the=20relay=20agent=20and= =20invalid=20AVP=20length=20=0D=0Aerror=20occurs.=20=0D=0AIn=20this=20cas= e=20to=20whom=20should=20it=20respond=20back,=20to=20the=20originator=20o= f=20the=20=0D=0Arequest=20or=20to=20the=20originator=20of=20the=20respons= e=20and=20with=20which=20all=20AVPs.=0D=0A<<=0D=0Aaccording=20to=20the=20= snippet=20of=20section=206.2.2=20stated=20below=20the=20relay=20should=20= =0D=0Aadd=20its=20identity=20to=20the=20Error_Reporting_Host=20AVP=20and= =20should=20add=20=0D=0Ainvalid-length=20error=20code=20in=20the=20result= =20code=20AVP=20and=20should=20send=20the=20=0D=0Aanswer=20message=20to= =20the=20destination(=20of=20the=20original=20Answer=20message=20).=20=0D= =0A=0D=0AIf=20the=20agent=20receives=20an=20answer=20message=20with=20a= =20Result-Code=20AVP=20indicating=20=0D=0Asuccess,=20and=20it=20wishes=20= to=20modify=20the=20AVP=20to=20indicate=20an=20error,=20it=20MUST=20=0D= =0Amodify=20the=20Result-Code=20AVP=20to=20contain=20the=20appropriate=20= error=20in=20the=20message=20=0D=0Adestined=20towards=0D=0Athe=20access= =20device=20as=20well=20as=20include=20the=20Error-Reporting-Host=20AVP= =20and=20it=20=0D=0AMUST=20issue=20an=20STR=20on=20behalf=20of=20the=20ac= cess=20device.=20=0D=0AThe=20agent=20MUST=20then=20send=20the=20answer=20= to=20the=20host=20that=20it=20received=20the=20=0D=0Aoriginal=20request= =20from.=0D=0A=0D=0A>>=20=0D=0ARegards,=0D=0ANimish=0D=0A=0D=0A=0D=0A****= *******************=20=20Aricent-Unclassified=20=20=20*******************= ****=20=0D=0A"DISCLAIMER:=20This=20message=20is=20proprietary=20to=20Aric= ent=20=20and=20is=20intended=20=0D=0Asolely=20for=20the=20use=20of=20=0D= =0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20conta= in=20privileged=20or=20=0D=0Aconfidential=20information=20and=20should=20= not=20be=20=0D=0Acirculated=20or=20used=20for=20any=20purpose=20other=20t= han=20for=20what=20it=20is=20intended.=20If=20=0D=0Ayou=20have=20received= =20this=20message=20in=20error,=20=0D=0Aplease=20notify=20the=20originato= r=20immediately.=20If=20you=20are=20not=20the=20intended=20=0D=0Arecipien= t,=20you=20are=20notified=20that=20you=20are=20strictly=0D=0Aprohibited= =20from=20using,=20copying,=20altering,=20or=20disclosing=20the=20content= s=20of=20=0D=0Athis=20message.=20Aricent=20accepts=20no=20responsibility= =20for=20=0D=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the= =20information=20transmitted=20by=20this=20=0D=0Aemail=20including=20dama= ge=20from=20virus."=0D=0A=0D=0A__________________________________________= _____=0D=0ADiME=20mailing=20list=0D=0ADiME@ietf.org=0D=0Ahttps://www1.iet= f.org/mailman/listinfo/dime=0D=0A=0D=0A=0D=0A=0D=0A**********************= *=20=20Aricent-Private=20=20=20***********************=0D=0A"DISCLAIMER:= =20This=20message=20is=20proprietary=20to=20Aricent=20=20and=20is=20inten= ded=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=20i= t=20is=20addressed.=20It=20may=20contain=20privileged=20or=20confidential= =20information=20and=20should=20not=20be=20=0Acirculated=20or=20used=20fo= r=20any=20purpose=20other=20than=20for=20what=20it=20is=20intended.=20If= =20you=20have=20received=20this=20message=20in=20error,=20=0Aplease=20not= ify=20the=20originator=20immediately.=20If=20you=20are=20not=20the=20inte= nded=20recipient,=20you=20are=20notified=20that=20you=20are=20strictly=0A= prohibited=20from=20using,=20copying,=20altering,=20or=20disclosing=20the= =20contents=20of=20this=20message.=20Aricent=20accepts=20no=20responsibil= ity=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the= =20information=20transmitted=20by=20this=20email=20including=20damage=20f= rom=20virus."=0A --=_alternative 0069DCE565257301_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20Nimish,=0D= =0A
=0D=0A
please=20find=20m= y=20comments=20in-line.=0D=0A
also=20please=20note=20I`m=20referring=20to=20the=0D=0Afollowing=20= document.=0D=0A
draft-ietf-dime-rfc3588bis= -04.txt=0D=0A
=0D=0A
Thanks.=0D=0A

= =0D=0ASincerely,=0D=0A=0D=0A=0D=0AHiman= shu=20Bahl=0D=0A=0D=0ASoftware=20Engineer=0D=0A=0D=0A =0D=0A=0D=0AA=20R=20I=20C=20E=20N=20T=0D=0A
=0D=0A

“You=20can't=20shake=20ha= nds=20with=20a=20clenched=20fist.”=0D=0A
=0D=0A
=0D=0A=
=0D=0A=0D=0A=0D=0ANimish=20Bhargava/HSS@H= SS=0D=0A=0D=0A

06/21/= 2007=2004:13=20PM=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ATo=0D=0Adime@ietf.org=0D=0A=0D=0A=0D=0Acc=0D=0A=0D=0A=0D=0A=0D=0ASubject=0D= =0A[Dime]=20Pro= blems=20at=20relay=0D=0Aagents=0D=0A
=0D=0A=0D= =0A=0D=0A
=0D=0A
=0D=0A
=0D= =0A
=0D=0A
=0D=0A

=0D= =0AHi=20All=20
=0D=0A
=0D=0AI=20have=20some=20concerns=20regarding= =20the=20behavior=20or=20relay=20agent=20in=20case=20an=20error=0D=0A(sup= pose=20invalid=20AVP=20length)=20occurs=20in=20the=20request=20message=20= at=20relay=20agent=0D=0Awhile=20finding=20the=20Destination-Host=20AVP.=20
=0D=0A
=0D=0AShould=20the=20relay=20agent=20respond=20to=20the=20ori= ginator=20of=20request=20by=20sending=0D=0Aan=20error=20response=20?=20=0D=0A
<<=0D=0A
I=20think=20the=20above=20scenario=0D=0Ashould= =20be=20considered=20as=20failure=20to=20get=20complete=20routing=20infor= mation=20by=0D=0Athe=20relay=20agent.(=20due=20to=20inability=20to=20deco= de=20the=20destination=20Host=20AVP=20)=0D=0A.=0D=0A
I=20think=20this=20is=20somew= hat=0D=0Asimilar=20to=20the=20situation=20depicted=20in=20figure=207=20of= =20the=20RFC.=0D=0A
Since=20you=20are=20unable=20to=20find=0D=0Athe=20routing=20in= formation=20of=20the=20message=20you=20should=20return=20the=20answer=20m= essage=0D=0Awith=20the=20ABNF=20defined=20in=20section=207.2=20 and= =20result=20code=20as=20DIAMETER_UNABLE_TO_DELIVER=0D=0A
this=20would=20also=20ma= ke=20the=0D=0Abehavior=20confirm=20to=20the=20following=20bullet=20of=20s= ection=206.1=20=0D=0A
 =20 o=20&= nbsp;If=20none=20of=20the=20above=20is=20successful,=0D=0Aan=20answer=20i= s=20returned=20with=20the=20Result-Code=20set=20to=20DIAMETER_UNABLE_TO_D= ELIVER,=0D=0Awith=20the=20E-bit=20set.=0D=0A
=0D=0A
>>
=0D=0AIf=20yes,=20which=20all=20AVP= s=20should=20be=20sent=20in=20the=20response=20message.=0D=0A
=0D=0A<<=0D=0A
as=20stated=20above=20the=20answer=0D=0Ashould=20be=20in= =20the=20ABNF=20defined=20in=20section=207.2=20=0D=0A
>>
=0D=0AAlso=20if=20a=20response=20is=20rece= ived=20at=20the=20relay=20agent=20and=20invalid=20AVP=20length=0D=0Aerror= =20occurs.=20
=0D=0AIn=20this=20case=20to=20whom=20should=20it=20respond= =20back,=20to=20the=20originator=20of=20the=20request=0D=0Aor=20to=20the= =20originator=20of=20the=20response=20and=20with=20which=20all=20AVPs.=0D=0A<&= lt;=0D=0A
according=20to=20the=20snippet=0D=0Aof=20section=206.2.2=20stated=20belo= w=20the=20relay=20should=20add=20its=20identity=20to=20the=0D=0AError_Rep= orting_Host=20AVP=20and=20should=20add=20invalid-length=20error=20code=20= in=20the=0D=0Aresult=20code=20AVP=20and=20should=20send=20the=20answer=20= message=20to=20the=20destination(=0D=0Aof=20the=20original=20Answer=20mes= sage=20).=20=0D=0A
=0D=0A
If=20the=20ag= ent=20receives=20an=20answer=20message=20with=20a=20Result-Code=0D=0AAVP= =20indicating=20success,=20and=20it=20wishes=20to=20modify=20the=20AVP=20= to=20indicate=20an=0D=0Aerror,=20it=20MUST=20modify=20the=20Result-Code= =20AVP=20to=20contain=20the=20appropriate=20error=0D=0Ain=20the=20message= =20destined=20towards
=0D=0Athe=20access=20device=20as=20well=20as=20i= nclude=20the=20Error-Reporting-Host=20AVP=20and=20it=0D=0AMUST=20issue=20= an=20STR=20on=20behalf=20of=20the=20access=20device.=20=0D=0A=
The=20agent=20MUST=20then=20send=20the=20answer= =20to=20the=20host=20that=0D=0Ait=20received=20the=20original=20request= =20from.=0D=0A
=0D=0A
>>=0D=0A
=0D=0ARegards,
=0D=0ANimish
=0D=0A
=0D=0A
=0D= =0A***********************=20 Aricent-Unclassified=20 =20******= *****************=0D=0A=0D=0A=0D=0A=0D=0A"DISCLAIMER:=20This=20message=0D=0Ais=20proprietary=20to= =20Aricent=20 and=20is=20intended=20solely=20for=20the=20use=20of=20=
=0D=0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20may= =20contain=20privileged=20or=20confidential=0D=0Ainformation=20and=20shou= ld=20not=20be=20
=0D=0Acirculated=20or=20used=20for=20any=20purpose=20= other=20than=20for=20what=20it=20is=20intended.=0D=0AIf=20you=20have=20re= ceived=20this=20message=20in=20error,=20
=0D=0Aplease=20notify=20the= =20originator=20immediately.=20If=20you=20are=20not=20the=20intended=20re= cipient,=0D=0Ayou=20are=20notified=20that=20you=20are=20strictly
=0D= =0Aprohibited=20from=20using,=20copying,=20altering,=20or=20disclosing=20= the=20contents=20of=0D=0Athis=20message.=20Aricent=20accepts=20no=20respo= nsibility=20for=20
=0D=0Aloss=20or=20damage=20arising=20from=20the=20u= se=20of=20the=20information=20transmitted=20by=20this=0D=0Aemail=20includ= ing=20damage=20from=20virus."
=0D=0A=0D=0A_______________________________________________
= =0D=0ADiME=20mailing=20list
=0D=0ADiME@ietf.org
=0D=0Ahttps://www1.= ietf.org/mailman/listinfo/dime
=0D=0A=0D=0A

=0D=0A
=0D=0A***********************= =20 Aricent-Private=20 =20***********************=0D=0A<= table>

"DISCLAIME=
R:=20This=20message=20is=20proprietary=20to=20Aricent=20=20and=20is=20int=
ended=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=
=20it=20is=20addressed.=20It=20may=20contain=20privileged=20or=20confiden=
tial=20information=20and=20should=20not=20be=20=0Acirculated=20or=20used=
=20for=20any=20purpose=20other=20than=20for=20what=20it=20is=20intended.=
=20If=20you=20have=20received=20this=20message=20in=20error,=20=0Aplease=
=20notify=20the=20originator=20immediately.=20If=20you=20are=20not=20the=
=20intended=20recipient,=20you=20are=20notified=20that=20you=20are=20stri=
ctly=0Aprohibited=20from=20using,=20copying,=20altering,=20or=20disclosin=
g=20the=20contents=20of=20this=20message.=20Aricent=20accepts=20no=20resp=
onsibility=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20o=
f=20the=20information=20transmitted=20by=20this=20email=20including=20dam=
age=20from=20virus."=0A
--=_alternative 0069DCE565257301_=-- --===============0587050147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0587050147==-- From dime-bounces@ietf.org Fri Jun 22 08:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iFN-0001T0-Vr; Fri, 22 Jun 2007 08:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iFM-0001St-8h for dime@ietf.org; Fri, 22 Jun 2007 08:28:16 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1iFK-00070S-UL for dime@ietf.org; Fri, 22 Jun 2007 08:28:16 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5MCNp8U007862 for ; Fri, 22 Jun 2007 17:53:51 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5MCNo5D007824 for ; Fri, 22 Jun 2007 17:53:51 +0530 In-Reply-To: To: dime@ietf.org Subject: [Dime] Problem with Redirect Agent MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Geetika Gupta Date: Fri, 22 Jun 2007 18:01:56 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 22/06/2007 06:02:01 PM, Serialize complete at 22/06/2007 06:02:01 PM X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0158586162==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0158586162== Content-Type: multipart/alternative; boundary="=_alternative 00447E3065257302_=" This is a multipart message in MIME format. --=_alternative 00447E3065257302_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIGhhdmUgYW4gdW5kZXJzdGFuZGluZyBpc3N1ZSB3aXRoIHRoZSBSZWRpcmVj dCBBZ2VudC4gUmVmZXJyZWQgdG8gDQpodHRwOi8vd3d3MS50b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXRzb3UtZGltZS1iYXNlLXJvdXRpbmctZXh0LTAwDQoNCkluIHRoZSBzY2VuYXJpbyB3aGVy ZSBSZWRpcmVjdCBhbmQgUHJveHkgYWdlbnQgYXJlIHByZXNlbnQgaW4gdGhlIHNhbWUgDQpyZWFs bS4NCg0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgfCAgICAgRGlhbWV0ZXIgICAg IHwNCiAgICAgIHwgIFJlZGlyZWN0IEFnZW50ICB8DQogICAgICB8KGFnZW50LmV4YW1wbGUubmV0 KXwNCiAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgIF4gICAgfA0KICAgICAg ICAgICB8ICAgIHwgUmVkaXJlY3QgSW5kaWNhdGlvbg0KICAgICAgICAgICB8ICAgIHwgICByZWRp cmVjdC1ob3N0PWhtcy5leGFtcGxlLm5ldA0KICAgICAgICAgICB8ICAgIHwgICByZWRpcmVjdC1y ZWFsbT1SLVI6ZXhhbXBsZS5uZXQNCiAgICAgICAgICAgfCAgICB2DQogICAgICArLS0tLS0tLS0t LS0tLSsgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICAgKy0tLS0tLS0tLS0tKw0K ICAgICAgfCAgQ2xpZW50ICAgICB8ICAgICAgICAgICAgfCAgIFByb3h5ICAgICB8ICAgICAgICAg IHwgU2VydmVyICAgIHwNCiAgICAgIHxjbGllbnQuc291cmNlfC0tLS0tLS0tLS0tPnxwcm94eS5l eGFtcGxlfC0tLS0tLS0tLT4raG1zLmV4YW1wbGV8DQogICAgICB8ICAgLm5ldCAgICAgIHwgICAg ICAgICAgICB8ICAgIC5uZXQgICAgIHwgICAgICAgICAgfCAgIC5uZXQgICAgfA0KICAgICAgKy0t LS0tLS0tLS0tLS0rICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICstLS0tLS0t LS0tLSsNCiAgICAgICAgICAgICBkZXN0LWhvc3Q9aG1zLmV4YW1wbGUubmV0IA0KICAgICAgICAg ICAgIGRlc3QtcmVhbG09ZXhhbXBsZS5uZXQgDQoNCg0KVGhlbiB3aGVuZXZlciBDbGllbnQgd2ls bCBsb29rIGludG8gdGhlIHJvdXRpbmcgdGFibGUgYmFzZWQgb24gcmVhbG0gDQooZXhhbXBsZS5u ZXQpLCBpdCBjYW4gYWx3YXlzIHJvdXRlIHRoZSBtZXNzYWdlIHRvICByZWRpcmVjdCBhZ2VudCBh bmQgbm90IA0KdGhlIFByb3h5IEFnZW50Lg0KQW5kIGhlbmNlIHdpbGwgZm9ybSBhIGxvb3AuDQoN CldoYXQgc2h1ZCBiZSB0aGUgc29sdXRpb24gdG8gc3VjaCBraW5kIG9mIHByb2JsZW0uIFdoYXQg a2luZCBvZiBjaGVjayBzaHVkIA0KYmUgdGhlcmUuDQoNCg0KUmVnYXJkcywNCkdlZXRpa2ENCg0K KioqKioqKioqKioqKioqKioqKioqKiogIEFyaWNlbnQtIENvbmZpZGVudGlhbCAgICoqKioqKioq KioqKioqKioqKioqKioqDQoNCioqKioqKioqKioqKioqKioqKioqKioqICBBcmljZW50LSBDb25m aWRlbnRpYWwgICAqKioqKioqKioqKioqKioqKioqKioqKg0KIkRJU0NMQUlNRVI6IFRoaXMgbWVz c2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNo b3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhh biBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNz YWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0 aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRl cmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50 IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZy b20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBp bmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo= --=_alternative 00447E3065257302_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBhbiB1bmRlcnN0YW5k aW5nIGlzc3VlIHdpdGggdGhlDQpSZWRpcmVjdCBBZ2VudC4gUmVmZXJyZWQgdG8gaHR0cDovL3d3 dzEudG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c291LWRpbWUtYmFzZS1yb3V0aW5nLWV4dC0w MDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW4gdGhl IHNjZW5hcmlvIHdoZXJlIFJlZGlyZWN0IGFuZCBQcm94eQ0KYWdlbnQgYXJlIHByZXNlbnQgaW4g dGhlIHNhbWUgcmVhbG0uPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTM+ Jm5ic3A7ICZuYnNwOystLS0tLS0tLS0tLS0tLS0tLS0rPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7fCAmbmJzcDsgJm5ic3A7IERpYW1ldGVyICZuYnNwOyAmbmJzcDsgfDxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwO3wgJm5ic3A7UmVkaXJlY3QgQWdlbnQgJm5ic3A7fDxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwO3woYWdlbnQuPGI+ZXhhbXBsZS5uZXQ8L2I+KXw8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsrLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IF4gJm5ic3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDt8IFJlZGlyZWN0IEluZGljYXRpb248YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyByZWRpcmVjdC1ob3N0PWhtcy5leGFtcGxlLm5ldDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwO3wgJm5ic3A7IHJlZGlyZWN0LXJlYWxt PVItUjpleGFtcGxlLm5ldDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7ICZuYnNwO3Y8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLS0tLS0tLS0t LSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7Ky0tLS0tLS0tLS0t LS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLS0tLS0tLS0rPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDtDbGllbnQgJm5ic3A7ICZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7IFByb3h5ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO3wgU2VydmVyICZu YnNwOyAmbmJzcDt8PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7fGNsaWVudC5zb3VyY2V8LS0t LS0tLS0tLS0mZ3Q7fHByb3h5LjxiPmV4YW1wbGU8L2I+fC0tLS0tLS0tLSZndDsraG1zLjxiPmV4 YW1wbGU8L2I+fDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7IC5uZXQgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3wgJm5ic3A7ICZuYnNwOzxiPi5uZXQgPC9iPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7IDxiPi5uZXQ8L2I+ICZuYnNwOyAmbmJzcDt8 PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOystLS0tLS0tLS0tLS0tKyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0tKzxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXN0LWhvc3Q9aG1zLmV4YW1wbGUubmV0ICZuYnNw Ow0KJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBkZXN0LXJlYWxtPWV4YW1wbGUubmV0ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJy Pg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlRoZW4gd2hlbmV2ZXIgQ2xpZW50IHdpbGwgbG9vayBpbnRvDQp0aGUgcm91dGluZyB0YWJsZSBi YXNlZCBvbiByZWFsbSAoZXhhbXBsZS5uZXQpLCBpdCBjYW4gYWx3YXlzIHJvdXRlIHRoZQ0KbWVz c2FnZSB0byAmbmJzcDtyZWRpcmVjdCBhZ2VudCBhbmQgbm90IHRoZSBQcm94eSBBZ2VudC48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZCBoZW5jZSB3aWxsIGZv cm0gYSBsb29wLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+V2hhdCBzaHVkIGJlIHRoZSBzb2x1dGlvbiB0byBzdWNoIGtpbmQNCm9mIHByb2JsZW0uIFdo YXQga2luZCBvZiBjaGVjayBzaHVkIGJlIHRoZXJlLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdlZXRpa2E8YnI+DQo8YnI+DQoqKioqKioqKioqKioq KioqKioqKioqKiAmbmJzcDtBcmljZW50LSBDb25maWRlbnRpYWwgJm5ic3A7ICoqKioqKioqKioq KioqKioqKioqKioqPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKiogJm5ic3A7QXJp Y2VudC0gQ29uZmlkZW50aWFsICZuYnNwOyAqKioqKioqKioqKioqKioqKioqKioqKjwvZm9udD4N Cjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAwMDAwPjxwcmU+ IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQg aXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9t IGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3Ig YW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9t IHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2Yg dGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3Nz IG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNt aXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo8L3ByZT48 L2ZvbnQ+PC90ZD48L3RyPjwvdGFibGU+ --=_alternative 00447E3065257302_=-- --===============0158586162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0158586162==-- From dime-bounces@ietf.org Fri Jun 22 09:11:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iux-0007uP-EQ; Fri, 22 Jun 2007 09:11:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iuv-0007oF-Ns for dime@ietf.org; Fri, 22 Jun 2007 09:11:13 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1iuu-0003aQ-Bz for dime@ietf.org; Fri, 22 Jun 2007 09:11:13 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5MDAYGd072066; Fri, 22 Jun 2007 09:10:34 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <467BCA4B.3090106@tari.toshiba.com> Date: Fri, 22 Jun 2007 09:10:35 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Geetika Gupta Subject: Re: [Dime] Problem with Redirect Agent References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, You may want to refer to Sec 6.1.7 of 3588 on how receivers of redirect indication uses redirect-hosts avps. regards, victor > > Hi All, > > I have an understanding issue with the Redirect Agent. Referred to > http://www1.tools.ietf.org/html/draft-tsou-dime-base-routing-ext-00 > > In the scenario where Redirect and Proxy agent are present in the same > realm. > > > +------------------+ > | Diameter | > | Redirect Agent | > |(agent.*example.net*)| > +------------------+ > ^ | > | | Redirect Indication > | | redirect-host=hms.example.net > | | redirect-realm=R-R:example.net > | v > +-------------+ +-------------+ +-----------+ > | Client | | Proxy | | Server | > |client.source|----------->|proxy.*example*|--------->+hms.*example*| > | .net | | *.net * | | *.net* | > +-------------+ +-------------+ +-----------+ > dest-host=hms.example.net > dest-realm=example.net > > > Then whenever Client will look into the routing table based on realm > (example.net), it can always route the message to redirect agent and > not the Proxy Agent. > And hence will form a loop. > > What shud be the solution to such kind of problem. What kind of check > shud be there. > > > Regards, > Geetika > > *********************** Aricent- Confidential *********************** > > *********************** Aricent- Confidential *********************** > "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of > the individual to whom it is addressed. It may contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for > loss or damage arising from the use of the information transmitted by this email including damage from virus." > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 22 12:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mLK-00015H-Uq; Fri, 22 Jun 2007 12:50:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mLJ-000156-Kw for dime@ietf.org; Fri, 22 Jun 2007 12:50:41 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1mLF-000599-TK for dime@ietf.org; Fri, 22 Jun 2007 12:50:41 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2007 09:50:37 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAJeae0arR7O6h2dsb2JhbAAUgk+MQwIJDiyNKA X-IronPort-AV: i="4.16,452,1175497200"; d="scan'208,217"; a="381332528:sNHT230141604" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5MGoaXx016368; Fri, 22 Jun 2007 09:50:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5MGoUn2000564; Fri, 22 Jun 2007 16:50:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 09:50:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Problem with Redirect Agent Date: Fri, 22 Jun 2007 09:50:21 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504349EB7@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Problem with Redirect Agent Thread-Index: Ace0yNPeooF/YUt2QJiAZ5kAXEKMEwAF0GKQ References: From: "Glen Zorn \(gwz\)" To: "Geetika Gupta" X-OriginalArrivalTime: 22 Jun 2007 16:50:21.0981 (UTC) FILETIME=[6C4134D0:01C7B4ED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6848; t=1182531036; x=1183395036; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Problem=20with=20Redirect=20Agent |Sender:=20; bh=0SfQzTuAzx2gaHie8UPBX0zjpjTXzaZrPFiMR4oa6kA=; b=h1mR2Fp1V6AsJom9HnE8Kf5vC3jqeljyRBVX+XbkdHgMv3vhpngpUngI5OcblWypgHXr2bWT gFC3KCKl2L9fbbgnH6LGaleSvkvEVv7vNl0WY0xn9GWx8/5dn03wzZzf; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1960440993==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1960440993== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B4ED.6BBFF46E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B4ED.6BBFF46E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All,=20 I have an understanding issue with the Redirect Agent. Referred to http://www1.tools.ietf.org/html/draft-tsou-dime-base-routing-ext-00=20 In the scenario where Redirect and Proxy agent are present in the same realm.=20 +------------------+ | Diameter | | Redirect Agent | |(agent.example.net)| +------------------+ ^ | | | Redirect Indication | | redirect-host=3Dhms.example.net | | redirect-realm=3DR-R:example.net | v +-------------+ +-------------+ +-----------+ | Client | | Proxy | | Server | |client.source|----------->|proxy.example|--------->+hms.example| | .net | | .net | | .net | +-------------+ +-------------+ +-----------+ dest-host=3Dhms.example.net =20 dest-realm=3Dexample.net =20 Then whenever Client will look into the routing table based on realm (example.net), it can always route the message to redirect agent and not the Proxy Agent.=20 And hence will form a loop.=20 What shud be the solution to such kind of problem. What kind of check shud be there. =20 Check the brain of the person who configured it?=20 Regards,=20 Geetika *********************** Aricent- Confidential *********************** *********************** Aricent- Confidential *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. If you have received this message in error,=20 please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by this email including damage from virus." ------_=_NextPart_001_01C7B4ED.6BBFF46E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,

I have an understanding issue with the Redirect Agent. Referred = to=20 http://www1.tools.ietf.org/html/draft-tsou-dime-base-routing-ext-00=20

In the scenario where Redirect = and Proxy=20 agent are present in the same realm.


 =20  +------------------+
     |     = Diameter=20     |
     |  Redirect Agent =  |
 =20    |(agent.example.net)|
   =20  +------------------+
          ^ =  =20  |
          |    | Redirect=20 Indication
          |    |   = redirect-host=3Dhms.example.net
          | =  =20  |   redirect-realm=3DR-R:example.net
      =  =20   |    v
     +-------------+   =  =20        +-------------+        =20  +-----------+
     |  Client     = |  =20          |   Proxy     |   =  =20      | Server    |
   =20  |client.source|----------->|proxy.example|--------->+h= ms.example|
 =20    |   .net      |       =  =20    |    .net     |     =  =20    |   .net    |
   =20  +-------------+           =  +-------------+=20          +-----------+
      =  =20     dest-host=3Dhms.example.net    
  =    =20       dest-realm=3Dexample.net       =  =20


Then whenever = Client will=20 look into the routing table based on realm (example.net), it can always = route=20 the message to  redirect agent and not the Proxy Agent. =
And hence will form a loop. =

What shud be the solution to such kind of = problem. What=20 kind of check shud be there.  
Check=20 the brain of the person who configured = it? 


Regards,
Geetika

***********************  Aricent- = Confidential  =20 ***********************

***********************  Aricent-=20 Confidential   *********************** 
"DISCLAIMER: This =
message is proprietary to Aricent  and is intended solely for the use of =

the individual to whom it is addressed. It may contain privileged or =
confidential information and should not be=20
circulated or used for any purpose other than for what it is intended. =
If you have received this message in error,=20
please notify the originator immediately. If you are not the intended =
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of =
this message. Aricent accepts no responsibility for=20
loss or damage arising from the use of the information transmitted by =
this email including damage from virus."
------_=_NextPart_001_01C7B4ED.6BBFF46E-- --===============1960440993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1960440993==-- From dime-bounces@ietf.org Tue Jun 26 02:28:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I34Wx-0005vX-Bq; Tue, 26 Jun 2007 02:28:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I34Wv-0005vP-P7 for dime@ietf.org; Tue, 26 Jun 2007 02:28:01 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I34Wu-000673-Cd for dime@ietf.org; Tue, 26 Jun 2007 02:28:01 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK8001BRCLD0Z@szxga03-in.huawei.com> for dime@ietf.org; Tue, 26 Jun 2007 14:27:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK8006S2CLBB5@szxga03-in.huawei.com> for dime@ietf.org; Tue, 26 Jun 2007 14:27:13 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK800FSJCL7WX@szxml04-in.huawei.com> for dime@ietf.org; Tue, 26 Jun 2007 14:27:11 +0800 (CST) Date: Tue, 26 Jun 2007 14:27:07 +0800 From: Tony Zhang Subject: RE: [Dime] Problem with Redirect Agent In-reply-to: To: 'Geetika Gupta' , dime@ietf.org Message-id: <000001c7b7bb$05088400$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ace0yNQ0ukeMtiq2QhCYpN76lO/9XAC7oy4g X-Spam-Score: 0.0 (/) X-Scan-Signature: 142968907492cd6b805bce4edf0aec7b Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500591313==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1500591313== Content-type: multipart/alternative; boundary="Boundary_(ID_8lbmrPX8p8KITDKGVnhuag)" This is a multi-part message in MIME format. --Boundary_(ID_8lbmrPX8p8KITDKGVnhuag) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT On my understanding, the redirect new realm name is different name(just like the redirect host is new).: +------------------+ | Diameter | | Redirect Agent | |(agent.example.net)| +------------------+ ^ | | | Redirect Indication | | redirect-host=hms.new.net | | redirect-realm=new.net | v +-------------+ +-------------+ +-----------+ | Client | | Proxy | | Server | |client.source|----------->|proxy.new.net|--------->+hms.new.net| | .net | | . | | | +-------------+ +-------------+ +-----------+ dest-host=hms.new.net dest-realm=new.net _____ From: Geetika Gupta [mailto:geetika.gupta@aricent.com] Sent: Friday, June 22, 2007 8:32 PM To: dime@ietf.org Subject: [Dime] Problem with Redirect Agent Hi All, I have an understanding issue with the Redirect Agent. Referred to http://www1.tools.ietf.org/html/draft-tsou-dime-base-routing-ext-00 In the scenario where Redirect and Proxy agent are present in the same realm. +------------------+ | Diameter | | Redirect Agent | |(agent.example.net)| +------------------+ ^ | | | Redirect Indication | | redirect-host=hms.example.net | | redirect-realm=R-R:example.net | v +-------------+ +-------------+ +-----------+ | Client | | Proxy | | Server | |client.source|----------->|proxy.example|--------->+hms.example| | .net | | .net | | .net | +-------------+ +-------------+ +-----------+ dest-host=hms.example.net dest-realm=example.net Then whenever Client will look into the routing table based on realm (example.net), it can always route the message to redirect agent and not the Proxy Agent. And hence will form a loop. What shud be the solution to such kind of problem. What kind of check shud be there. Regards, Geetika *********************** Aricent- Confidential *********************** *********************** Aricent- Confidential *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." --Boundary_(ID_8lbmrPX8p8KITDKGVnhuag) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On my = understanding, =C2=A0the redirect new realm name is different name(just like the redirect host is = new).:

 <= /span>

   =C2=A0 +------------------+
     |     = Diameter     |
     |  Redirect = Agent  |
     |(agent.example.net)|
    =  +------------------+
          ^ =    |
          | =    | Redirect Indication
          | =    |   redirect-host=3Dhms.new.net
          | =    |   redirect-realm=3Dnew.net
          | =    v
     +-------------+ =            +-------------+          +-----------+
     |  Client   =   |            |   Proxy     | =          | Server    |
     |client.source|----------->|proxy.new.net|--------->+hms.new.net|
     |   .net   =    |            |    .=C2=A0 =C2=A0=C2=A0    = |          |   =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  =  |
     +-------------+ =            +-------------+          +-----------+
            dest-host=3Dhms.new.net    
            dest-realm=3Dnew.net       =  

 



=

From: Geetika Gupta [mailto:geetika.gupta@aricent.com]
Sent: Friday, June 22, = 2007 8:32 PM
To: dime@ietf.org
Subject: [Dime] Problem = with Redirect Agent

 


Hi All, =

I have an understanding issue with the Redirect = Agent. Referred to = http://www1.tools.ietf.org/html/draft-tsou-dime-base-routing-ext-00

In the scenario where Redirect and Proxy agent = are present in the same realm.


  =  =C2=A0 = +------------------+
     |     = Diameter     |
     |  Redirect = Agent  |
     |(agent.example.net)|
    =  +------------------+
          ^ =    |
          | =    | Redirect Indication
          | =    |   redirect-host=3Dhms.example.net
          | =    |   redirect-realm=3DR-R:example.net
          | =    v
     +-------------+ =            +-------------+          +-----------+
     |  Client   =   |            |   Proxy     | =          | Server    |
     |client.source|----------->|proxy.example|--------->+hms.example|
     |   .net   =    |            |    .net     |     =      |   .net    |
     +-------------+ =            +-------------+          +-----------+
            dest-host=3Dhms.example.net    
            dest-realm=3Dexample.net        


Then whenever Client will look into the routing = table based on realm (example.net), it can always route the message to =  redirect agent and not the Proxy Agent.
And hence will form a loop.

What shud be the solution to such kind of = problem. What kind of check shud be there.


Regards,
Geetika

***********************  Aricent- Confidential   ***********************

***********************  Aricent- Confidential   *********************** = 

"DISCLAIMER: This message is proprietary to =
Aricent=C2=A0 and is intended solely for the use of =

the individual to whom it is addressed. It may contain =
privileged or confidential information and should not be =

circulated or used for any purpose other than for what it =
is intended. If you have received this message in error, =

please notify the originator immediately. If you are not =
the intended recipient, you are notified that you are =
strictly
prohibited from using, copying, altering, or disclosing =
the contents of this message. Aricent accepts no responsibility for =

loss or damage arising from the use of the information =
transmitted by this email including damage from =
virus."

 

--Boundary_(ID_8lbmrPX8p8KITDKGVnhuag)-- --===============1500591313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1500591313==-- From dime-bounces@ietf.org Tue Jun 26 08:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3AEo-00039J-0j; Tue, 26 Jun 2007 08:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3AEm-00039B-RX for dime@ietf.org; Tue, 26 Jun 2007 08:33:40 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3AEi-0008VG-Dk for dime@ietf.org; Tue, 26 Jun 2007 08:33:40 -0400 Received: by ug-out-1314.google.com with SMTP id k3so164197ugf for ; Tue, 26 Jun 2007 05:33:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Z6tHFBXmrijUy1VIDivTFws7YPLBLAaRXvcXzHq95wiY/hBwmFbmDqdNMOQLa//WRXABC9ouScIiio3KvTRoKekZCMpcWGfCpNw4F5T1FLUhxIbSaEFWC7zDTzGc8ff7cwEfdj4CP5vK7r5vGX5h6mm6noCGHWyP3eU1YtZcDJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Om5IpzwyCxIVztqGztQ7g0rc/ToIM74/6Sq8DY6uvWSLCtkVZmbQqHccOszSViB1vDz3pAqripymPUu3B+F0fm4avUybqCqTV4pweNJp1cLgAUC6/bFp8PAZVQVfz9TMh7VEUC5Whas/GNAZcyBIKINzziNJ5T7jsINijspXpQs= Received: by 10.78.206.9 with SMTP id d9mr3068571hug.1182861214874; Tue, 26 Jun 2007 05:33:34 -0700 (PDT) Received: by 10.78.175.16 with HTTP; Tue, 26 Jun 2007 05:33:34 -0700 (PDT) Message-ID: Date: Tue, 26 Jun 2007 18:03:34 +0530 From: "naveen sarma" To: dime@ietf.org, dime-request@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Dime] Reg the Failed-AVP in CEA, DWA and DPA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0406951817==" Errors-To: dime-bounces@ietf.org --===============0406951817== Content-Type: multipart/alternative; boundary="----=_Part_9602_17780080.1182861214858" ------=_Part_9602_17780080.1182861214858 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, Can anyone explain the significance of the Failed-AVP in the CEA message. It is not mentioned in the RFC 3588 or 3588 4-bis, that if CER decoding fails, CEA should be sent with 'E' bit set with the corresponding failed AVP. Have one more question regarding the Failed-AVP in the DWA, DPA signatures; Its like *[Failed-AVP]. In the RFC 3588 or 3588 4-bis, its not mentioned when the base protocol need to set the Failed-AVP in the DWA, DPA messages? One more point is the probable action of an invalid Disconnect-Cause AVP value received in the DPR is not mentioned in the 3588 or 3588 4-bis. In such cases, does the base protocol need to retain the connection and send the DPA with 'E' bit set? Regards, Naveen. ------=_Part_9602_17780080.1182861214858 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,
 
Can anyone explain the significance of the Failed-AVP in the CEA message.  It is not mentioned in the RFC 3588 or 3588 4-bis, that if CER decoding fails, CEA should be sent with 'E' bit set with the corresponding failed AVP.

Have one more question regarding the Failed-AVP in the DWA, DPA signatures; Its like *[Failed-AVP].  In the RFC 3588 or 3588 4-bis, its not mentioned when the base protocol need to set the Failed-AVP in the DWA, DPA messages?
 
One more point is the probable action of an invalid Disconnect-Cause AVP value received in the DPR is not mentioned in the 3588 or 3588 4-bis.  In such cases, does the base protocol need to retain the connection and send the DPA with 'E' bit set? 
 
Regards,
Naveen.
------=_Part_9602_17780080.1182861214858-- --===============0406951817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0406951817==-- From dime-bounces@ietf.org Tue Jun 26 12:47:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ECn-0007n6-My; Tue, 26 Jun 2007 12:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ECm-0007ht-32; Tue, 26 Jun 2007 12:47:52 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ECI-0006cB-IH; Tue, 26 Jun 2007 12:47:52 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5QGkRAQ087455; Tue, 26 Jun 2007 12:46:27 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <468142DE.7010603@tari.toshiba.com> Date: Tue, 26 Jun 2007 12:46:22 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: naveen sarma Subject: Re: [Dime] Reg the Failed-AVP in CEA, DWA and DPA References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dime-request@ietf.org, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Naveen, > Hi all, > > Can anyone explain the significance of the Failed-AVP in the CEA > message. It is not mentioned in the RFC 3588 or 3588 4-bis, that if > CER decoding fails, CEA should be sent with 'E' bit set with the > corresponding failed AVP. > > Have one more question regarding the Failed-AVP in the DWA, DPA > signatures; Its like *[Failed-AVP]. In the RFC 3588 or 3588 4-bis, > its not mentioned when the base protocol need to set the Failed-AVP in > the DWA, DPA messages? It seems Sec 7. and 7.2 already covers this. Is there something unclear in those sections ? victor > > One more point is the probable action of an invalid Disconnect-Cause > AVP value received in the DPR is not mentioned in the 3588 or 3588 > 4-bis. In such cases, does the base protocol need to retain the > connection and send the DPA with 'E' bit set? > > Regards, > Naveen. > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 27 02:33:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3R5j-0005u7-T9; Wed, 27 Jun 2007 02:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3R5e-0005qy-VT for dime@ietf.org; Wed, 27 Jun 2007 02:33:24 -0400 Received: from ik-out-1112.google.com ([66.249.90.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3R5a-0000TS-1h for dime@ietf.org; Wed, 27 Jun 2007 02:33:22 -0400 Received: by ik-out-1112.google.com with SMTP id b32so42063ika for ; Tue, 26 Jun 2007 23:33:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=R4lSp9whx/eRE68i03C2NA0DNOqWAfw6XMVroJxv8Ak5dV8RzC3CoqTZxHwFeICjimIYB01GOU5JJyB2jqGhj14NnoDDM8HeqAlMKFItekcXzN4Jgtx5edLC9xtVmfER4N2Q39WDuPdCEC+KINBHGu61mX8HPhFHcFvQTEf3M/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tHyAug9Z0PC96nDwxT9mupgrt7uFezhO4O4daMTTdPD/7SuFAkW0dO64vcfo6MJuInF/siNdSuS70Ad2XHPV+4khyndHkfJiUNAQI+FJMQtal6CfiHZCvfp/jmqTwUGz+lSu0tJh4ycqwwcT0sabXYBzUkobrfaMPfxdNgs/Lrg= Received: by 10.78.130.6 with SMTP id c6mr62317hud.1182925997021; Tue, 26 Jun 2007 23:33:17 -0700 (PDT) Received: by 10.78.175.16 with HTTP; Tue, 26 Jun 2007 23:33:16 -0700 (PDT) Message-ID: Date: Wed, 27 Jun 2007 12:03:16 +0530 From: "naveen sarma" To: dime@ietf.org, dime-request@ietf.org Subject: Fwd: [Dime] Reg the Failed-AVP in CEA, DWA and DPA In-Reply-To: MIME-Version: 1.0 References: <468142DE.7010603@tari.toshiba.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1638268193==" Errors-To: dime-bounces@ietf.org --===============1638268193== Content-Type: multipart/alternative; boundary="----=_Part_16040_4992832.1182925996997" ------=_Part_16040_4992832.1182925996997 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Just forwarding to group... ---------- Forwarded message ---------- From: naveen sarma Date: Jun 27, 2007 12:01 PM Subject: Re: [Dime] Reg the Failed-AVP in CEA, DWA and DPA To: Victor Fajardo Hi Victor, The sections 7 and 7.2 discussed possible cases of using the Failed AVP in the protocol as well as application specific messages; with a phrase "In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation dependent order)." There are couple of points here: 1. Consider a scenario like if the CER is received from a known peer without the Host-Ip-Address AVP, which is not correct as per the ABNF signature. In this case, the receiver of CER will stop validating the whole CER message, because of the first error. In such case does the receiver of the CER needs to send CEA with Result-Code AVP set to DIAMETER_MISSING_AVP and Failed-AVP as Host-Ip-Address AVP (or) the CER is to be silently discarded and close the transport connection. This point is not clear in the RFC 3588 or 3588 4-bis. Can this be treated as base protocol implementation specific? If so there will be a problem in the interop. Even if the CEA has to be sent with the Failed-AVP, the receiver will always fills the first encountered error. So is the ABNF signature of CEA with *[Failed-AVP] correct? Since the Failed-AVP cannot be more than one, can we make it [Failed-AVP]? 2. The point that is not clear in the specs is that whether the receiver of the DWR and DPR needs to validate the Origin-Host and Origin-Realm AVP values? Since the messages are received from the established transport connection or from a peer with which capabilities are exchanged, can the receiver simply by-pass the validation of these AVPs values. If the receiver can by-pass the validation, there is no relevance of these AVPs in the corresponding ABNF signatures. If not, the specs can clearly mention what action does the receiver need to take if the validation fails. Can i know what the base protocol needs to do when the disconnect cause in the DPR is not valid also? Thanks & Regards, Naveen On 6/26/07, Victor Fajardo wrote: > > Hi Naveen, > > > Hi all, > > > > Can anyone explain the significance of the Failed-AVP in the CEA > > message. It is not mentioned in the RFC 3588 or 3588 4-bis, that if > > CER decoding fails, CEA should be sent with 'E' bit set with the > > corresponding failed AVP. > > > > Have one more question regarding the Failed-AVP in the DWA, DPA > > signatures; Its like *[Failed-AVP]. In the RFC 3588 or 3588 4-bis, > > its not mentioned when the base protocol need to set the Failed-AVP in > > the DWA, DPA messages? > > It seems Sec 7. and 7.2 already covers this. Is there something unclear > in those sections ? > > > victor > > > > > One more point is the probable action of an invalid Disconnect-Cause > > AVP value received in the DPR is not mentioned in the 3588 or 3588 > > 4-bis. In such cases, does the base protocol need to retain the > > connection and send the DPA with 'E' bit set? > > > > Regards, > > Naveen. > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > -- Yours Naveen. ------=_Part_16040_4992832.1182925996997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Just forwarding to group...

---------- Forwarded message ----------
From: naveen sarma <naveen.sarma@gmail.com >
Date: Jun 27, 2007 12:01 PM
Subject: Re: [Dime] Reg the Failed-AVP in CEA, DWA and DPA
To: Victor Fajardo <vfajardo@tari.toshiba.com>
Hi Victor,
 
The sections 7 and 7.2 discussed possible cases of using the Failed AVP in the protocol as well as application specific messages; with a phrase "In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation dependent order)."
 
There are couple of points here:
 
1.  Consider a scenario like if the CER is received from a known peer without the Host-Ip-Address AVP, which is not correct as per the ABNF signature.  In this case, the receiver of CER will stop validating the whole CER message, because of the first error.
 
In such case does the receiver of the CER needs to send CEA with Result-Code AVP set to DIAMETER_MISSING_AVP and Failed-AVP as Host-Ip-Address AVP (or) the CER is to be silently discarded and close the transport connection. This point is not clear in the RFC 3588 or 3588 4-bis.  Can this be treated as base protocol implementation specific?  If so there will be a problem in the interop.
 
Even if the CEA has to be sent with the Failed-AVP, the receiver will always fills the first encountered error.  So is the ABNF signature of CEA with *[Failed-AVP] correct?  Since the Failed-AVP cannot be more than one, can we make it [Failed-AVP]?
 
2.  The point that is not clear in the specs is that whether the receiver of the DWR and DPR needs to validate the Origin-Host and Origin-Realm AVP values?  Since the messages are received from the established transport connection or from a peer with which capabilities are exchanged, can the receiver simply by-pass the validation of these AVPs values.
 
If the receiver can by-pass the validation, there is no relevance of these AVPs in the corresponding ABNF signatures.  If not, the specs can clearly mention what action does the receiver need to take if the validation fails.
 
Can i know what the base protocol needs to do when the disconnect cause in the DPR is not valid also?
 
Thanks & Regards,
Naveen
 
On 6/26/07, Victor Fajardo <vfajardo@tari.toshiba.com > wrote:
Hi Naveen,

> Hi all,
>
> Can anyone explain the significance of the Failed-AVP in the CEA
> message.  It is not mentioned in the RFC 3588 or 3588 4-bis, that if
> CER decoding fails, CEA should be sent with 'E' bit set with the
> corresponding failed AVP.
>
> Have one more question regarding the Failed-AVP in the DWA, DPA
> signatures; Its like *[Failed-AVP].  In the RFC 3588 or 3588 4-bis,
> its not mentioned when the base protocol need to set the Failed-AVP in
> the DWA, DPA messages?

It seems Sec 7. and 7.2 already covers this. Is there something unclear
in those sections ?


victor

>
> One more point is the probable action of an invalid Disconnect-Cause
> AVP value received in the DPR is not mentioned in the 3588 or 3588
> 4-bis.  In such cases, does the base protocol need to retain the
> connection and send the DPA with 'E' bit set?
>
> Regards,
> Naveen.
> ------------------------------------------------------------------------
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>


--
Yours
Naveen. ------=_Part_16040_4992832.1182925996997-- --===============1638268193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1638268193==-- From dime-bounces@ietf.org Wed Jun 27 04:14:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Sf9-0000YP-1t; Wed, 27 Jun 2007 04:14:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Sf8-0000YJ-2q for dime@ietf.org; Wed, 27 Jun 2007 04:14:06 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3SeY-000369-Mb for dime@ietf.org; Wed, 27 Jun 2007 04:14:06 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 4CE2237C0E5; Wed, 27 Jun 2007 13:38:17 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid 8B2E437C25C; Wed, 27 Jun 2007 13:37:42 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 13:42:25 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Jun 2007 13:41:18 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601AA8EE5@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query on sctp transport Thread-Index: Ace4kr1mVuOZ2wpfT/GBO8rpv0Ynxw== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 27 Jun 2007 08:12:25.0102 (UTC) FILETIME=[E50E8AE0:01C7B892] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-8.7327 TC:1F TRN:30 TV:3.6.1039(15262.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Type: multipart/mixed; boundary="=_Boundary_yqa6eMDNNT47k4sI2yW4" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: diameter-developers@lists.sourceforge.net Subject: [Dime] Query on sctp transport X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --=_Boundary_yqa6eMDNNT47k4sI2yW4 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Query on sctp transport

Hi All,

    RFC says that the = diameter server should support SCTP transport. I need some input = regarding the SCTP socket type
    for diameter = protocol.

    Which socket type is = more suitable for diameter stack, One-to-one or  = one-to-many?

Thanks in advance,
Bala

--=_Boundary_yqa6eMDNNT47k4sI2yW4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- --=_Boundary_yqa6eMDNNT47k4sI2yW4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --=_Boundary_yqa6eMDNNT47k4sI2yW4-- From dime-bounces@ietf.org Wed Jun 27 08:49:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Wxt-00016T-7o; Wed, 27 Jun 2007 08:49:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Wxr-00016E-N1 for dime@ietf.org; Wed, 27 Jun 2007 08:49:43 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3Wxr-0004ZL-E6 for dime@ietf.org; Wed, 27 Jun 2007 08:49:43 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5RCms1G091365; Wed, 27 Jun 2007 08:48:54 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46825CB6.7070302@tari.toshiba.com> Date: Wed, 27 Jun 2007 08:48:54 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: naveen sarma Subject: Re: Fwd: [Dime] Reg the Failed-AVP in CEA, DWA and DPA References: <468142DE.7010603@tari.toshiba.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi naveen, > > The sections 7 and 7.2 discussed possible cases of using the Failed > AVP in the protocol as well as application specific messages; with a > phrase "In case there are multiple errors, the Diameter node MUST > report only the first error it encountered (detected possibly in some > implementation dependent order)." > > There are couple of points here: > > 1. Consider a scenario like if the CER is received from a known > peer without the Host-Ip-Address AVP, which is not correct as per the > ABNF signature. In this case, the receiver of CER will stop > validating the whole CER message, because of the first error. > > In such case does the receiver of the CER needs to send CEA with > Result-Code AVP set to DIAMETER_MISSING_AVP and Failed-AVP as > Host-Ip-Address AVP (or) the CER is to be silently discarded and close > the transport connection. This point is not clear in the RFC 3588 or > 3588 4-bis. Can this be treated as base protocol implementation > specific? If so there will be a problem in the interop. The first scenario you mentioned is probably more appropriate since the capability exchange does not specify anything that overrides the default error handling in sec 7. Sending an error answer is useful for debugging a connection. Also, AFAIK the bis only mentions silently discarding a CER from an unknown peer. > > 2. The point that is not clear in the specs is that whether the > receiver of the DWR and DPR needs to validate the Origin-Host and > Origin-Realm AVP values? Since the messages are received from the > established transport connection or from a peer with which > capabilities are exchanged, can the receiver simply by-pass the > validation of these AVPs values. Its probably up to your implementation if you want to skip value validation for these AVPs. > > If the receiver can by-pass the validation, there is no relevance of > these AVPs in the corresponding ABNF signatures. If not, the > specs can clearly mention what action does the receiver need to take > if the validation fails. > > Can i know what the base protocol needs to do when the disconnect > cause in the DPR is not valid also? Following the same error handling rules in sec 7 with INVALID_AVP_VALUE seems useful in this case. BTW, the peer fsm forces the receiver of the DPR to close the connection and move to closed state regardless. -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 27 14:54:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ceo-0003js-Vf; Wed, 27 Jun 2007 14:54:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3cen-0003eD-Ji for dime@ietf.org; Wed, 27 Jun 2007 14:54:25 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ceT-0005eO-Bs for dime@ietf.org; Wed, 27 Jun 2007 14:54:25 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1153264ugf for ; Wed, 27 Jun 2007 11:54:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eEJp73jnANSqjNE37aIBUdFLK9prkw49Gd7fhKuC/HIBXVNYmz2FCo+KOpNsp4ZkLGrjd5KDkFZ2XX2eNwYAQ9Sl6TdVwf47EBbn9JnoaHcVSas67JUMctmGSLQDtvAn+mpOY8s4XbbT15JWWx3Fhhwt1m5nClijktzy/Imgo7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=k7cJx2qwULciR6Vlhx6KEYZio8r6YxHpr1bV2vZpZAvfMIKW/m8HKG86oGx+oIEi/h80q6xELpSGEWHysZEMoXeMqIgffmbJdZThKq4SjtZFy0I72mdKPEVP81SUDYCkf1NccPzyNIp1A6dXEwwFs2CAXXREuV+sCRZiLpbS6EE= Received: by 10.78.131.8 with SMTP id e8mr462190hud.1182970443933; Wed, 27 Jun 2007 11:54:03 -0700 (PDT) Received: by 10.78.175.16 with HTTP; Wed, 27 Jun 2007 11:54:03 -0700 (PDT) Message-ID: Date: Thu, 28 Jun 2007 00:24:03 +0530 From: "naveen sarma" To: "Victor Fajardo" Subject: Re: Fwd: [Dime] Reg the Failed-AVP in CEA, DWA and DPA In-Reply-To: <46825CB6.7070302@tari.toshiba.com> MIME-Version: 1.0 References: <468142DE.7010603@tari.toshiba.com> <46825CB6.7070302@tari.toshiba.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0649088775==" Errors-To: dime-bounces@ietf.org --===============0649088775== Content-Type: multipart/alternative; boundary="----=_Part_21675_17662908.1182970443906" ------=_Part_21675_17662908.1182970443906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Victor, I just want to know few things... On 6/27/07, Victor Fajardo wrote: > > Hi naveen, > > > > The sections 7 and 7.2 discussed possible cases of using the Failed > > AVP in the protocol as well as application specific messages; with a > > phrase "In case there are multiple errors, the Diameter node MUST > > report only the first error it encountered (detected possibly in some > > implementation dependent order)." > > > > There are couple of points here: > > > > 1. Consider a scenario like if the CER is received from a known > > peer without the Host-Ip-Address AVP, which is not correct as per the > > ABNF signature. In this case, the receiver of CER will stop > > validating the whole CER message, because of the first error. > > > > In such case does the receiver of the CER needs to send CEA with > > Result-Code AVP set to DIAMETER_MISSING_AVP and Failed-AVP as > > Host-Ip-Address AVP (or) the CER is to be silently discarded and close > > the transport connection. This point is not clear in the RFC 3588 or > > 3588 4-bis. Can this be treated as base protocol implementation > > specific? If so there will be a problem in the interop. > > The first scenario you mentioned is probably more appropriate since the > capability exchange does not specify anything that overrides the default > error handling in sec 7. Sending an error answer is useful for debugging > a connection. Also, AFAIK the bis only mentions silently discarding a > CER from an unknown peer. > > > 2. The point that is not clear in the specs is that whether the > > receiver of the DWR and DPR needs to validate the Origin-Host and > > Origin-Realm AVP values? Since the messages are received from the > > established transport connection or from a peer with which > > capabilities are exchanged, can the receiver simply by-pass the > > validation of these AVPs values. > > Its probably up to your implementation if you want to skip value > validation for these AVPs. Naveen >>> If this is implementation specific, and no usage as far as the base protocol is concerned, i see no usage of these AVPs in the signatures. Is there any other usage? > > > If the receiver can by-pass the validation, there is no relevance of > > these AVPs in the corresponding ABNF signatures. If not, the > > specs can clearly mention what action does the receiver need to take > > if the validation fails. > > > > Can i know what the base protocol needs to do when the disconnect > > cause in the DPR is not valid also? > > Following the same error handling rules in sec 7 with INVALID_AVP_VALUE > seems useful in this case. BTW, the peer fsm forces the receiver of the > DPR to close the connection and move to closed state regardless. Naveen >>> In such case does the receiver need to attempt the re-connection or not? -- victor > > -- Yours Naveen. ------=_Part_21675_17662908.1182970443906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Victor,
 
I just want to know few things...

 
On 6/27/07, Victor Fajardo <vfajardo@tari.toshiba.com> wrote:
Hi naveen,
>
> The sections 7 and 7.2 discussed possible cases of using the Failed
> AVP in the protocol as well as application specific messages; with a
> phrase "In case there are multiple errors, the Diameter node MUST
> report only the first error it encountered (detected possibly in some
> implementation dependent order)."
>
> There are couple of points here:
>
> 1.  Consider a scenario like if the CER is received from a known
> peer without the Host-Ip-Address AVP, which is not correct as per the
> ABNF signature.  In this case, the receiver of CER will stop
> validating the whole CER message, because of the first error.
>
> In such case does the receiver of the CER needs to send CEA with
> Result-Code AVP set to DIAMETER_MISSING_AVP and Failed-AVP as
> Host-Ip-Address AVP (or) the CER is to be silently discarded and close
> the transport connection. This point is not clear in the RFC 3588 or
> 3588 4-bis.  Can this be treated as base protocol implementation
> specific?  If so there will be a problem in the interop.

The first scenario you mentioned is probably more appropriate since the
capability exchange does not specify anything that overrides the default
error handling in sec 7. Sending an error answer is useful for debugging
a connection. Also, AFAIK the bis only mentions silently discarding a
CER from an unknown peer.

>
> 2.  The point that is not clear in the specs is that whether the
> receiver of the DWR and DPR needs to validate the Origin-Host and
> Origin-Realm AVP values?  Since the messages are received from the
> established transport connection or from a peer with which
> capabilities are exchanged, can the receiver simply by-pass the
> validation of these AVPs values.

Its probably up to your implementation if you want to skip value
validation for these AVPs.
 
Naveen >>> If this is implementation specific, and no usage as far as the base protocol is concerned, i see no usage of these AVPs in the signatures.  Is there any other usage?

>
> If the receiver can by-pass the validation, there is no relevance of
> these AVPs in the corresponding ABNF signatures.  If not, the
> specs can clearly mention what action does the receiver need to take
> if the validation fails.
>
> Can i know what the base protocol needs to do when the disconnect
> cause in the DPR is not valid also?

Following the same error handling rules in sec 7 with INVALID_AVP_VALUE
seems useful in this case. BTW, the peer fsm forces the receiver of the
DPR to close the connection and move to closed state regardless.
 
Naveen >>> In such case does the receiver need to attempt the re-connection or not?

-- victor




--
Yours
Naveen. ------=_Part_21675_17662908.1182970443906-- --===============0649088775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0649088775==-- From dime-bounces@ietf.org Wed Jun 27 16:23:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3e3M-0003bT-6p; Wed, 27 Jun 2007 16:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3e3K-0003bF-QK for dime@ietf.org; Wed, 27 Jun 2007 16:23:50 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3e2k-00048H-JN for dime@ietf.org; Wed, 27 Jun 2007 16:23:50 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5RKMKEb093634; Wed, 27 Jun 2007 16:22:20 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4682C6FC.4010800@tari.toshiba.com> Date: Wed, 27 Jun 2007 16:22:20 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: naveen sarma Subject: Re: Fwd: [Dime] Reg the Failed-AVP in CEA, DWA and DPA References: <468142DE.7010603@tari.toshiba.com> <46825CB6.7070302@tari.toshiba.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi naveen, > > > Its probably up to your implementation if you want to skip value > validation for these AVPs. > > > Naveen >>> If this is implementation specific, and no usage as far > as the base protocol is concerned, i see no usage of these AVPs in the > signatures. Is there any other usage? The use is when implementations does the right thing and validate the value for the AVPs. Its up to your implementation if it wants to do the right thing. > Following the same error handling rules in sec 7 with > INVALID_AVP_VALUE > seems useful in this case. BTW, the peer fsm forces the receiver > of the > DPR to close the connection and move to closed state regardless. > > > Naveen >>> In such case does the receiver need to attempt the > re-connection or not? This is a policy decision from your implementation/deployment. --victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 28 11:01:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vUs-0001V2-0a; Thu, 28 Jun 2007 11:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vUp-0001UP-SN for dime@ietf.org; Thu, 28 Jun 2007 11:01:24 -0400 Received: from mu-out-0910.google.com ([209.85.134.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3vUg-0007CA-Nl for dime@ietf.org; Thu, 28 Jun 2007 11:01:23 -0400 Received: by mu-out-0910.google.com with SMTP id w8so658755mue for ; Thu, 28 Jun 2007 08:01:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DAo9ZnoX6PGmmgO6ZpDnjYZfZLnKAsNf8q4B2R6S4s8nqMuCVqXussFAfPflf5uegD+wJqw4sazMx/2D3vOylZd+eKFettsTBNjkTbpY40poSMFIUXVplNKSsrF41QX/WljmMkUlt6FgTPe4Cj2cSzlD7cx+4A6wlEm6VidYN5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=X8AHSQvCkO9H5g2R4wcYSE+zLqM1ls2dof7cEbKhoy9pvXRKEu+CbCI6xzASknLefN1m9qlaGjbuDFKsy0cJPvIco/LHTTDaKU3yejQiNpV2TrN2A0P3UPlx8yibwMBfbT/JqsTrhMrGKXYlI9xgjlvp97jPqtSTp9i4oyUcTcg= Received: by 10.82.158.12 with SMTP id g12mr3944007bue.1183042873266; Thu, 28 Jun 2007 08:01:13 -0700 (PDT) Received: by 10.82.105.16 with HTTP; Thu, 28 Jun 2007 08:01:13 -0700 (PDT) Message-ID: Date: Thu, 28 Jun 2007 20:31:13 +0530 From: "harish raghuveer" To: "Victor Fajardo" Subject: Re: Fwd: [Dime] Reg the Failed-AVP in CEA, DWA and DPA In-Reply-To: <4683A8BC.5020804@tari.toshiba.com> MIME-Version: 1.0 References: <468142DE.7010603@tari.toshiba.com> <46825CB6.7070302@tari.toshiba.com> <4683A8BC.5020804@tari.toshiba.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0181307459==" Errors-To: dime-bounces@ietf.org --===============0181307459== Content-Type: multipart/alternative; boundary="----=_Part_52384_30941942.1183042873236" ------=_Part_52384_30941942.1183042873236 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline CC'ing to mailing list. I am in favor of closing the connection in case of invalid DPR. :-) cheers, Harish On 6/28/07, Victor Fajardo wrote: > > Hi, > > > > I feel that the peer FSM should not close the connection and move to > > closed state if the Origin-Host and Origin-Realm is incorrect in > > DPR. If we do this, how do we know if the DPR originated at the > > 'legal' or 'valid' transport end-point (if there is no end-to-end > > security as well)? > > It is also possible that if a peer receives a DPR with an invalid value > for origin-host and/or origin-realm, it sends a an answer with an error > then close the connection. This is a lot safer than waiting for a DPR > with a correct value on an already open transport connection. An invalid > DPR can only mean that the peer is already malfunctioning or doing some > malicious attack; in both cases, how can we trust it to eventually send > a valid DPR. Besides, that peer is already implying that it wants to > close the connection (even though its not very good at it) ... so why > waste resources and keep an open connection waiting for the peer to > correct itself. BTW, this will not involved end-to-end security, only > peer based security. > > > > > If the validation of these AVPs is 'optional' then they should > > be 'informational' AVPs rather than 'mandatory AVPs' in all the > > messages other than CER/CEA. > > I would dis-agree. First, it is there for a reason. Second, you will be > breaking a many many existing implementations that is actually able to > follow the spec properly. > > regards, > victor > > -- Harish R Prabhu Ph:98457-34737 (M) ------=_Part_52384_30941942.1183042873236 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline CC'ing to mailing list. I am in favor of closing the connection in case of invalid DPR. :-)

cheers,
Harish

On 6/28/07, Victor Fajardo < vfajardo@tari.toshiba.com> wrote:
Hi,
>
> I feel that the peer FSM should not close the connection and move to
> closed state if the Origin-Host and Origin-Realm is incorrect in
> DPR. If we do this, how do we know if the DPR originated at the
> 'legal' or 'valid' transport end-point (if there is no end-to-end
> security as well)?

It is also possible that if a peer receives a DPR with an invalid value
for origin-host and/or origin-realm, it sends a an answer with an error
then close the connection. This is a lot safer than waiting for a DPR
with a correct value on an already open transport connection. An invalid
DPR can only mean that the peer is already malfunctioning or doing some
malicious attack; in both cases, how can we trust it to eventually send
a valid DPR. Besides, that peer is already implying that it wants to
close the connection (even though its not very good at it) ... so why
waste resources and keep an open connection waiting for the peer to
correct itself. BTW, this will not involved end-to-end security, only
peer based security.

>
> If the validation of these AVPs is 'optional' then they should
> be 'informational' AVPs rather than 'mandatory AVPs' in all the
> messages other than CER/CEA.

I would dis-agree. First, it is there for a reason. Second, you will be
breaking a many many existing implementations that is actually able to
follow the spec properly.

regards,
victor




--
Harish R Prabhu
Ph:98457-34737 (M) ------=_Part_52384_30941942.1183042873236-- --===============0181307459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0181307459==-- From dime-bounces@ietf.org Fri Jun 29 14:10:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4KvI-0001oj-KW; Fri, 29 Jun 2007 14:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4KvH-0001oe-Sj for dime@ietf.org; Fri, 29 Jun 2007 14:10:23 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Kv8-0001kf-Kt for dime@ietf.org; Fri, 29 Jun 2007 14:10:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jun 2007 14:10:11 -0400 Message-ID: From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Subject: [Dime] Review of draft-ietf-dime-app-design-guide-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Victor, Tolga, Hannes, Glenn, John, I finally got around to reviewing this important draft and my comments/ questions are below. Please note that I'm on vacation next week so I'll respond to emails the week after (July 9th). Thanks for initiating this draft. I am optimistic that the other SDOs will embrace it and review their future specs for compliance. I will certainly be pushing for compliance in the groups where I participate. Regards Mark --- General comment: I found the structure a little confusing at times, e.g. sections on extending applications contain guidance on new applications. I would like to suggest the following re-org: 1. Introduction 2. Rules for Reuse 2.1 Application Reuse Adding Commands Deleting Commands 2.2 Command Reuse Adding AVPs (mandatory vs optiona) Deleting AVPs 2.3 AVP Reuse Adding values Deleting values 3. Rules on introducing new elements 3.1 Rules for new applications Justifying allocation of Application-Id Use of Application-Id in a Message Application Specific Session Statemachine 3.2 Rules for new commands 3.3 Rules for new AVPs 4. Other design considerations 4.1 Diameter Account Support 4.2 Generic Diameter Extensions 4.3 Updating an existing Application 4.4 System Architecture and Deployment 5. IANA Considerations 6. Security Considerations 7. Acknowledgements 8. References =09 Comments on specific sections: Abstract -------- Is the draft only going to focus on clarifying existing rules in the Base rfc? I think we're adding some new rules too, e.g. AVP/command deletion. Will these rules need to be propagated to a 3588bis? 1. Introduction --------------- The draft provides guidance on the decisions to define new AVP values, new AVPs and new commands. Not just new applications as suggested in this section. 4. Rules on Diameter Extensibility ---------------------------------- I suggest rewording "Defining a new Diameter application can be done by:" to "Mapping a new application to the Diameter protocol can be done by:". Extending an existing application --------------------------------- Typo in first sentence. It should read "In this case, the requirements of the new application are not completely unique and there are existing applications ..." If I choose to reuse an existing application, do I have to implement all commands even though they may not be used in the new application? I would expect the answer to be yes otherwise you've effectively deleted a command and so created a new application. Correct? 4.1 Rules on Extending Existing Applications -------------------------------------------- To my understanding the rules for extending an application are fairly restrictive: Existing applications can only be extended by the addition of non-mandatory AVPs to existing commands or adding values to existing AVPs (providing they don't change the AVP semantics). If correct, this rule should be stated somewhere in this section. Adding an AVP to a command ABNF of an existing application ---------------------------------------------------------- I suggest explicitly stating the rule in the first paragraph: a mandatory AVP can not be added to (or deleted from) an existing command. I like the list of questions to help qualify whether an AVP is mandatory but a summary statement would help: "If one or more of the above conditions are true, the AVP is considered mandatory". Adding a new AVP value to an existing AVP=20 ----------------------------------------- There are a couple of typos in the subsection title: should start with "Adding" instead of "Add"; "to an" is repeated. Need to explicitly state what "rule applies" since it may not be obvious to the reader: A new value can only be added to an existing AVP if it does not change the semantics of the AVP.=20 =09 Add a command to an existing application ---------------------------------------- Again need to state what "rule applies" here: to my understanding, a command can not be added to an existing application regardless of whether it is a new command or reused from another application. --- I also have suggestions for a couple of new sections. If you agree they are useful, I could provide a first draft.=20 AVP datatype rules ------------------ If appropriate derived AVP data format exists, it SHOULD be used instead of the base type, i.e. if you're transporting an IP address, use the "Address" data type instead of some new encoding as Octet String. Datatype use should be consistent across an application. Reuse of derived AVP data formats defined in existing IETF applications is encouraged. Guidelines for SDOs ------------------- I think we have three types of groups that extend Diameter: . IETF . Other SDOs . Vendors >From a protocol extensibility perspective the other SDOs are treated as vendors. However, the SDOs do have interoperability concerns that a single vendor does not. I think it would be useful to offer them some general advice: . Follow the IETF reuse guidelines for their own applications, commands and AVPs. . Determine the level of internal policing required for assignments (First come, first served vs Expert Review). Obviously these are over and above any IANA requirements. . Consider assigning an internal expert body to review SDO application, command, AVP and value use. . If an internal expert body is not available, consider publishing application as an IETF draft and requesting DIME WG review. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 29 14:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4L03-0007f0-OL; Fri, 29 Jun 2007 14:15:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4L02-0007eu-JT for dime@ietf.org; Fri, 29 Jun 2007 14:15:18 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4L02-0004Su-5L for dime@ietf.org; Fri, 29 Jun 2007 14:15:18 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5TIEa3V002748 for ; Fri, 29 Jun 2007 14:14:36 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46854C0C.3090007@tari.toshiba.com> Date: Fri, 29 Jun 2007 14:14:36 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/mixed; boundary="------------040604010205060300090104" X-Spam-Score: 0.1 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Subject: [Dime] [Fwd: Re: Review of draft-ietf-dime-app-design-guide-01.txt] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --------------040604010205060300090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------040604010205060300090104 Content-Type: message/rfc822; name="Re: Review of draft-ietf-dime-app-design-guide-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: Review of draft-ietf-dime-app-design-guide-01.txt" X-Account-Key: account5 Return-Path: Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5TG0kmW002256 for ; Fri, 29 Jun 2007 12:00:47 -0400 (EDT) (envelope-from john.loughney@nokia.com) X-VirusChecked: Checked X-Env-Sender: john.loughney@nokia.com X-Msg-Ref: server-13.tower-129.messagelabs.com!1183132837!5079422!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [131.228.20.171] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 24547 invoked from network); 29 Jun 2007 16:00:39 -0000 Received: from smtp.nokia.com (HELO mgw-ext12.nokia.com) (131.228.20.171) by server-13.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 29 Jun 2007 16:00:39 -0000 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5TG0GZk002961; Fri, 29 Jun 2007 19:00:18 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 19:00:17 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:00:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Review of draft-ietf-dime-app-design-guide-01.txt Date: Fri, 29 Jun 2007 11:00:14 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A3C0348@daebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-dime-app-design-guide-01.txt Thread-Index: Ace6XchqjXo1IEWEQFiWDRTe8PZitgACBzMg References: From: To: , , , , X-OriginalArrivalTime: 29 Jun 2007 16:00:15.0380 (UTC) FILETIME=[95128D40:01C7BA66] X-Nokia-AV: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by toshi17.tari.toshiba.com id l5TG0kmW002256 Mark, Do you mind if we forward your comments to the DiME mailing list? Comments in-line. >-----Original Message----- >From: ext Mark Jones [mailto:mark.jones@bridgewatersystems.com] >Sent: 29 June, 2007 07:55 >To: vfajardo@tari.toshiba.com; tasveren@sonusnet.com; >Tschofenig Hannes (NSN DE/Muenchen); glenn@aaa.lucent.com; >Loughney John (Nokia-NRC/PaloAlto) >Subject: Review of draft-ietf-dime-app-design-guide-01.txt > >Victor, Tolga, Hannes, Glenn, John, > >I finally got around to reviewing this important draft and my >comments/ questions are below. Please note that I'm on >vacation next week so I'll respond to emails the week after (July 9th). > >Thanks for initiating this draft. I am optimistic that the >other SDOs will embrace it and review their future specs for >compliance. I will certainly be pushing for compliance in the >groups where I participate. > >Regards >Mark > >--- > >General comment: I found the structure a little confusing at times, e.g. >sections on extending applications contain guidance on new applications. >I would like to suggest the following re-org: > >1. Introduction > >2. Rules for Reuse >2.1 Application Reuse > Adding Commands > Deleting Commands >2.2 Command Reuse > Adding AVPs (mandatory vs optiona) > Deleting AVPs >2.3 AVP Reuse > Adding values > Deleting values > >3. Rules on introducing new elements >3.1 Rules for new applications > Justifying allocation of Application-Id > Use of Application-Id in a Message > Application Specific Session Statemachine >3.2 Rules for new commands >3.3 Rules for new AVPs > >4. Other design considerations >4.1 Diameter Account Support >4.2 Generic Diameter Extensions >4.3 Updating an existing Application >4.4 System Architecture and Deployment > >5. IANA Considerations >6. Security Considerations >7. Acknowledgements >8. References That seems reasonable, anyone else have thoughts? >Comments on specific sections: > >Abstract >-------- > >Is the draft only going to focus on clarifying existing rules >in the Base rfc? I think we're adding some new rules too, e.g. >AVP/command deletion. Will these rules need to be propagated >to a 3588bis? I would think so. >1. Introduction >--------------- > >The draft provides guidance on the decisions to define new AVP >values, new AVPs and new commands. Not just new applications >as suggested in this section. OK >4. Rules on Diameter Extensibility >---------------------------------- > >I suggest rewording "Defining a new Diameter application can >be done by:" to "Mapping a new application to the Diameter >protocol can be done by:". OK >Extending an existing application >--------------------------------- > >Typo in first sentence. It should read "In this case, the >requirements of the new application are not completely unique >and there are existing applications ..." > >If I choose to reuse an existing application, do I have to >implement all commands even though they may not be used in the >new application? I would expect the answer to be yes otherwise >you've effectively deleted a command and so created a new >application. Correct? > >4.1 Rules on Extending Existing Applications >-------------------------------------------- > >To my understanding the rules for extending an application are fairly >restrictive: Existing applications can only be extended by the >addition of non-mandatory AVPs to existing commands or adding >values to existing AVPs (providing they don't change the AVP >semantics). If correct, this rule should be stated somewhere >in this section. OK. >Adding an AVP to a command ABNF of an existing application >---------------------------------------------------------- > >I suggest explicitly stating the rule in the first paragraph: >a mandatory AVP can not be added to (or deleted from) an >existing command. > > >I like the list of questions to help qualify whether an AVP is >mandatory but a summary statement would help: "If one or more >of the above conditions are true, the AVP is considered mandatory". OK >Adding a new AVP value to an existing AVP >----------------------------------------- > >There are a couple of typos in the subsection title: should >start with "Adding" instead of "Add"; "to an" is repeated. > >Need to explicitly state what "rule applies" since it may not >be obvious to the reader: A new value can only be added to an >existing AVP if it does not change the semantics of the AVP. > >Add a command to an existing application >---------------------------------------- > >Again need to state what "rule applies" here: to my >understanding, a command can not be added to an existing >application regardless of whether it is a new command or >reused from another application. OK >--- > >I also have suggestions for a couple of new sections. If you >agree they are useful, I could provide a first draft. > >AVP datatype rules >------------------ > >If appropriate derived AVP data format exists, it SHOULD be >used instead of the base type, i.e. if you're transporting an >IP address, use the "Address" data type instead of some new >encoding as Octet String. > >Datatype use should be consistent across an application. Reuse >of derived AVP data formats defined in existing IETF >applications is encouraged. That makes sense. > >Guidelines for SDOs >------------------- > >I think we have three types of groups that extend Diameter: > . IETF > . Other SDOs > . Vendors > >From a protocol extensibility perspective the other SDOs are >treated as vendors. However, the SDOs do have interoperability >concerns that a single vendor does not. I think it would be >useful to offer them some general advice: > > . Follow the IETF reuse guidelines for their own >applications, commands and AVPs. > . Determine the level of internal policing required for >assignments (First come, first served vs Expert Review). >Obviously these are over and above any IANA requirements. > . Consider assigning an internal expert body to review >SDO application, command, AVP and value use. > . If an internal expert body is not available, consider >publishing application as an IETF draft and requesting DIME WG review. SDOs unfortunately, don't have a special status inside the IETF. I was bugging some people on the IESG about this at some point, but nothing happened. --------------040604010205060300090104 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --------------040604010205060300090104-- From dime-bounces@ietf.org Fri Jun 29 14:44:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LSY-0005cw-3R; Fri, 29 Jun 2007 14:44:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LSW-0005bV-Pw for dime@ietf.org; Fri, 29 Jun 2007 14:44:44 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4LSW-0006HM-Cp for dime@ietf.org; Fri, 29 Jun 2007 14:44:44 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l5TIi6LU002839; Fri, 29 Jun 2007 14:44:06 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <468552F6.7050709@tari.toshiba.com> Date: Fri, 29 Jun 2007 14:44:06 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Review of draft-ietf-dime-app-design-guide-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mark, Many thanks for the review. Comments inline: > > General comment: I found the structure a little confusing at times, e.g. > sections on extending applications contain guidance on new applications. > I would like to suggest the following re-org: > > 1. Introduction > > 2. Rules for Reuse > 2.1 Application Reuse > Adding Commands > Deleting Commands > 2.2 Command Reuse > Adding AVPs (mandatory vs optiona) > Deleting AVPs > 2.3 AVP Reuse > Adding values > Deleting values > > 3. Rules on introducing new elements > 3.1 Rules for new applications > Justifying allocation of Application-Id > Use of Application-Id in a Message > Application Specific Session Statemachine > 3.2 Rules for new commands > 3.3 Rules for new AVPs > > 4. Other design considerations > 4.1 Diameter Account Support > 4.2 Generic Diameter Extensions > 4.3 Updating an existing Application > 4.4 System Architecture and Deployment > > 5. IANA Considerations > 6. Security Considerations > 7. Acknowledgements > 8. References > Sounds good. > > Comments on specific sections: > > Abstract > -------- > > Is the draft only going to focus on clarifying existing rules in the > Base rfc? I think we're adding some new rules too, e.g. AVP/command > deletion. Will these rules need to be propagated to a 3588bis? > Yes some of the new rules have been propagated to bis-04. > 1. Introduction > --------------- > > The draft provides guidance on the decisions to define new AVP values, > new AVPs and new commands. Not just new applications as suggested in > this section. > Ok. > 4. Rules on Diameter Extensibility > ---------------------------------- > > I suggest rewording "Defining a new Diameter application can be done > by:" to "Mapping a new application to the Diameter protocol can be done > by:". > Ok. > Extending an existing application > --------------------------------- > > Typo in first sentence. It should read "In this case, the requirements > of the new application are not completely unique and there are existing > applications ..." > Ok. > If I choose to reuse an existing application, do I have to implement all > commands even though they may not be used in the new application? I > would expect the answer to be yes otherwise you've effectively deleted a > command and so created a new application. Correct? > Good question. In general, yes I think this is true. Others may have additional comments. > 4.1 Rules on Extending Existing Applications > -------------------------------------------- > > To my understanding the rules for extending an application are fairly > restrictive: Existing applications can only be extended by the addition > of non-mandatory AVPs to existing commands or adding values to existing > AVPs (providing they don't change the AVP semantics). If correct, this > rule should be stated somewhere in this section. > Ok. > Adding an AVP to a command ABNF of an existing application > ---------------------------------------------------------- > > I suggest explicitly stating the rule in the first paragraph: a > mandatory AVP can not be added to (or deleted from) an existing command. > Ok. > > I like the list of questions to help qualify whether an AVP is mandatory > but a summary statement would help: "If one or more of the above > conditions are true, the AVP is considered mandatory". > Ok. > Adding a new AVP value to an existing AVP > ----------------------------------------- > > There are a couple of typos in the subsection title: should start with > "Adding" instead of "Add"; "to an" is repeated. > > Need to explicitly state what "rule applies" since it may not be obvious > to the reader: A new value can only be added to an existing AVP if it > does not change the semantics of the AVP. > Ok. > > Add a command to an existing application > ---------------------------------------- > > Again need to state what "rule applies" here: to my understanding, a > command can not be added to an existing application regardless of > whether it is a new command or reused from another application. > Ok. > --- > > I also have suggestions for a couple of new sections. If you agree they > are useful, I could provide a first draft. > > AVP datatype rules > ------------------ > > If appropriate derived AVP data format exists, it SHOULD be used instead > of the base type, i.e. if you're transporting an IP address, use the > "Address" data type instead of some new encoding as Octet String. > > Datatype use should be consistent across an application. Reuse of > derived AVP data formats defined in existing IETF applications is > encouraged. > > This is useful. We can integrate your draft when ready. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 29 15:12:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LtO-00031Z-8S; Fri, 29 Jun 2007 15:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LtM-0002yB-9y for dime@ietf.org; Fri, 29 Jun 2007 15:12:28 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Lsr-0001Er-Fn for dime@ietf.org; Fri, 29 Jun 2007 15:12:28 -0400 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l5TJBu1d027999; Fri, 29 Jun 2007 15:11:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-ietf-dime-app-design-guide-01.txt Date: Fri, 29 Jun 2007 15:11:56 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188006@sonusmail04.sonusnet.com> In-Reply-To: <468552F6.7050709@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-app-design-guide-01.txt Thread-Index: Ace6fZRSktjVa+4tQTKJdeDNgrWu6AAAu1Kg References: <468552F6.7050709@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" , "Mark Jones" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor/Mark, >=20 > > If I choose to reuse an existing application, do I have to implement all > > commands even though they may not be used in the new application? I > > would expect the answer to be yes otherwise you've effectively deleted a > > command and so created a new application. Correct? > > >=20 > Good question. In general, yes I think this is true. Others may have > additional comments. [TOLGA]I think this is true for AVPs with M-bit set. I guess one of the reasons for confusions about Diameter extensibility is that people are focusing to message definitions only syntactically rather than semantically as well. If a node advertises an Application-Id, this means that it is not only ready to parse the message somehow, but also that it is ready to execute all the associated mandatory semantics. This means that it should know how to process the AVPs with M-bit set. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime