From dime-bounces@ietf.org Fri Oct 3 06:34:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9668F3A69A6; Fri, 3 Oct 2008 06:34:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501263A6452 for ; Fri, 3 Oct 2008 06:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2m-hHUIpRBY for ; Fri, 3 Oct 2008 06:34:36 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 0298628C0EE for ; Fri, 3 Oct 2008 06:34:35 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA06.westchester.pa.mail.comcast.net with comcast id NBVn1a0030ldTLk56Db4UM; Fri, 03 Oct 2008 13:35:04 +0000 Received: from gwzPC ([124.120.223.242]) by OMTA04.westchester.pa.mail.comcast.net with comcast id NDaD1a00K5EQVu43QDahVo; Fri, 03 Oct 2008 13:34:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=7-SZVKRP0IYA:10 a=E4VBmqM_aYIA:10 a=vvtxif4SU1OUXqJDmMQA:9 a=QaE1woHI4tuLUUG5OxkA:7 a=YRSoS9TC9rgwiBIIz2EE1XyvAnEA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=yrqZJK_-PtxMGgl7afsA:9 a=K4CMtUXk39mkTbJMCmMA:7 a=ZdaGJGfjDta_ABp6K7BX_vk19HUA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Vipul2 Aggarwal'" References: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> In-Reply-To: <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> Date: Fri, 3 Oct 2008 20:33:46 +0700 Message-ID: <003f01c9255c$b83c0550$28b40ff0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackf6r2CTjhNsmWtRpCMN2LFXF81zAAASOdgAVwTaLA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============2061307743==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============2061307743== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C92597.649ADD50" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0040_01C92597.649ADD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, As far as I know, there is no RAR message in Sh Interface. As far as I know, there is no Sh Interface in Diameter. Seriously, if you guys can't figure out how your own "standards" work that's a shame but it doesn't make it a part of the work of the either the IETF or the dime WG. The messages supported in Sh Interface are UDR/UDA PUR/PUA SNR/SNA PNR/PNA All these messages use the application ID of Sh. Can you please elaborate more on the context of RAR in the Sh interface? Regds, Vipul Aggarwal Senior Software Engineer A R I C E N T The Presidency Tower-A 351/2, Sector 14, M.G Road Gurgaon, 122001, Haryana, India _____ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Bartosz Baranowski Sent: Friday, September 26, 2008 8:45 PM To: dime@ietf.org Subject: [Dime] Application ID, Session Id and message flows Hi Im trying to figure few things out for some time now and up until now I have been hearing contradicting voices wherever I turn myself. I would like to know what are values of ApplicationID set in messages - Base messages used in context of Sh interface to Authanticate/Authorize user? Lets consider flow like follows (not sure if its valid or not): CLIENT SERVER(HSS ?) | ------------- UDR -----------------> | SesssionId_1, AppId_1 ==Sh X | <----------- RAR ------------------- | SessionId_2, AppId_2= Base | ------------- RAA -----------------> | SessionId_2, AppId_2= Base | ------------- UDR -----------------> | SesssionId_1, AppId_1 ==Sh | <----------- UDA -------------------- | SesssionId_1, AppId_1 ==Sh Does X indicates UDA denying access? Is SessionId_1 equal to SessionId_2? Is AppId_2== Base or is it equal to AppId_2 ? Thanks _____ "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." ------=_NextPart_000_0040_01C92597.649ADD50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As far as I know, there is no RAR message in Sh = Interface.

As far as I know, there is no Sh Interface in = Diameter.   Seriously, if you guys can't figure out how your own = "standards" work that's a shame but it doesn't make it a part of the work of the either = the IETF or the dime WG.

The messages supported in Sh Interface = are

UDR/UDA

PUR/PUA

SNR/SNA

PNR/PNA

 

All these messages use the application ID of = Sh.

 

Can you please elaborate more on the context of RAR in the = Sh interface?

 

Regds,

Vipul Aggarwal

Senior Software Engineer

 

A R I C E N T

 

The Presidency Tower-A

351/2, Sector 14, M.G Road

Gurgaon, 122001,  Haryana, = India

 

From:= dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Bartosz Baranowski
Sent: Friday, September 26, 2008 8:45 PM
To: dime@ietf.org
Subject: [Dime] Application ID, Session Id and message = flows

 

Hi
Im trying to figure few things out for some time now and up until now I = have been hearing contradicting voices wherever I turn myself.
I would like to know what are values of ApplicationID set in messages - = Base messages used in context of Sh interface to Authanticate/Authorize = user?

Lets consider flow like follows (not sure if its valid or not):




CLIENT           &= nbsp;           &n= bsp;

       SERVER(HSS = ?)
     | -------------    UDR = -----------------> |            =             &= nbsp;    SesssionId_1, AppId_1 =3D=3DSh
            &= nbsp;           &n= bsp;  X
     | <-----------    RAR ------------------- = |            =             &= nbsp;    SessionId_2, AppId_2=3D Base
     | -------------    RAA -----------------> |            =             &= nbsp;    SessionId_2, AppId_2=3D Base
     | -------------    UDR -----------------> |            =             &= nbsp;    SesssionId_1, AppId_1 =3D=3DSh
     | <-----------   UDA = -------------------- |            =             &= nbsp;    SesssionId_1, AppId_1 =3D=3DSh


Does X indicates UDA denying access?
Is SessionId_1 equal to SessionId_2?
Is AppId_2=3D=3D Base or is it equal to AppId_2 ?


Thanks

 

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

------=_NextPart_000_0040_01C92597.649ADD50-- --===============2061307743== 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://www.ietf.org/mailman/listinfo/dime --===============2061307743==-- From dime-bounces@ietf.org Fri Oct 3 06:37:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EEA43A69FB; Fri, 3 Oct 2008 06:37:13 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C013A69F6 for ; Fri, 3 Oct 2008 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z73R4q8Z80eA for ; Fri, 3 Oct 2008 06:37:10 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 5D12C28C281 for ; Fri, 3 Oct 2008 06:36:32 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA02.westchester.pa.mail.comcast.net with comcast id NAZd1a0060ldTLk52DcbAv; Fri, 03 Oct 2008 13:36:35 +0000 Received: from gwzPC ([124.120.223.242]) by OMTA04.westchester.pa.mail.comcast.net with comcast id NDc11a0015EQVu43QDcZzR; Fri, 03 Oct 2008 13:36:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=7-SZVKRP0IYA:10 a=E4VBmqM_aYIA:10 a=48vgC7mUAAAA:8 a=mfxeJJ8n0G9URTuWEe8A:9 a=KixsmemFOw1YYKB4jgoA:7 a=qGkHDlidVV9-A4nttZUK_iGfW-MA:4 a=VRKwbjqsiJ4A:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=birkmQ2h4YEA:10 From: "Glen Zorn" To: "'Hannes Tschofenig'" , "'Bartosz Baranowski'" References: <13c12d6b0809260815n3c769414tf97ff0d0c1c8ac23@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE4411A@GUREXMB01.ASIAN.AD.ARICENT.COM> <13c12d6b0809260844s281521e4tfe007acb0b2c30d5@mail.gmail.com> <2644750229D3DC4896C04587BF628046021CE44125@GUREXMB01.ASIAN.AD.ARICENT.COM> <13c12d6b0809261048u24d144cgb036d8a43f5f4487@mail.gmail.com> <48DD291D.10800@gmx.net> In-Reply-To: <48DD291D.10800@gmx.net> Date: Fri, 3 Oct 2008 20:35:34 +0700 Message-ID: <004401c9255c$fa7c9f60$ef75de20$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckgBUa13DrbrR8NSc+RRKmByWSxwgFV4MjQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Application ID, Session Id and message flows X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Is there any way that we can stop this incessant 3GPP spam? > A well written IETF document must describe the Application ID setting > for the messages an application uses. > > Bartosz Baranowski wrote: > > Hi > > Thanks, this clears my mind - should be mentioned in TS or rfc. > > > > On Fri, Sep 26, 2008 at 6:03 PM, Vipul2 Aggarwal > > > > wrote: > > > > Hi, > > > > > > > > You are right. There is no re-authentication scenario in Sh. > > > > > > > > Yes, there are interfaces (like NASReq, EAP, Wm, Rx, that I am > > aware of) that use base messages. But, these interfaces use their > > own application ID in these messages i.e. they don't use the > > application ID of Base (i.e. 0) in the messages. > > > > > > > > For e.g. NASReq interface uses the messages STR/STA, RAR/RAA, > > ASR/ASA. But, the application ID that goes in these messages is > > that of NASReq (i.e. 1). > > > > > > > > Hope this helps. > > > > Regds, > > > > *Vipul Aggarwal* > > > > Senior Software Engineer > > > > > > > > *A R I C E N T* > > > > > > > > The Presidency Tower-A > > > > 351/2, Sector 14, M.G Road > > > > Gurgaon, 122001, Haryana, India > > > > > > > > ----------------------------------------------------------------- > ------- > > > > *From:* Bartosz Baranowski [mailto:baranowb@gmail.com > > ] > > *Sent:* Friday, September 26, 2008 9:14 PM > > *To:* Vipul2 Aggarwal > > *Cc:* dime@ietf.org > > *Subject:* Re: [Dime] Application ID, Session Id and message > flows > > > > > > > > Hi > > Thanks for such quick answer. > > See inline > > > > On Fri, Sep 26, 2008 at 5:29 PM, Vipul2 Aggarwal > > > > > wrote: > > > > Hi, > > > > > > > > As far as I know, there is no RAR message in Sh Interface. > > > > Yes I know, there is no such message in Sh defined > > > > The messages supported in Sh Interface are > > > > UDR/UDA > > > > PUR/PUA > > > > SNR/SNA > > > > PNR/PNA > > > > > > > > All these messages use the application ID of Sh. > > > > Someone just threw example of Sh scenario where server reqeust > > authentication - I didnt find anything about that in TS, rfc or > > google, neither I was able to find any example scenarios (of any > > kind, not regardign this particular case), so I have decided to > > post here. > > Up until now I was sure that there is not authentication in Sh > > scenarios, or is there? > > Is there any case of application that uses base messages? I mean > > there is no app id in Base, this would indicate that all > > aplication have to support those? > > > > Can you please elaborate more on the context of RAR in the Sh > > interface? > > > > > > > > Regds, > > > > *Vipul Aggarwal* > > > > Senior Software Engineer > > > > > > > > *A R I C E N T* > > > > > > > > The Presidency Tower-A > > > > 351/2, Sector 14, M.G Road > > > > Gurgaon, 122001, Haryana, India > > > > > > > > ------------------------------------------------------------- > ----------- > > > > *From:* dime-bounces@ietf.org > > [mailto:dime-bounces@ietf.org ] > > *On Behalf Of *Bartosz Baranowski > > *Sent:* Friday, September 26, 2008 8:45 PM > > *To:* dime@ietf.org > > *Subject:* [Dime] Application ID, Session Id and message > flows > > > > > > > > Hi > > > > > > Im trying to figure few things out for some time now and up > > until now I have been hearing contradicting voices wherever I > > turn myself. > > I would like to know what are values of ApplicationID set in > > messages - Base messages used in context of Sh interface to > > Authanticate/Authorize user? > > > > Lets consider flow like follows (not sure if its valid or > not): > > > > > > > > > > CLIENT > > > > SERVER(HSS ?) > > | ------------- UDR -----------------> > > | SesssionId_1, AppId_1 ==Sh > > X > > | <----------- RAR ------------------- > > | SessionId_2, AppId_2= Base > > | ------------- RAA -----------------> > > | SessionId_2, AppId_2= Base > > | ------------- UDR -----------------> > > | SesssionId_1, AppId_1 ==Sh > > | <----------- UDA -------------------- > > | SesssionId_1, AppId_1 ==Sh > > > > > > Does X indicates UDA denying access? > > Is SessionId_1 equal to SessionId_2? > > Is AppId_2== Base or is it equal to AppId_2 ? > > > > > > Thanks > > > > > > > > ------------------------------------------------------------- > ----------- > > > > "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://www.ietf.org/mailman/listinfo/dime > > > > > > > > > > -- > > Bartosz Baranowski > > JBoss R & D > > ================================== > > Word of criticism meant to improve is always step forward. > > > > > > ----------------------------------------------------------------- > ------- > > "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." > > > > > > > > > > -- > > Bartosz Baranowski > > JBoss R & D > > ================================== > > Word of criticism meant to improve is always step forward. > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 8 11:29:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB573A6847; Wed, 8 Oct 2008 11:29:44 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130523A6847 for ; Wed, 8 Oct 2008 11:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-aeOsJUETYa for ; Wed, 8 Oct 2008 11:29:42 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id 2A28F3A6765 for ; Wed, 8 Oct 2008 11:29:41 -0700 (PDT) Received: from [10.10.10.162] (12-187-205-3.att-inc.com [12.187.205.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id D39CF216C53 for ; Wed, 8 Oct 2008 21:29:39 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: To: dime@ietf.org From: Jouni Korhonen Date: Wed, 8 Oct 2008 21:29:27 +0300 X-Mailer: Apple Mail (2.753.1) Subject: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, The -12 revision of 3588bis still allows and actually gives an example of using "* { AVP }", which in my opinion does not make sense. Should we add a note under section 3.2 qual description stating that "* { AVP }" is not possible based on the description of a required AVP? I would add the following text to qual description: "If a required rule has a qualifier, then the value of min MUST be 1 if present." If the above is acceptable, then we need to fix the example following the ABNF definitions: The following is a definition of a fictitious command code: Example-Request ::= < Diameter Header: 9999999, REQ, PXY > { User-Name } * { Origin-Host } ^^^^ * [ AVP ] Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 8 11:37:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BF23A6847; Wed, 8 Oct 2008 11:37:02 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78453A6847 for ; Wed, 8 Oct 2008 11:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi-vJWAlzRnk for ; Wed, 8 Oct 2008 11:37:01 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id 110143A67DF for ; Wed, 8 Oct 2008 11:37:01 -0700 (PDT) Received: from [10.10.10.162] (12-187-205-3.att-inc.com [12.187.205.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 2CFBA139773 for ; Wed, 8 Oct 2008 21:37:28 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: References: Message-Id: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> From: Jouni Korhonen Date: Wed, 8 Oct 2008 21:37:18 +0300 To: dime@ietf.org X-Mailer: Apple Mail (2.753.1) Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org A copy'n'paste typo. meant: "If a required rule has a qualifier, then the value of min MUST be 1." Jouni On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > Hi all, > > The -12 revision of 3588bis still allows and actually gives an > example of using "* { AVP }", which in my opinion does not make > sense. Should we add a note under section 3.2 qual description > stating that "* { AVP }" is not possible based on the description > of a required AVP? I would add the following text to qual description: > > "If a required rule has a qualifier, then the value of min > MUST be 1 if present." > > If the above is acceptable, then we need to fix the example > following the ABNF definitions: > > The following is a definition of a fictitious command code: > > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > { User-Name } > * { Origin-Host } > ^^^^ > * [ AVP ] > > > Cheers, > Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 8 11:58:53 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208CA3A6956; Wed, 8 Oct 2008 11:58:53 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161EE3A6956 for ; Wed, 8 Oct 2008 11:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.963 X-Spam-Level: X-Spam-Status: No, score=-4.963 tagged_above=-999 required=5 tests=[AWL=1.636, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNs8BTa9wW+v for ; Wed, 8 Oct 2008 11:58:51 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 022563A6832 for ; Wed, 8 Oct 2008 11:58:50 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m98IxVf0016242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 8 Oct 2008 20:59:31 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m98IxV9X004138 for ; Wed, 8 Oct 2008 20:59:31 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Oct 2008 20:59:31 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Oct 2008 20:59:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Oct 2008 21:59:30 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The M-bit MAY column issue Thread-Index: Ackpd/5Cd/WNG0FkRyeWMRY55W7ezw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 08 Oct 2008 18:59:31.0215 (UTC) FILETIME=[FEF5F9F0:01C92977] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081008205931-40306BB0-D4759F87/0-0/0-15 X-purgate-size: 1058/0 Subject: [Dime] The M-bit MAY column issue X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, the M-bit setting in an AVP indicates what the receiving side has to understand. From an implementation point of view there are only these two options: * I have to implement the AVP. * I don't have to implement it. It's optional. For the sending side the ABNF tells what the sender has to put into a command (with some additional constraints). When one restricts the M-bit setting to -- MUST and -- MUST NOT then the semantic regarding what has to be implemented and understood is essentially determined at the time when the specification was written and this raises the question about why that information is carried in the protocol itself (rather than just written in the specification very much like the ABNF is). Some folks in the past suggested to remove the MAY option of the M-bit. My question is: Why is the M-bit flag in the AVP needed at all? Why don't we replace it with a table in the document that says which AVPs must get implemented and which others are optional? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 8 12:03:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40963A6B26; Wed, 8 Oct 2008 12:03:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4253A6B26 for ; Wed, 8 Oct 2008 12:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10FvuLk0tiJE for ; Wed, 8 Oct 2008 12:03:48 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id DB09D3A6966 for ; Wed, 8 Oct 2008 12:03:47 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 21:03:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Oct 2008 21:03:35 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98E7@ftrdmel2> In-Reply-To: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] comment on ABNFs in 3588bis Thread-Index: AckpdPaO3AbgKY6/TnGcJIVKj/gLgAAAR4jA References: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> From: To: , X-OriginalArrivalTime: 08 Oct 2008 19:03:37.0835 (UTC) FILETIME=[91F533B0:01C92978] Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Ok with that. The "min" must be equal to 1 for Required AVP. By the way, about the given example, is it really possible to have multiple= Origin-host AVP in the same request, according to the definition of the Or= igin-host AVP? on the same topic, is it possible to have several occurrences of a fixed AV= P? If not, either another note should be added to state that: "If an fixed rule has a = qualifier, then the value of min and max MUST be 1." Or remove the [qual] before "<" avp-spec ">" to have: Fixed =3D [qual] "<" = avp-spec ">" Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De = > la part de Jouni Korhonen > Envoy=E9 : mercredi 8 octobre 2008 20:37 > =C0 : dime@ietf.org > Objet : Re: [Dime] comment on ABNFs in 3588bis > = > A copy'n'paste typo. meant: > = > "If a required rule has a qualifier, then the value of min = > MUST be 1." > = > Jouni > = > = > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > = > > Hi all, > > > > The -12 revision of 3588bis still allows and actually gives = > an example = > > of using "* { AVP }", which in my opinion does not make = > sense. Should = > > we add a note under section 3.2 qual description stating = > that "* { AVP = > > }" is not possible based on the description of a required = > AVP? I would = > > add the following text to qual description: > > > > "If a required rule has a qualifier, then the value of min > > MUST be 1 if present." > > > > If the above is acceptable, then we need to fix the example = > following = > > the ABNF definitions: > > > > The following is a definition of a fictitious command code: > > > > Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > > > { User-Name } > > * { Origin-Host } > > ^^^^ > > * [ AVP ] > > > > > > Cheers, > > Jouni > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > = > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 8 12:53:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B383A69A4; Wed, 8 Oct 2008 12:53:28 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F7A3A690D for ; Wed, 8 Oct 2008 12:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy7qZYb3jSvg for ; Wed, 8 Oct 2008 12:53:26 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 48CE03A69A4 for ; Wed, 8 Oct 2008 12:53:26 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 21:53:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Oct 2008 21:53:36 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98EA@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] The M-bit MAY column issue Thread-Index: Ackpd/5Cd/WNG0FkRyeWMRY55W7ezwAA69tw References: From: To: , X-OriginalArrivalTime: 08 Oct 2008 19:53:39.0276 (UTC) FILETIME=[8EF4C0C0:01C9297F] Subject: Re: [Dime] The M-bit MAY column issue X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org For me, the use of the M-bit allows to "optionally" send any AVPs in a give= n command and to be sure that these AVPs will not be simply ignored if not = understood. If you want to remove the M-bit, you will have to specify per command in th= e same table: *All the AVPs that will be always present in the command (i.e. fixed and re= quired AVP) *All the AVPs that may be added in the command and must not be ignored if n= ot supported *Any other AVP that may be present in the command and may be ignored if not= supported. I think it would be easier to keep the M-bit flag as it is. I'm assuming that the majority of the AVPs used in a given application will= have a fixed setting of the M-bit (set or cleared) - that could be stated = some where... If still required, it would be however possible to indicate that a specific= AVP would have "always" the M-bit set except in such or such a command. Th= at means that this clarification would be needed only for these specific AV= Ps. Lionel = > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De = > la part de Tschofenig, Hannes (NSN - FI/Espoo) > Envoy=E9 : mercredi 8 octobre 2008 21:00 > =C0 : dime@ietf.org > Objet : [Dime] The M-bit MAY column issue > = > Hi all, = > = > the M-bit setting in an AVP indicates what the receiving side = > has to understand. From an implementation point of view there = > are only these two options: = > * I have to implement the AVP. > * I don't have to implement it. It's optional. = > = > For the sending side the ABNF tells what the sender has to = > put into a command (with some additional constraints). = > = > When one restricts the M-bit setting to > -- MUST and > -- MUST NOT > then the semantic regarding what has to be implemented and = > understood is essentially determined at the time when the = > specification was written and this raises the question about = > why that information is carried in the protocol itself = > (rather than just written in the specification very much like = > the ABNF is). > = > Some folks in the past suggested to remove the MAY option of = > the M-bit. > My question is: Why is the M-bit flag in the AVP needed at = > all? Why don't we replace it with a table in the document = > that says which AVPs must get implemented and which others = > are optional? = > = > Ciao > Hannes > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 8 23:02:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1883A69ED; Wed, 8 Oct 2008 23:02:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B773A69ED for ; Wed, 8 Oct 2008 23:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.135 X-Spam-Level: X-Spam-Status: No, score=-0.135 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCiUNWQSaq2P for ; Wed, 8 Oct 2008 23:02:48 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 3E4483A69EC for ; Wed, 8 Oct 2008 23:02:48 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id QW1Z1a0030EPchoA1W2uJi; Thu, 09 Oct 2008 06:02:54 +0000 Received: from gwzPC ([124.120.224.99]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id QW2U1a00729HfoC8MW31pS; Thu, 09 Oct 2008 06:03:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=VueOUM1eYMUA:10 a=48vgC7mUAAAA:8 a=hMdjXtSdW9EjDz2ABsUA:9 a=-5jb1F-qOWkcg8GrKxwA:7 a=zRjsESbI0npgpLlzxFdWz-1wiEUA:4 a=lZB815dzVvQA:10 a=cPiQg-nXjNYA:10 a=LY0hPdMaydYA:10 From: "Glen Zorn" To: , , References: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98E7@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98E7@ftrdmel2> Date: Thu, 9 Oct 2008 13:01:38 +0700 Message-ID: <00ac01c929d4$903f6890$b0be39b0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckpdPaO3AbgKY6/TnGcJIVKj/gLgAAAR4jAABeIbBA= Content-language: en-us Cc: dime@ietf.org Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On a related but more general note: is are the ABNF definitions really useful? From the traffic on this list, it seems that they cause more trouble than anything else... > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > lionel.morand@orange-ftgroup.com > Sent: Thursday, October 09, 2008 2:04 AM > To: jouni.korhonen@iki.fi; dime@ietf.org > Subject: Re: [Dime] comment on ABNFs in 3588bis > = > Ok with that. The "min" must be equal to 1 for Required AVP. > = > By the way, about the given example, is it really possible to have > multiple Origin-host AVP in the same request, according to the > definition of the Origin-host AVP? > = > on the same topic, is it possible to have several occurrences of a > fixed AVP? If not, > = > either another note should be added to state that: "If an fixed rule > has a qualifier, then the value of min and max MUST be 1." > = > Or remove the [qual] before "<" avp-spec ">" to have: Fixed =3D [qual] > "<" avp-spec ">" > = > Lionel > = > > -----Message d'origine----- > > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De > > la part de Jouni Korhonen > > Envoy=E9 : mercredi 8 octobre 2008 20:37 > > =C0 : dime@ietf.org > > Objet : Re: [Dime] comment on ABNFs in 3588bis > > > > A copy'n'paste typo. meant: > > > > "If a required rule has a qualifier, then the value of min > > MUST be 1." > > > > Jouni > > > > > > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > > > > > Hi all, > > > > > > The -12 revision of 3588bis still allows and actually gives > > an example > > > of using "* { AVP }", which in my opinion does not make > > sense. Should > > > we add a note under section 3.2 qual description stating > > that "* { AVP > > > }" is not possible based on the description of a required > > AVP? I would > > > add the following text to qual description: > > > > > > "If a required rule has a qualifier, then the value of min > > > MUST be 1 if present." > > > > > > If the above is acceptable, then we need to fix the example > > following > > > the ABNF definitions: > > > > > > The following is a definition of a fictitious command code: > > > > > > Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > > > > { User-Name } > > > * { Origin-Host } > > > ^^^^ > > > * [ AVP ] > > > > > > > > > Cheers, > > > Jouni > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 08:34:54 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F305D28C0EF; Thu, 9 Oct 2008 08:34:53 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257E628C0EF for ; Thu, 9 Oct 2008 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdVXP2aKJv0m for ; Thu, 9 Oct 2008 08:34:52 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 3061E3A6C82 for ; Thu, 9 Oct 2008 08:34:52 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 9 Oct 2008 11:35:09 -0400 From: Mark Jones To: "dime@ietf.org" , Jouni Korhonen Date: Thu, 9 Oct 2008 11:35:08 -0400 Thread-Topic: [Dime] comment on ABNFs in 3588bis Thread-Index: AckpdRPPZAfpJM5tR4GcF1LnOFZzjwArLGMg Message-ID: References: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> In-Reply-To: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, I'd always assumed that a required AVP would have a minimum occurrence of one but I agree that it should be explicit in the ABNF description. An alternative change to 3588bis that probably has less impact on existing specs would be: min = 1*DIGIT ; The minimum number of times the element may ; be present. The default value is zero for ; fixed and optional rules. The default value ; is one for required rules. Then we don't have to change any *{ avp } in existing specs. Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Jouni Korhonen > Sent: October 8, 2008 11:37 > To: dime@ietf.org > Subject: Re: [Dime] comment on ABNFs in 3588bis > > A copy'n'paste typo. meant: > > "If a required rule has a qualifier, then the value of min MUST be > 1." > > Jouni > > > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > > > Hi all, > > > > The -12 revision of 3588bis still allows and actually gives an > > example of using "* { AVP }", which in my opinion does not make > > sense. Should we add a note under section 3.2 qual description > > stating that "* { AVP }" is not possible based on the description > > of a required AVP? I would add the following text to qual > description: > > > > "If a required rule has a qualifier, then the value of min > > MUST be 1 if present." > > > > If the above is acceptable, then we need to fix the example > > following the ABNF definitions: > > > > The following is a definition of a fictitious command code: > > > > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > > { User-Name } > > * { Origin-Host } > > ^^^^ > > * [ AVP ] > > > > > > Cheers, > > Jouni > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 08:57:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F473A6A63; Thu, 9 Oct 2008 08:57:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A0A3A6A63 for ; Thu, 9 Oct 2008 08:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7imFYEnE0U4 for ; Thu, 9 Oct 2008 08:57:51 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 3F0373A6A3F for ; Thu, 9 Oct 2008 08:57:51 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 17:58:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 17:58:07 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3031A276C@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] comment on ABNFs in 3588bis Thread-Index: AckpdRPPZAfpJM5tR4GcF1LnOFZzjwArLGMgAAFm0YA= From: To: , X-OriginalArrivalTime: 09 Oct 2008 15:58:12.0359 (UTC) FILETIME=[D5120970:01C92A27] Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, Works for me! However, I think we still need to state that min value of 0 is not allowed at all for required rules: min = 1*DIGIT ; The minimum number of times the element may ; be present. The default value is zero for ; fixed and optional rules. The default value ; is one for required rules. The value of zero ; is not allowed for required rules. Cheers, Jouni > > Hi Jouni, > > I'd always assumed that a required AVP would have a minimum > occurrence of one but I agree that it should be explicit in > the ABNF description. > > An alternative change to 3588bis that probably has less > impact on existing specs would be: > > min = 1*DIGIT > ; The minimum number of times the element may > ; be present. The default value is zero for > ; fixed and optional rules. The default value > ; is one for required rules. > > Then we don't have to change any *{ avp } in existing specs. > > Regards > Mark > > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > On Behalf > > Of Jouni Korhonen > > Sent: October 8, 2008 11:37 > > To: dime@ietf.org > > Subject: Re: [Dime] comment on ABNFs in 3588bis > > > > A copy'n'paste typo. meant: > > > > "If a required rule has a qualifier, then the value of > min MUST be > > 1." > > > > Jouni > > > > > > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > > > > > Hi all, > > > > > > The -12 revision of 3588bis still allows and actually gives an > > > example of using "* { AVP }", which in my opinion does not make > > > sense. Should we add a note under section 3.2 qual description > > > stating that "* { AVP }" is not possible based on the > description of > > > a required AVP? I would add the following text to qual > > description: > > > > > > "If a required rule has a qualifier, then the value of min > > > MUST be 1 if present." > > > > > > If the above is acceptable, then we need to fix the example > > > following the ABNF definitions: > > > > > > The following is a definition of a fictitious command code: > > > > > > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > > > { User-Name } > > > * { Origin-Host } > > > ^^^^ > > > * [ AVP ] > > > > > > > > > Cheers, > > > Jouni > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 08:58:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1A23A68FF; Thu, 9 Oct 2008 08:58:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A23A3A68FF for ; Thu, 9 Oct 2008 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gMTBMQdheQd for ; Thu, 9 Oct 2008 08:58:46 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id F36FC3A6863 for ; Thu, 9 Oct 2008 08:58:45 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 9 Oct 2008 11:59:21 -0400 From: Mark Jones To: "lionel.morand@orange-ftgroup.com" , "dime@ietf.org" Date: Thu, 9 Oct 2008 11:59:19 -0400 Thread-Topic: [Dime] comment on ABNFs in 3588bis Thread-Index: AckpdPaO3AbgKY6/TnGcJIVKj/gLgAAAR4jAACutwXA= Message-ID: References: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98E7@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98E7@ftrdmel2> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Lionel, Comments inline... > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of lionel.morand@orange-ftgroup.com > Sent: October 8, 2008 12:04 > To: jouni.korhonen@iki.fi; dime@ietf.org > Subject: Re: [Dime] comment on ABNFs in 3588bis > > Ok with that. The "min" must be equal to 1 for Required AVP. > > By the way, about the given example, is it really possible to > have multiple Origin-host AVP in the same request, according > to the definition of the Origin-host AVP? > Well, it is a ficticious example :) . But I agree it looks weird so maybe w= e could replace Origin-Host with Host-IP-Address. > on the same topic, is it possible to have several occurrences > of a fixed AVP? If not, > > either another note should be added to state that: "If an > fixed rule has a qualifier, then the value of min and max MUST be 1." > I understand that the current ABNF intentionally allows optional fixed AVPs= , i.e. the AVP is optional but if present then it MUST be in this position.= I've never seen one but I suppose it could happen. > Or remove the [qual] before "<" avp-spec ">" to have: Fixed =3D > [qual] "<" avp-spec ">" > > Lionel > > > -----Message d'origine----- > > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De > > la part de Jouni Korhonen > > Envoy=E9 : mercredi 8 octobre 2008 20:37 > > =C0 : dime@ietf.org > > Objet : Re: [Dime] comment on ABNFs in 3588bis > > > > A copy'n'paste typo. meant: > > > > "If a required rule has a qualifier, then the value of min > > MUST be 1." > > > > Jouni > > > > > > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > > > > > Hi all, > > > > > > The -12 revision of 3588bis still allows and actually gives > > an example > > > of using "* { AVP }", which in my opinion does not make > > sense. Should > > > we add a note under section 3.2 qual description stating > > that "* { AVP > > > }" is not possible based on the description of a required > > AVP? I would > > > add the following text to qual description: > > > > > > "If a required rule has a qualifier, then the value of min > > > MUST be 1 if present." > > > > > > If the above is acceptable, then we need to fix the example > > following > > > the ABNF definitions: > > > > > > The following is a definition of a fictitious command code: > > > > > > Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > > > > { User-Name } > > > * { Origin-Host } > > > ^^^^ > > > * [ AVP ] > > > > > > > > > Cheers, > > > Jouni > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 09:01:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BFF28C0EF; Thu, 9 Oct 2008 09:01:25 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A30528C0EF for ; Thu, 9 Oct 2008 09:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfg7aPz0wOHK for ; Thu, 9 Oct 2008 09:01:23 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 9F63D3A686D for ; Thu, 9 Oct 2008 09:01:23 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 9 Oct 2008 12:02:06 -0400 From: Mark Jones To: "jouni.korhonen@teliasonera.com" , "dime@ietf.org" Date: Thu, 9 Oct 2008 12:02:05 -0400 Thread-Topic: [Dime] comment on ABNFs in 3588bis Thread-Index: AckpdRPPZAfpJM5tR4GcF1LnOFZzjwArLGMgAAFm0YAAADEAYA== Message-ID: References: <59D7431DE2527D4CB0F1EFEDA5683ED3031A276C@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3031A276C@SEHAN021MB.tcad.telia.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Oops! Yes, I agree that your clause is also required here. Mark > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: October 9, 2008 08:58 > To: Mark Jones; dime@ietf.org > Subject: RE: [Dime] comment on ABNFs in 3588bis > > Hi Mark, > > Works for me! However, I think we still need to state that min > value of 0 is not allowed at all for required rules: > > min = 1*DIGIT > ; The minimum number of times the element may > ; be present. The default value is zero for > ; fixed and optional rules. The default value > ; is one for required rules. The value of zero > ; is not allowed for required rules. > > > Cheers, > Jouni > > > > > > Hi Jouni, > > > > I'd always assumed that a required AVP would have a minimum > > occurrence of one but I agree that it should be explicit in > > the ABNF description. > > > > An alternative change to 3588bis that probably has less > > impact on existing specs would be: > > > > min = 1*DIGIT > > ; The minimum number of times the element may > > ; be present. The default value is zero for > > ; fixed and optional rules. The default value > > ; is one for required rules. > > > > Then we don't have to change any *{ avp } in existing specs. > > > > Regards > > Mark > > > > > -----Original Message----- > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > > On Behalf > > > Of Jouni Korhonen > > > Sent: October 8, 2008 11:37 > > > To: dime@ietf.org > > > Subject: Re: [Dime] comment on ABNFs in 3588bis > > > > > > A copy'n'paste typo. meant: > > > > > > "If a required rule has a qualifier, then the value of > > min MUST be > > > 1." > > > > > > Jouni > > > > > > > > > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > > > > > > > Hi all, > > > > > > > > The -12 revision of 3588bis still allows and actually gives an > > > > example of using "* { AVP }", which in my opinion does not make > > > > sense. Should we add a note under section 3.2 qual description > > > > stating that "* { AVP }" is not possible based on the > > description of > > > > a required AVP? I would add the following text to qual > > > description: > > > > > > > > "If a required rule has a qualifier, then the value of min > > > > MUST be 1 if present." > > > > > > > > If the above is acceptable, then we need to fix the example > > > > following the ABNF definitions: > > > > > > > > The following is a definition of a fictitious command code: > > > > > > > > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > > > > { User-Name } > > > > * { Origin-Host } > > > > ^^^^ > > > > * [ AVP ] > > > > > > > > > > > > Cheers, > > > > Jouni > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 09:16:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A083A6AC9; Thu, 9 Oct 2008 09:16:05 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71C13A6863 for ; Thu, 9 Oct 2008 09:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwqL8nE9OxiZ for ; Thu, 9 Oct 2008 09:15:59 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 6D2503A6A66 for ; Thu, 9 Oct 2008 09:15:59 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 9 Oct 2008 12:16:16 -0400 From: Mark Jones To: "dime@ietf.org" Date: Thu, 9 Oct 2008 12:16:14 -0400 Thread-Topic: Application Id AVPs in message bodies Thread-Index: AckqKloMqqNff+crTtixmp6nrGXZDw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Dime] Application Id AVPs in message bodies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The 3588bis still has requirements for application ids to be present in non-CER/CEA messages: 6.11. Vendor-Specific-Application-Id AVP ... This AVP MUST also be present as the first AVP in all experimental commands defined in the vendor-specific application. --- 9.7.1. Accounting-Request ... One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it MUST include an Acct-Application-Id AVP. --- 9.7.2. Accounting-Answer ... One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it MUST contain an Acct-Application-Id AVP. --- The draft already states that an application id AVP in the message body (non-CER/CEA) MUST match the Application Id present in the Diameter message header so I propose the above requirements be removed from 3588bis. Objections? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 09:20:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D363A69B9; Thu, 9 Oct 2008 09:20:43 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C413A6983 for ; Thu, 9 Oct 2008 09:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vKtLRrRaNoJ for ; Thu, 9 Oct 2008 09:20:42 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id EDE1F3A69B9 for ; Thu, 9 Oct 2008 09:20:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 995B8C803A; Thu, 9 Oct 2008 12:21:20 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20375-07; Thu, 9 Oct 2008 12:21:18 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 9 Oct 2008 12:21:18 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 12:21:18 -0400 Received: from [10.6.32.149] ([10.6.32.149]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Oct 2008 21:51:12 +0530 From: Biplab Sarkar To: Mark Jones In-Reply-To: References: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> Organization: Starent Networks Date: Thu, 09 Oct 2008 21:51:10 +0530 Message-Id: <1223569270.4412.2.camel@tiger.billo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 09 Oct 2008 16:21:12.0308 (UTC) FILETIME=[0B958B40:01C92A2B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: "dime@ietf.org" Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1773548055==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1773548055== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KbuIKavsF4wnC95pBrGo" --=-KbuIKavsF4wnC95pBrGo Content-Type: multipart/alternative; boundary="=-9HwtEg1WH/L6IIbga0Fd" --=-9HwtEg1WH/L6IIbga0Fd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi All, I also thing for AVP's that "can't" be present in a message, we should have "min=3D0" in the ABNF representation. Thanks Biplab On Thu, 2008-10-09 at 11:35 -0400, Mark Jones wrote: > Hi Jouni, >=20 > I'd always assumed that a required AVP would have a minimum occurrence of= one but I agree that it should be explicit in the ABNF description. >=20 > An alternative change to 3588bis that probably has less impact on existin= g specs would be: >=20 > min =3D 1*DIGIT > ; The minimum number of times the element may > ; be present. The default value is zero for > ; fixed and optional rules. The default value > ; is one for required rules. >=20 > Then we don't have to change any *{ avp } in existing specs. >=20 > Regards > Mark >=20 > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > Behalf Of Jouni Korhonen > > Sent: October 8, 2008 11:37 > > To: dime@ietf.org > > Subject: Re: [Dime] comment on ABNFs in 3588bis > > > > A copy'n'paste typo. meant: > > > > "If a required rule has a qualifier, then the value of min MUST be > > 1." > > > > Jouni > > > > > > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > > > > > Hi all, > > > > > > The -12 revision of 3588bis still allows and actually gives an > > > example of using "* { AVP }", which in my opinion does not make > > > sense. Should we add a note under section 3.2 qual description > > > stating that "* { AVP }" is not possible based on the description > > > of a required AVP? I would add the following text to qual > > description: > > > > > > "If a required rule has a qualifier, then the value of min > > > MUST be 1 if present." > > > > > > If the above is acceptable, then we need to fix the example > > > following the ABNF definitions: > > > > > > The following is a definition of a fictitious command code: > > > > > > Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > > > > { User-Name } > > > * { Origin-Host } > > > ^^^^ > > > * [ AVP ] > > > > > > > > > Cheers, > > > Jouni > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=-9HwtEg1WH/L6IIbga0Fd Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,

I also thing for AVP's that "can't" be present in a message, we s= hould have "min=3D0" in the ABNF representation.

Thanks
Biplab


On Thu, 2008-10-09 at 11:35 -0400, Mark Jones wrote: 
Hi Jouni,

I'd always assumed that a required AVP would have a minimum occurrence of o=
ne but I agree that it should be explicit in the ABNF description.

An alternative change to 3588bis that probably has less impact on existing =
specs would be:

   min              =3D 1*DIGIT
                      ; The minimum number of times the element may
                      ; be present.  The default value is zero for
                      ; fixed and optional rules. The default value
                      ; is one for required rules.

Then we don't have to change any *{ avp } in existing specs.

Regards
Mark

> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
> Behalf Of Jouni Korhonen
> Sent: October 8, 2008 11:37
> To: dime@ietf.org
> Subject: Re: [Dime] comment on ABNFs in 3588bis
>
> A copy'n'paste typo. meant:
>
>    "If a required rule has a qualifier, then the value of min MUS=
T be
> 1."
>
> Jouni
>
>
> On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote:
>
> > Hi all,
> >
> > The -12 revision of 3588bis still allows and actually gives an
> > example of using "* { AVP }", which in my opinion does =
not make
> > sense. Should we add a note under section 3.2 qual description
> > stating that "* { AVP }" is not possible based on the d=
escription
> > of a required AVP? I would add the following text to qual
> description:
> >
> >   "If a required rule has a qualifier, then the value of min
> >    MUST be 1 if present."
> >
> > If the above is acceptable, then we need to fix the example
> > following  the ABNF definitions:
> >
> >    The following is a definition of a fictitious command code:
> >
> >    Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY =
>
> >                        { User-Name }
> >                      * { Origin-Host }
> >                    ^^^^
> >                      * [ AVP ]
> >
> >
> > Cheers,
> >       Jouni
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://ww=
w.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.iet=
f.org/mailman/listinfo/dime
>
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org=
/mailman/listinfo/dime
--=-9HwtEg1WH/L6IIbga0Fd-- --=-KbuIKavsF4wnC95pBrGo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBI7i923rQBTW1UPu4RAvoeAJ9FuMs2qSREv50quCDKcD/N2j0ApACgw3DE i0645LxXuXTyqe+YEGjaGQc= =JlzX -----END PGP SIGNATURE----- --=-KbuIKavsF4wnC95pBrGo-- --===============1773548055== 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://www.ietf.org/mailman/listinfo/dime --===============1773548055==-- From dime-bounces@ietf.org Thu Oct 9 10:00:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84843A6AC9; Thu, 9 Oct 2008 10:00:03 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DDB13A69B9 for ; Thu, 9 Oct 2008 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WStT8qeA7Dr8 for ; Thu, 9 Oct 2008 09:59:58 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 415CF3A6AC9 for ; Thu, 9 Oct 2008 09:59:58 -0700 (PDT) Received: (qmail invoked by alias); 09 Oct 2008 16:59:56 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp035) with SMTP; 09 Oct 2008 18:59:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19UtQAv2/JUxY9vQLa6BqsHA/YFgbCV0EYIIAzl6j d014dk9k2m0rwS From: "Hannes Tschofenig" To: , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , References: <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98EA@ftrdmel2> Date: Thu, 9 Oct 2008 19:59:55 +0300 Message-ID: <009501c92a30$750ef0c0$804aa20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98EA@ftrdmel2> Thread-Index: Ackpd/5Cd/WNG0FkRyeWMRY55W7ezwAA69twACzzloA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Subject: Re: [Dime] The M-bit MAY column issue X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Lionel, = >For me, the use of the M-bit allows to "optionally" send any = >AVPs in a given command and to be sure that these AVPs will = >not be simply ignored if not understood. I would phrase it a bit differently (since the M-bit is independing of the ABNF, i.e., what is being sent) but the outcome would be the same. = > >If you want to remove the M-bit, Some other folks in the group suggested it. I am only stating what it essentially means. = you will have to specify per = >command in the same table: >*All the AVPs that will be always present in the command (i.e. = >fixed and required AVP) The information about what AVPs are being sent in each command has to be provided anyway, regardless of the M-bit discussion as it is contained in the ABNF of the command. = *All the AVPs that may be added in the = >command and must not be ignored if not supported This is essentially an AVP that has the M-bit set. *Any other = >AVP that may be present in the command and may be ignored if = >not supported. This is essentially an AVP that does not have the M-bit set. = > >I think it would be easier to keep the M-bit flag as it is. >I'm assuming that the majority of the AVPs used in a given = >application will have a fixed setting of the M-bit (set or = >cleared) - that could be stated some where... There are only two choices when the MAY option is removed. = >If still required, it would be however possible to indicate = >that a specific AVP would have "always" the M-bit set except = >in such or such a command. That means that this clarification = >would be needed only for these specific AVPs. > Ciao Hannes >Lionel > = > >> -----Message d'origine----- >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = >> de Tschofenig, Hannes (NSN - FI/Espoo) Envoy=E9 : mercredi 8 octobre = >> 2008 21:00 =C0 : dime@ietf.org Objet : [Dime] The M-bit MAY = >column issue >> = >> Hi all, >> = >> the M-bit setting in an AVP indicates what the receiving side has to = >> understand. From an implementation point of view there are = >only these = >> two options: >> * I have to implement the AVP. >> * I don't have to implement it. It's optional. = >> = >> For the sending side the ABNF tells what the sender has to = >put into a = >> command (with some additional constraints). >> = >> When one restricts the M-bit setting to >> -- MUST and >> -- MUST NOT >> then the semantic regarding what has to be implemented and = >understood = >> is essentially determined at the time when the specification was = >> written and this raises the question about why that information is = >> carried in the protocol itself (rather than just written in the = >> specification very much like the ABNF is). >> = >> Some folks in the past suggested to remove the MAY option of the = >> M-bit. >> My question is: Why is the M-bit flag in the AVP needed at all? Why = >> don't we replace it with a table in the document that says = >which AVPs = >> must get implemented and which others are optional? >> = >> Ciao >> Hannes >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> = >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 10:16:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12FD93A6AFA; Thu, 9 Oct 2008 10:16:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95623A6AE3 for ; Thu, 9 Oct 2008 10:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr8eyLxMg3ow for ; Thu, 9 Oct 2008 10:16:44 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 75CE328C12B for ; Thu, 9 Oct 2008 10:16:44 -0700 (PDT) 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 m99HHPZL014982; Thu, 9 Oct 2008 13:17:25 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48EE3C9D.50900@tari.toshiba.com> Date: Thu, 09 Oct 2008 13:17:17 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Mark Jones References: <59D7431DE2527D4CB0F1EFEDA5683ED3031A276C@SEHAN021MB.tcad.telia.se> In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Guys, This change is duly noted. -- victor > Oops! Yes, I agree that your clause is also required here. > > Mark > > >> -----Original Message----- >> From: jouni.korhonen@teliasonera.com >> [mailto:jouni.korhonen@teliasonera.com] >> Sent: October 9, 2008 08:58 >> To: Mark Jones; dime@ietf.org >> Subject: RE: [Dime] comment on ABNFs in 3588bis >> >> Hi Mark, >> >> Works for me! However, I think we still need to state that min >> value of 0 is not allowed at all for required rules: >> >> min = 1*DIGIT >> ; The minimum number of times the element may >> ; be present. The default value is zero for >> ; fixed and optional rules. The default value >> ; is one for required rules. The value of zero >> ; is not allowed for required rules. >> >> >> Cheers, >> Jouni >> >> >> >>> Hi Jouni, >>> >>> I'd always assumed that a required AVP would have a minimum >>> occurrence of one but I agree that it should be explicit in >>> the ABNF description. >>> >>> An alternative change to 3588bis that probably has less >>> impact on existing specs would be: >>> >>> min = 1*DIGIT >>> ; The minimum number of times the element may >>> ; be present. The default value is zero for >>> ; fixed and optional rules. The default value >>> ; is one for required rules. >>> >>> Then we don't have to change any *{ avp } in existing specs. >>> >>> Regards >>> Mark >>> >>> >>>> -----Original Message----- >>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >>>> >>> On Behalf >>> >>>> Of Jouni Korhonen >>>> Sent: October 8, 2008 11:37 >>>> To: dime@ietf.org >>>> Subject: Re: [Dime] comment on ABNFs in 3588bis >>>> >>>> A copy'n'paste typo. meant: >>>> >>>> "If a required rule has a qualifier, then the value of >>>> >>> min MUST be >>> >>>> 1." >>>> >>>> Jouni >>>> >>>> >>>> On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: >>>> >>>> >>>>> Hi all, >>>>> >>>>> The -12 revision of 3588bis still allows and actually gives an >>>>> example of using "* { AVP }", which in my opinion does not make >>>>> sense. Should we add a note under section 3.2 qual description >>>>> stating that "* { AVP }" is not possible based on the >>>>> >>> description of >>> >>>>> a required AVP? I would add the following text to qual >>>>> >>>> description: >>>> >>>>> "If a required rule has a qualifier, then the value of min >>>>> MUST be 1 if present." >>>>> >>>>> If the above is acceptable, then we need to fix the example >>>>> following the ABNF definitions: >>>>> >>>>> The following is a definition of a fictitious command code: >>>>> >>>>> Example-Request ::= < Diameter Header: 9999999, REQ, PXY > >>>>> { User-Name } >>>>> * { Origin-Host } >>>>> ^^^^ >>>>> * [ AVP ] >>>>> >>>>> >>>>> Cheers, >>>>> Jouni >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 10:37:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2213A686D; Thu, 9 Oct 2008 10:37:02 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B883A67DD for ; Thu, 9 Oct 2008 10:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwv-AxeKNCob for ; Thu, 9 Oct 2008 10:36:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 03C723A686D for ; Thu, 9 Oct 2008 10:36:54 -0700 (PDT) Received: (qmail invoked by alias); 09 Oct 2008 17:37:37 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp047) with SMTP; 09 Oct 2008 19:37:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19WtJMSKVpWHHo11nl200qXRqUWUewKW/HuJWkQ9y KIJNrIqeXC3aBH From: "Hannes Tschofenig" To: , "'Mark Jones'" References: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> <1223569270.4412.2.camel@tiger.billo.com> Date: Thu, 9 Oct 2008 20:37:39 +0300 Message-ID: <009601c92a35$ba9e0040$804aa20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1223569270.4412.2.camel@tiger.billo.com> Thread-Index: AckqKxWIAuW/3SrMTa+rB1VvC7Sx2AABXAWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: dime@ietf.org Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Although the recently made proposal just clarify the usage of the ABNF I wanted to mention it. The ABNF has limitations when it comes to express more complex conditions (if you want to still keep readable and without defining a new Command Code for every tiny variation). Ideally, dependencies like "Don't send AVP X if AVP is present or has a specific value." should be avoided This isn't really a problem with simple applications. However, we have seen some more complicated onces and there the ABNF itself isn't really so expressive as it could be. Now, there is the question about what todo about this. Some folks within the group in the past suggested to introduce more powerful mechanisms to describe dependencies. Nobody came up with a specific proposal but some individual comments go into the direction of addressing some specific aspects, such as the one made by Biplab. All of them are fine, in some sense, if we consider the impact to the extensibility rules. For example, the current extensibility rules assumes that a command is described using ABNF. Many of the "progressing rules" aren't really captured in the ABNF itself. As such, you can change the description in a spec to create interoperability problems without touching the ABNF. I personally don't have a strong opinion what the best way is to describe the message content. I have, for example, written a few specs that contain an XML schema and I have to tell that XML schemas are not a good way either to describe what a message should contain although they provide more flexibility. Since we were pretty unhappy about the limited extensibility of XML schemas we switched to Relax NG schemas. That was more powerful but then had other problems. Other folks suggested to use Schematron, which I have never used. Since this issue came up a couple of times already I would like to hear whether folks are happy with only using ABNF to describe the content of a command? Here is my opinion: I would not too strict rules here and allow the protocol designer and document editor to pick a suitable mechanism to describe how the application looks like. For example, if someone wants to use pseudo code to capture vagueness in the ABNF then let them write pseudo code. Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Biplab Sarkar Sent: 09 October, 2008 19:21 To: Mark Jones Cc: dime@ietf.org Subject: Re: [Dime] comment on ABNFs in 3588bis Hi All, I also thing for AVP's that "can't" be present in a message, we should have "min=0" in the ABNF representation. Thanks Biplab On Thu, 2008-10-09 at 11:35 -0400, Mark Jones wrote: Hi Jouni, I'd always assumed that a required AVP would have a minimum occurrence of one but I agree that it should be explicit in the ABNF description. An alternative change to 3588bis that probably has less impact on existing specs would be: min = 1*DIGIT ; The minimum number of times the element may ; be present. The default value is zero for ; fixed and optional rules. The default value ; is one for required rules. Then we don't have to change any *{ avp } in existing specs. Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Jouni Korhonen > Sent: October 8, 2008 11:37 > To: dime@ietf.org > Subject: Re: [Dime] comment on ABNFs in 3588bis > > A copy'n'paste typo. meant: > > "If a required rule has a qualifier, then the value of min MUST be > 1." > > Jouni > > > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > > > Hi all, > > > > The -12 revision of 3588bis still allows and actually gives an > > example of using "* { AVP }", which in my opinion does not make > > sense. Should we add a note under section 3.2 qual description > > stating that "* { AVP }" is not possible based on the description > > of a required AVP? I would add the following text to qual > description: > > > > "If a required rule has a qualifier, then the value of min > > MUST be 1 if present." > > > > If the above is acceptable, then we need to fix the example > > following the ABNF definitions: > > > > The following is a definition of a fictitious command code: > > > > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > > { User-Name } > > * { Origin-Host } > > ^^^^ > > * [ AVP ] > > > > > > Cheers, > > Jouni > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 9 10:38:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367E73A6AFB; Thu, 9 Oct 2008 10:38:13 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AAC63A6AFB for ; Thu, 9 Oct 2008 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUl39rqBmAoG for ; Thu, 9 Oct 2008 10:38:07 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 1A5A03A6AE8 for ; Thu, 9 Oct 2008 10:38:07 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 9 Oct 2008 13:38:50 -0400 From: Mark Jones To: "bsarkar@starentnetworks.com" Date: Thu, 9 Oct 2008 13:38:44 -0400 Thread-Topic: [Dime] comment on ABNFs in 3588bis Thread-Index: AckqKySxU0fq+EuEQ2G7yEnuWW7FnAAAZVOg Message-ID: References: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> <1223569270.4412.2.camel@tiger.billo.com> In-Reply-To: <1223569270.4412.2.camel@tiger.billo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0835274365==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0835274365== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_D6824C8074596B4E9CA38F6A62454F5C0A283C7E96exchange02bri_" --_000_D6824C8074596B4E9CA38F6A62454F5C0A283C7E96exchange02bri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Biplab, According to the current draft a forbidden AVP would be represented as: *0 [ Evil-AVP ] And I understand that you are requesting that this be changed to: 0*0 [ Evil-AVP ] Is that correct? This change appears to be redundant given that the default= value of min is zero. Regards Mark ________________________________ From: Biplab Sarkar [mailto:bsarkar@starentnetworks.com] Sent: October 9, 2008 09:21 To: Mark Jones Cc: dime@ietf.org; Jouni Korhonen Subject: Re: [Dime] comment on ABNFs in 3588bis Hi All, I also thing for AVP's that "can't" be present in a message, we should have= "min=3D0" in the ABNF representation. Thanks Biplab On Thu, 2008-10-09 at 11:35 -0400, Mark Jones wrote: Hi Jouni, I'd always assumed that a required AVP would have a minimum occurrence of o= ne but I agree that it should be explicit in the ABNF description. An alternative change to 3588bis that probably has less impact on existing = specs would be: min =3D 1*DIGIT ; The minimum number of times the element may ; be present. The default value is zero for ; fixed and optional rules. The default value ; is one for required rules. Then we don't have to change any *{ avp } in existing specs. Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bo= unces@ietf.org] On > Behalf Of Jouni Korhonen > Sent: October 8, 2008 11:37 > To: dime@ietf.org > Subject: Re: [Dime] comment on ABNFs in 3588bis > > A copy'n'paste typo. meant: > > "If a required rule has a qualifier, then the value of min MUST be > 1." > > Jouni > > > On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote: > > > Hi all, > > > > The -12 revision of 3588bis still allows and actually gives an > > example of using "* { AVP }", which in my opinion does not make > > sense. Should we add a note under section 3.2 qual description > > stating that "* { AVP }" is not possible based on the description > > of a required AVP? I would add the following text to qual > description: > > > > "If a required rule has a qualifier, then the value of min > > MUST be 1 if present." > > > > If the above is acceptable, then we need to fix the example > > following the ABNF definitions: > > > > The following is a definition of a fictitious command code: > > > > Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > > > { User-Name } > > * { Origin-Host } > > ^^^^ > > * [ AVP ] > > > > > > Cheers, > > Jouni > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_D6824C8074596B4E9CA38F6A62454F5C0A283C7E96exchange02bri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Biplab,
 
According to the current draft a forbidden = AVP=20 would be represented as:
 
        *0 [= =20 Evil-AVP ]
 
And I=20 understand that you are requesting that this be changed to:
 
        0*0 [= =20 Evil-AVP ]
 
Is=20 that correct? This change appears to be redundant given that the default va= lue=20 of min is zero.
 
Regards
= Mark<= BR>
From: Biplab Sarkar=20 [mailto:bsarkar@starentnetworks.com]
Sent: October 9, 2008=20 09:21
To: Mark Jones
Cc: dime@ietf.org; Jouni=20 Korhonen
Subject: Re: [Dime] comment on ABNFs in=20 3588bis

Hi All,

I also thing for AVP's that "can't" be present = in a=20 message, we should have "min=3D0" in the ABNF=20 representation.

Thanks
Biplab


On Thu, 2008-10-09 at = 11:35=20 -0400, Mark Jones wrote:=20 
Hi Jouni,

I'd always assumed that a required AVP would have a minimum occurrence of o=
ne but I agree that it should be explicit in the ABNF description.

An alternative change to 3588bis that probably has less impact on existing =
specs would be:

   min              =3D 1*DIGIT
                      ; The minimum number of times the element may
                      ; be present.  The default value is zero for
                      ; fixed and optional rules. The default value
                      ; is one for required rules.

Then we don't have to change any *{ avp } in existing specs.

Regards
Mark

> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
> Behalf Of Jouni Korhonen
> Sent: October 8, 2008 11:37
> To: dime@ietf.org
> Subject: Re: [Dime] comment on ABNFs in 3588bis
>
> A copy'n'paste typo. meant:
>
>    "If a required rule has a qualifier, then the value of min MUST be
> 1."
>
> Jouni
>
>
> On Oct 8, 2008, at 9:29 PM, Jouni Korhonen wrote:
>
> > Hi all,
> >
> > The -12 revision of 3588bis still allows and actually gives an
> > example of using "* { AVP }", which in my opinion does not make
> > sense. Should we add a note under section 3.2 qual description
> > stating that "* { AVP }" is not possible based on the description
> > of a required AVP? I would add the following text to qual
> description:
> >
> >   "If a required rule has a qualifier, then the value of min
> >    MUST be 1 if present."
> >
> > If the above is acceptable, then we need to fix the example
> > following  the ABNF definitions:
> >
> >    The following is a definition of a fictitious command code:
> >
> >    Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY =
>
> >                        { User-Name }
> >                      * { Origin-Host }
> >                    ^^^^
> >                      * [ AVP ]
> >
> >
> > Cheers,
> >       Jouni
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://ww=
w.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.iet=
f.org/mailman/listinfo/dime
>
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org=
/mailman/listinfo/dime
--_000_D6824C8074596B4E9CA38F6A62454F5C0A283C7E96exchange02bri_-- --===============0835274365== 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://www.ietf.org/mailman/listinfo/dime --===============0835274365==-- From dime-bounces@ietf.org Sat Oct 11 15:44:54 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780013A67F6; Sat, 11 Oct 2008 15:44:54 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734813A67F6 for ; Sat, 11 Oct 2008 15:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loGRN6sYSYn6 for ; Sat, 11 Oct 2008 15:44:51 -0700 (PDT) Received: from mailfilter11.ihug.co.nz (mailfilter11.ihug.co.nz [203.109.136.11]) by core3.amsl.com (Postfix) with ESMTP id 5B9913A67D2 for ; Sat, 11 Oct 2008 15:44:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAJnJ8Eh2XMHe/2dsb2JhbACBcrhNgWyBCA X-IronPort-AV: E=Sophos;i="4.33,395,1220184000"; d="scan'208";a="135989373" Received: from 118-92-193-222.dsl.dyn.ihug.co.nz (HELO i.geek.nz) ([118.92.193.222]) by smtp.mailfilter5.ihug.co.nz with SMTP; 12 Oct 2008 11:45:34 +1300 Date: Sun, 12 Oct 2008 11:45:34 +1300 From: Ralph Loader To: "Glen Zorn" Message-ID: <20081012114534.22c93a26@i.geek.nz> In-Reply-To: <00ac01c929d4$903f6890$b0be39b0$@net> References: <247FB937-AE22-4FC1-9B33-70151BC4AA9D@iki.fi> <7DBAFEC6A76F3E42817DF1EBE64CB02605EA98E7@ftrdmel2> <00ac01c929d4$903f6890$b0be39b0$@net> X-Mailer: Claws Mail 3.5.0cvs92 (GTK+ 2.14.3; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] comment on ABNFs in 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Cj4gT24gYSByZWxhdGVkIGJ1dCBtb3JlIGdlbmVyYWwgbm90ZTogaXMgYXJlIHRoZSBBQk5GIGRl ZmluaXRpb25zIHJlYWxseQo+IHVzZWZ1bD8gIEZyb20gdGhlIHRyYWZmaWMgb24gdGhpcyBsaXN0 LCBpdCBzZWVtcyB0aGF0IHRoZXkgY2F1c2UgbW9yZQo+IHRyb3VibGUgdGhhbiBhbnl0aGluZyBl bHNlLi4uCgpSZXBsYWNpbmcgdGhlbSB3aXRoIHNvbWV0aGluZyBtb3JlIHZhZ3VlIG1pZ2h0IHdl bGwgY2F1c2UgbW9yZSBwcm9ibGVtcwp0aGFuIGl0IHNvbHZlcy4KCkhhdmluZyB3cml0dGVuIGNv ZGUgZ2VuZXJhdG9ycyB0aGF0IHByb2Nlc3MgdGhlIEFCTkYsIEknbSBncmF0ZWZ1bCBmb3IKdGhl IGVmZm9ydCB0aGF0IGdvZXMgaW50byBnZXR0aW5nIHRoZSBkZWZpbml0aW9ucyByaWdodC4KCgo+ ID4gT2sgd2l0aCB0aGF0LiBUaGUgIm1pbiIgbXVzdCBiZSBlcXVhbCB0byAxIGZvciBSZXF1aXJl ZCBBVlAuCgpJbmNpZGVudGx5LCBzb21lIG9mIHRoZSAzR1BQIHNwZWNzIHVzZSAnKntmb299JyBh bmQgZnJvbSB0aGUgY29udGV4dAppbnRlbmRlZCB0aGlzIHRvIG1lYW4gMS1vci1tb3JlLgoKUmFs cGguCgo+ID4gCj4gPiBCeSB0aGUgd2F5LCBhYm91dCB0aGUgZ2l2ZW4gZXhhbXBsZSwgaXMgaXQg cmVhbGx5IHBvc3NpYmxlIHRvIGhhdmUKPiA+IG11bHRpcGxlIE9yaWdpbi1ob3N0IEFWUCBpbiB0 aGUgc2FtZSByZXF1ZXN0LCBhY2NvcmRpbmcgdG8gdGhlCj4gPiBkZWZpbml0aW9uIG9mIHRoZSBP cmlnaW4taG9zdCBBVlA/Cj4gPiAKPiA+IG9uIHRoZSBzYW1lIHRvcGljLCBpcyBpdCBwb3NzaWJs ZSB0byBoYXZlIHNldmVyYWwgb2NjdXJyZW5jZXMgb2YgYQo+ID4gZml4ZWQgQVZQPyBJZiBub3Qs Cj4gPiAKPiA+IGVpdGhlciBhbm90aGVyIG5vdGUgc2hvdWxkIGJlIGFkZGVkIHRvIHN0YXRlIHRo YXQ6ICJJZiBhbiBmaXhlZCBydWxlCj4gPiBoYXMgYSBxdWFsaWZpZXIsIHRoZW4gdGhlIHZhbHVl IG9mIG1pbiBhbmQgbWF4IE1VU1QgYmUgMS4iCj4gPiAKPiA+IE9yIHJlbW92ZSB0aGUgW3F1YWxd IGJlZm9yZSAiPCIgYXZwLXNwZWMgIj4iIHRvIGhhdmU6IEZpeGVkID0gW3F1YWxdCj4gPiAiPCIg YXZwLXNwZWMgIj4iCj4gPiAKPiA+IExpb25lbAo+ID4gCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQo+ID4gPiBEZSA6IGRpbWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZ10gRGUKPiA+ID4gbGEgcGFydCBkZSBKb3VuaSBLb3Job25lbgo+ID4g PiBFbnZvecOpIDogbWVyY3JlZGkgOCBvY3RvYnJlIDIwMDggMjA6MzcKPiA+ID4gw4AgOiBkaW1l QGlldGYub3JnCj4gPiA+IE9iamV0IDogUmU6IFtEaW1lXSBjb21tZW50IG9uIEFCTkZzIGluIDM1 ODhiaXMKPiA+ID4KPiA+ID4gQSBjb3B5J24ncGFzdGUgdHlwby4gbWVhbnQ6Cj4gPiA+Cj4gPiA+ ICAgICJJZiBhIHJlcXVpcmVkIHJ1bGUgaGFzIGEgcXVhbGlmaWVyLCB0aGVuIHRoZSB2YWx1ZSBv ZiBtaW4KPiA+ID4gTVVTVCBiZSAxLiIKPiA+ID4KPiA+ID4gSm91bmkKPiA+ID4KPiA+ID4KPiA+ ID4gT24gT2N0IDgsIDIwMDgsIGF0IDk6MjkgUE0sIEpvdW5pIEtvcmhvbmVuIHdyb3RlOgo+ID4g Pgo+ID4gPiA+IEhpIGFsbCwKPiA+ID4gPgo+ID4gPiA+IFRoZSAtMTIgcmV2aXNpb24gb2YgMzU4 OGJpcyBzdGlsbCBhbGxvd3MgYW5kIGFjdHVhbGx5IGdpdmVzCj4gPiA+IGFuIGV4YW1wbGUKPiA+ ID4gPiBvZiB1c2luZyAiKiB7IEFWUCB9Iiwgd2hpY2ggaW4gbXkgb3BpbmlvbiBkb2VzIG5vdCBt YWtlCj4gPiA+IHNlbnNlLiBTaG91bGQKPiA+ID4gPiB3ZSBhZGQgYSBub3RlIHVuZGVyIHNlY3Rp b24gMy4yIHF1YWwgZGVzY3JpcHRpb24gc3RhdGluZwo+ID4gPiB0aGF0ICIqIHsgQVZQCj4gPiA+ ID4gfSIgaXMgbm90IHBvc3NpYmxlIGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbiBvZiBhIHJlcXVp cmVkCj4gPiA+IEFWUD8gSSB3b3VsZAo+ID4gPiA+IGFkZCB0aGUgZm9sbG93aW5nIHRleHQgdG8g cXVhbCBkZXNjcmlwdGlvbjoKPiA+ID4gPgo+ID4gPiA+ICAgIklmIGEgcmVxdWlyZWQgcnVsZSBo YXMgYSBxdWFsaWZpZXIsIHRoZW4gdGhlIHZhbHVlIG9mIG1pbgo+ID4gPiA+ICAgIE1VU1QgYmUg MSBpZiBwcmVzZW50LiIKPiA+ID4gPgo+ID4gPiA+IElmIHRoZSBhYm92ZSBpcyBhY2NlcHRhYmxl LCB0aGVuIHdlIG5lZWQgdG8gZml4IHRoZSBleGFtcGxlCj4gPiA+IGZvbGxvd2luZwo+ID4gPiA+ IHRoZSBBQk5GIGRlZmluaXRpb25zOgo+ID4gPiA+Cj4gPiA+ID4gICAgVGhlIGZvbGxvd2luZyBp cyBhIGRlZmluaXRpb24gb2YgYSBmaWN0aXRpb3VzIGNvbW1hbmQgY29kZToKPiA+ID4gPgo+ID4g PiA+ICAgIEV4YW1wbGUtUmVxdWVzdCA6Oj0gPCBEaWFtZXRlciBIZWFkZXI6IDk5OTk5OTksIFJF USwgUFhZID4KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgIHsgVXNlci1OYW1lIH0KPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgICAqIHsgT3JpZ2luLUhvc3QgfQo+ID4gPiA+ICAgICAg ICAgICAgICAgICAgICBeXl5eCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgKiBbIEFWUCBd Cj4gPiA+ID4KPiA+ID4gPgo+ID4gPiA+IENoZWVycywKPiA+ID4gPiAJSm91bmkKPiA+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gPiA+IERp TUUgbWFpbGluZyBsaXN0Cj4gPiA+ID4gRGlNRUBpZXRmLm9yZwo+ID4gPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQo+ID4gPgo+ID4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gPiBEaU1FIG1haWxpbmcgbGlz dAo+ID4gPiBEaU1FQGlldGYub3JnCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGltZQo+ID4gPgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPiA+IERpTUUgbWFpbGluZyBsaXN0Cj4gPiBEaU1FQGlldGYub3JnCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUKPiAKPiAKPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IERpTUUgbWFpbGlu ZyBsaXN0Cj4gRGlNRUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpEaU1FIG1haWxpbmcgbGlzdApEaU1FQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZQo= From dime-bounces@ietf.org Mon Oct 13 10:58:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD663A68AA; Mon, 13 Oct 2008 10:58:44 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A9E28C17A for ; Mon, 13 Oct 2008 10:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lesv-88oja+Y for ; Mon, 13 Oct 2008 10:58:42 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 55C1F3A6820 for ; Mon, 13 Oct 2008 10:58:42 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m9DHwwOd019350; Mon, 13 Oct 2008 12:58:58 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 12:58:58 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 13 Oct 2008 12:58:56 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01F98827@ILEXC2U01.ndc.lucent.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01D90BFB@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-sun-dime-itu-t-rw-01 Thread-Index: AckJFl3SUio9iUyTRtC58dZoelRc3gQoeExABOi/0OA= References: <20080828135239.62230@gmx.net> <09C9068466B79E4C938DC7737562404D01D90BFB@ILEXC2U01.ndc.lucent.com> From: "Sun, Dong \(Dong\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 13 Oct 2008 17:58:58.0157 (UTC) FILETIME=[5D8E11D0:01C92D5D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-sun-dime-itu-t-rw-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, All, I have one question concerning the use of AVP Flag, when the 'M' bit is placed in the MAY Column (in a Diameter application defined by other SDOs), what does it exactly mean? Is this interpretation correct? - i.e. the originator may set the 'M' bit, if it did, the receiver shall reject the message if the AVP or content is not recognized. If it is the case, that means It depends on the implementation, then how to ensure the interop? Thanks, Dong -----Original Message----- From: Sun, Dong (Dong) Sent: Thursday, September 18, 2008 11:16 PM To: 'Hannes Tschofenig'; 'aaa-doctors@ietf.org' Cc: 'dime@ietf.org' Subject: RE: [Dime] Review of draft-sun-dime-itu-t-rw-01 Hannes, I understood your concern on the modification of the ABNF of existing Diameter Credit control commands e.g. CCR/CCA. However, those changes are made originally by 3GPP 29.212 Gx interface. The ITU-T Q.3303.3 just reuses what are defined by Gx interface in order to avoid the interoperability problem with other SDOs (e.g. including WiMAX and 3GPP2 since both them are based on 3GPP Gx). Regarding the indications of "M"/"P" bits, all them are copied from other specs. I will try to fix it for this spec if possible. Same to the NASREQ issue. Thanks for the review and comments, although they are more related to the ITU-T spec instead of this IETF I-D. Rgs, Dong -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, August 28, 2008 9:53 AM To: aaa-doctors@ietf.org Cc: dime@ietf.org Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01 I reviewed draft-sun-dime-itu-t-rw-01 the normative reference: [Q.3303.3] ITU-T Recommendation Q.3303.3, "Resource control protocol no. 3 (rcp3): Protocol at the Rw interface between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE): Diameter", 2008. I think it is the right decision to define two new command codes (PIR / PIA) as it is done in [Q.3303.3]. HOWEVER, more command codes must be specified as the ABNF of existing Diameter Base Protocol and Diameter Credit Control Commands has been modified. I therefore request that [Q.3303.3] be changed in the following way since they would cause interoperability problems with existing Diameter Base Protocol and Diameter Credit Control implementations. * CCR Command The ABNF of the original CCR command is modified by removing the required Service-Context-ID AVP. * CCA Command The ABNF of the original CCA command is modified by turning the required Result-Code AVP into an optional one. * RAA Command The ABNF of the original RAA command is modified by turning the required Result-Code AVP into an optional one. * ASR Command The ABNF of the original ASR command is modified by adding the required Abort-Cause AVP. * ASA Command The ABNF of the original ASA command is modified by turning the required Result-Code AVP into an optional one. The simplest way to solve these issues is to register new command codes. Alternatively you could think about why you actually need to modify the ABNF of these commands. Another remark: A couple of tables are listed with AVP flag settings. I got the impression that these flag settings got copied from other documents. This could be a problem since the M-bit (and other flags) meaning is specific for the specific application and command. A new Diameter application/Command may require a different flag setting. I hope that the ITU-T checked this aspect since otherwise they will experience a lot of interop issues. Table 2 is missing indications about the M bit usage. Table 3 is missing indications about the P bit usage. Table 4 is missing indications about the P bit usage. A minor issue: The description about soft-state vs. hard-state was confusing since there is no Reservation-Lifetime AVP specified. Furthermore the text refers to NASREQ and the specification does not use NASREQ. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 14 00:11:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2342428C1A1; Tue, 14 Oct 2008 00:11:10 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C523A6BF0 for ; Tue, 14 Oct 2008 00:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wddm288XyD0Q for ; Tue, 14 Oct 2008 00:11:08 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 23D1F28C1B8 for ; Tue, 14 Oct 2008 00:11:07 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id A93CE92682 for ; Tue, 14 Oct 2008 09:12:01 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 9C090B8B3A for ; Tue, 14 Oct 2008 09:12:01 +0200 (CEST) Message-ID: <48F44641.9070604@restena.lu> Date: Tue, 14 Oct 2008 09:12:01 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Subject: [Dime] NAPTR registry X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, RFC3588 states that several NAPTR service fields are reserved for Diameter, specifically AAA+D2T and AAA+D2S. It also mentions creating an IANA registry for NAPTR service name to transport protocol mappings. I tried to find an exhaustive list of service fields but failed to find that registry at the IANA site. Maybe I'm just blind, could someone be so nice to give me a pointer? Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 14 13:21:22 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3773A6C07; Tue, 14 Oct 2008 13:21:22 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA4C3A6C07 for ; Tue, 14 Oct 2008 13:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwi+XedhVcM1 for ; Tue, 14 Oct 2008 13:21:20 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 448C43A6B2C for ; Tue, 14 Oct 2008 13:21:20 -0700 (PDT) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m9EKMDq1065118; Tue, 14 Oct 2008 16:22:13 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <48F4FF76.1040003@tari.toshiba.com> Date: Tue, 14 Oct 2008 16:22:14 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Mark Jones References: In-Reply-To: Cc: "dime@ietf.org" Subject: Re: [Dime] Application Id AVPs in message bodies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mark, Changes looks ok to me. -- victor > The 3588bis still has requirements for application ids to be present in non-CER/CEA messages: > > 6.11. Vendor-Specific-Application-Id AVP > ... > > This AVP MUST also be present as the first AVP in all experimental > commands defined in the vendor-specific application. > --- > > 9.7.1. Accounting-Request > ... > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present. If the Vendor-Specific-Application-Id grouped AVP > is present, it MUST include an Acct-Application-Id AVP. > > --- > > 9.7.2. Accounting-Answer > ... > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present. If the Vendor-Specific-Application-Id grouped AVP > is present, it MUST contain an Acct-Application-Id AVP. > --- > > The draft already states that an application id AVP in the message body (non-CER/CEA) MUST match the Application Id present in the Diameter message header so I propose the above requirements be removed from 3588bis. Objections? > > Regards > Mark > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 14 22:03:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC473A6808; Tue, 14 Oct 2008 22:03:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5391D3A6808 for ; Tue, 14 Oct 2008 22:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz03IbCxm5IJ for ; Tue, 14 Oct 2008 22:03:32 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 588E63A67FF for ; Tue, 14 Oct 2008 22:03:32 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2433098rvf.49 for ; Tue, 14 Oct 2008 22:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=TfudZME5412j7MxFxh/hdt+2ag1XARjb3aoBGqK6M+s=; b=KGN//iS5Ctd7n/3NXk3QWHmT50Ubos/i+J19J1rX949lAsy/3b/PHs2/71nOmZ4Vsr sSv38lith8TldSk4LG/88w3Mw6uzt/vLOg5yppCyO7zsF7KChf1tsl8afvy+LZnnokSl s1T/JtvPxj1okWc7oz1FWo15g6vKmoj6BK7MQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=a7/qG71ta8emgsf7JxdUiUMwSFbs18q+y/BoRp29FGKJ40x2ThVWqW5g9ZzvhZEdL4 o5fB1YqFUyPC+eTYBBGTRaxfmnkkLVspJEQuGGk1J2+z7Dx49UJ9TSl0lBXLrKC5UA3Y 22L9/1ZOcqGlryOcSoEykhXgNULbLfi9jlG2k= Received: by 10.141.33.21 with SMTP id l21mr300238rvj.9.1224047069584; Tue, 14 Oct 2008 22:04:29 -0700 (PDT) Received: by 10.140.143.4 with HTTP; Tue, 14 Oct 2008 22:04:29 -0700 (PDT) Message-ID: <27a1f01b0810142204i228b434eq5516283d2dfecb01@mail.gmail.com> Date: Wed, 15 Oct 2008 10:34:29 +0530 From: "praveen ch" To: dime@ietf.org In-Reply-To: <27a1f01b0810140142g21cf18dcu853163abcc50d138@mail.gmail.com> MIME-Version: 1.0 References: <27a1f01b0810140142g21cf18dcu853163abcc50d138@mail.gmail.com> Subject: [Dime] Query Regarding UNKNOWN AVP in the message. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0484072059==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0484072059== Content-Type: multipart/alternative; boundary="----=_Part_12529_6168417.1224047069577" ------=_Part_12529_6168417.1224047069577 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi I have a couple of queries regarding the UNKNOWN-AVP in the Message. Suppose the appId = 16777216, vendor-Id = 10315, Supported vendor Id's = 10316,10317,10318 ( just for assumption) 1. When a message with UNKNOWN-AVP comes with 'M' bit sets, then how will be the diameter base protocol validates that AVP. If V-bit sets for an AVP, we are validating like : if ( (avpMsg->vendorId != appCfg->vendorId) && ( avpMsg->vendorId != appCfg->suppVendorId)) { /* Sending error indication to the application */ } In this case how i can support this AVP. 2. When a message with UNKNOWN-AVP comes with 'M' bit not set, how can the base protocol takes the action? Can the base protocol checks for the Vendor-ID presents in the message or we need to pass to the peer with out validate the message. Please let us know in case of any further details needed. Your suggestions will be highly appreciated. Thanks in Advance. -- Regards, praveen chebolu -- Regards, praveen chebolu ------=_Part_12529_6168417.1224047069577 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi

I have a couple of queries regarding the UNKNOWN-AVP in the Message.

Suppose the appId = 16777216, vendor-Id = 10315, Supported vendor Id's = 10316,10317,10318 ( just for assumption)

1. When a message with UNKNOWN-AVP comes with 'M' bit sets, then how will be the diameter base protocol validates that AVP.
    If V-bit sets for an AVP, we are validating like :

    if ( (avpMsg->vendorId != appCfg->vendorId) && ( avpMsg->vendorId != appCfg->suppVendorId))
    {
     /* Sending error indication to the application */
    }

In this case how i can support this AVP.

2. When a message with UNKNOWN-AVP comes with 'M' bit not set, how can the base protocol takes the action? Can the base protocol checks for the Vendor-ID presents in the message or we need to pass to the peer with out validate the message.

Please let us know in case of any further details needed.

Your suggestions will be highly appreciated.

Thanks in Advance.
  
--
Regards,
praveen chebolu



--
Regards,
praveen chebolu
------=_Part_12529_6168417.1224047069577-- --===============0484072059== 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://www.ietf.org/mailman/listinfo/dime --===============0484072059==-- From dime-bounces@ietf.org Tue Oct 14 22:13:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DBB13A6C47; Tue, 14 Oct 2008 22:13:43 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B92C3A6C47 for ; Tue, 14 Oct 2008 22:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bciXIDitAv+W for ; Tue, 14 Oct 2008 22:13:41 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 365C83A6C36 for ; Tue, 14 Oct 2008 22:13:41 -0700 (PDT) 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 <0K8R00A8DL7XRI@szxga01-in.huawei.com> for dime@ietf.org; Wed, 15 Oct 2008 13:14:21 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8R00DMYL7WVP@szxga01-in.huawei.com> for dime@ietf.org; Wed, 15 Oct 2008 13:14:20 +0800 (CST) Received: from huawei1515 ([10.18.28.31]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8R00J68L7ION@szxml03-in.huawei.com> for dime@ietf.org; Wed, 15 Oct 2008 13:14:20 +0800 (CST) Date: Wed, 15 Oct 2008 10:43:55 +0530 From: Rajith R In-reply-to: To: 'Mark Jones' Message-id: <000601c92e84$e154c680$1f1c120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AckqKloMqqNff+crTtixmp6nrGXZDwEWWtfQ Cc: dime@ietf.org Subject: Re: [Dime] Application Id AVPs in message bodies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi 1. Why these requirements should be removed? 2. The draft already states that an application id AVP in the message body (non-CER/CEA) MUST match the Application Id present in the Diameter message header Is not this an altogether different requirement than the ones you are suggesting to remove? I cannot understand how they are related or am I missing something here? regards Rajith -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Mark Jones Sent: Thursday, October 09, 2008 9:46 PM To: dime@ietf.org Subject: [Dime] Application Id AVPs in message bodies The 3588bis still has requirements for application ids to be present in non-CER/CEA messages: 6.11. Vendor-Specific-Application-Id AVP ... This AVP MUST also be present as the first AVP in all experimental commands defined in the vendor-specific application. --- 9.7.1. Accounting-Request ... One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it MUST include an Acct-Application-Id AVP. --- 9.7.2. Accounting-Answer ... One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it MUST contain an Acct-Application-Id AVP. --- The draft already states that an application id AVP in the message body (non-CER/CEA) MUST match the Application Id present in the Diameter message header so I propose the above requirements be removed from 3588bis. Objections? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 05:58:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978BB28C219; Wed, 15 Oct 2008 05:58:51 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1A728C218 for ; Wed, 15 Oct 2008 05:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2-zecRSWdUW for ; Wed, 15 Oct 2008 05:58:47 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 39DC228C219 for ; Wed, 15 Oct 2008 05:58:47 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Wed, 15 Oct 2008 08:59:41 -0400 From: Mark Jones To: "rajithr@huawei.com" Date: Wed, 15 Oct 2008 08:59:39 -0400 Thread-Topic: [Dime] Application Id AVPs in message bodies Thread-Index: AckqKloMqqNff+crTtixmp6nrGXZDwEWWtfQABBSLFA= Message-ID: References: <000601c92e84$e154c680$1f1c120a@china.huawei.com> In-Reply-To: <000601c92e84$e154c680$1f1c120a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Application Id AVPs in message bodies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Rajith, The application ID is always present in the Diameter command header. These requirements are mandating the presence of redundant application ID AVPs in the message body. Do you see any reason to keep these requirements? Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Rajith R > Sent: October 15, 2008 01:14 > To: Mark Jones > Cc: dime@ietf.org > Subject: Re: [Dime] Application Id AVPs in message bodies > > Hi > 1. Why these requirements should be removed? > 2. The draft already states that an application id AVP in the > message body (non-CER/CEA) MUST match the Application Id > present in the > Diameter message header > Is not this an altogether different requirement than the ones you are > suggesting to remove? I cannot understand how they are related or am I > missing something here? > > regards > Rajith > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Mark > Jones > Sent: Thursday, October 09, 2008 9:46 PM > To: dime@ietf.org > Subject: [Dime] Application Id AVPs in message bodies > > The 3588bis still has requirements for application ids to be > present in > non-CER/CEA messages: > > 6.11. Vendor-Specific-Application-Id AVP > ... > > This AVP MUST also be present as the first AVP in all experimental > commands defined in the vendor-specific application. > --- > > 9.7.1. Accounting-Request > ... > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present. If the Vendor-Specific-Application-Id grouped AVP > is present, it MUST include an Acct-Application-Id AVP. > > --- > > 9.7.2. Accounting-Answer > ... > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present. If the Vendor-Specific-Application-Id grouped AVP > is present, it MUST contain an Acct-Application-Id AVP. > --- > > The draft already states that an application id AVP in the > message body > (non-CER/CEA) MUST match the Application Id present in the > Diameter message > header so I propose the above requirements be removed from 3588bis. > Objections? > > Regards > Mark > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 07:20:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B9B3A6963; Wed, 15 Oct 2008 07:20:56 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7860E28C20E for ; Wed, 15 Oct 2008 07:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-DsUUasYVIV for ; Wed, 15 Oct 2008 07:20:54 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 70DC13A68E8 for ; Wed, 15 Oct 2008 07:20:54 -0700 (PDT) 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 <0K8S005BVAJO9B@szxga04-in.huawei.com> for dime@ietf.org; Wed, 15 Oct 2008 22:21:24 +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 <0K8S00AKNAJOGK@szxga04-in.huawei.com> for dime@ietf.org; Wed, 15 Oct 2008 22:21:24 +0800 (CST) Received: from huawei1515 ([10.18.28.31]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8S00HYLAJNC6@szxml03-in.huawei.com> for dime@ietf.org; Wed, 15 Oct 2008 22:21:24 +0800 (CST) Date: Wed, 15 Oct 2008 19:51:23 +0530 From: Rajith R In-reply-to: To: 'Mark Jones' Message-id: <000401c92ed1$4d7a19e0$1f1c120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AckqKloMqqNff+crTtixmp6nrGXZDwEWWtfQABBSLFAAAiODMA== Cc: dime@ietf.org Subject: Re: [Dime] Application Id AVPs in message bodies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi I know of some Diameter applications that share the same application Id value b/w an Auth. & Accounting application, for e.g. 3GPP Rel-6 Cx & Accounting (see 32.299 v6.0.0) share the same application Id viz. 16777216. An explicit Auth- or Acct-Application-Id AVP in the message is needed in this case. Also, if 2 vendors provide the implementation of the same Diameter application, would not the Vendor Specific Application Id be useful in request routing? Regards Rajith -----Original Message----- From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] Sent: Wednesday, October 15, 2008 6:30 PM To: rajithr@huawei.com Cc: dime@ietf.org Subject: RE: [Dime] Application Id AVPs in message bodies Hi Rajith, The application ID is always present in the Diameter command header. These requirements are mandating the presence of redundant application ID AVPs in the message body. Do you see any reason to keep these requirements? Regards Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Rajith R > Sent: October 15, 2008 01:14 > To: Mark Jones > Cc: dime@ietf.org > Subject: Re: [Dime] Application Id AVPs in message bodies > > Hi > 1. Why these requirements should be removed? > 2. The draft already states that an application id AVP in the > message body (non-CER/CEA) MUST match the Application Id > present in the > Diameter message header > Is not this an altogether different requirement than the ones you are > suggesting to remove? I cannot understand how they are related or am I > missing something here? > > regards > Rajith > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Mark > Jones > Sent: Thursday, October 09, 2008 9:46 PM > To: dime@ietf.org > Subject: [Dime] Application Id AVPs in message bodies > > The 3588bis still has requirements for application ids to be > present in > non-CER/CEA messages: > > 6.11. Vendor-Specific-Application-Id AVP > ... > > This AVP MUST also be present as the first AVP in all experimental > commands defined in the vendor-specific application. > --- > > 9.7.1. Accounting-Request > ... > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present. If the Vendor-Specific-Application-Id grouped AVP > is present, it MUST include an Acct-Application-Id AVP. > > --- > > 9.7.2. Accounting-Answer > ... > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present. If the Vendor-Specific-Application-Id grouped AVP > is present, it MUST contain an Acct-Application-Id AVP. > --- > > The draft already states that an application id AVP in the > message body > (non-CER/CEA) MUST match the Application Id present in the > Diameter message > header so I propose the above requirements be removed from 3588bis. > Objections? > > Regards > Mark > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 08:15:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D15C28C24E; Wed, 15 Oct 2008 08:15:07 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B19528C248 for ; Wed, 15 Oct 2008 08:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvQUzatA6Uv3 for ; Wed, 15 Oct 2008 08:15:06 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 204F828C244 for ; Wed, 15 Oct 2008 08:15:06 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Wed, 15 Oct 2008 11:15:44 -0400 From: Mark Jones To: "rajithr@huawei.com" Date: Wed, 15 Oct 2008 11:15:43 -0400 Thread-Topic: [Dime] Application Id AVPs in message bodies Thread-Index: AckqKloMqqNff+crTtixmp6nrGXZDwEWWtfQABBSLFAAAiODMAABJRdA Message-ID: References: <000401c92ed1$4d7a19e0$1f1c120a@china.huawei.com> In-Reply-To: <000401c92ed1$4d7a19e0$1f1c120a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Application Id AVPs in message bodies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Rajith, Answers inline... > -----Original Message----- > From: Rajith R [mailto:rajithr@huawei.com] > Sent: October 15, 2008 10:21 > To: Mark Jones > Cc: dime@ietf.org > Subject: RE: [Dime] Application Id AVPs in message bodies > > Hi > I know of some Diameter applications that share the > same application > Id value b/w an Auth. & Accounting application, for e.g. 3GPP > Rel-6 Cx & > Accounting (see 32.299 v6.0.0) share the same application Id > viz. 16777216. > An explicit Auth- or Acct-Application-Id AVP in the message > is needed in > this case. The Diameter command header contains an application id and a command code. That is sufficient to uniquely identify a command type without parsing the message for additional AVPs. > Also, if 2 vendors provide the implementation of the > same Diameter > application, would not the Vendor Specific Application Id be useful in > request routing? > The Vendor-Specific-Application-Id AVP in the message body MUST contain the same value as the Diameter command header so I don't see how the AVP can be useful for request routing. You may want to review section 6.11 in 3588bis because I think you may be misusing the Vendor-Id in the Vendor-Specific-Application-Id AVP. Regards Mark > Regards > Rajith > > -----Original Message----- > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] > Sent: Wednesday, October 15, 2008 6:30 PM > To: rajithr@huawei.com > Cc: dime@ietf.org > Subject: RE: [Dime] Application Id AVPs in message bodies > > Hi Rajith, > > The application ID is always present in the Diameter command > header. These > requirements are mandating the presence of redundant > application ID AVPs in > the message body. Do you see any reason to keep these requirements? > > Regards > Mark > > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > Behalf Of Rajith R > > Sent: October 15, 2008 01:14 > > To: Mark Jones > > Cc: dime@ietf.org > > Subject: Re: [Dime] Application Id AVPs in message bodies > > > > Hi > > 1. Why these requirements should be removed? > > 2. The draft already states that an application id > AVP in the > > message body (non-CER/CEA) MUST match the Application Id > > present in the > > Diameter message header > > Is not this an altogether different requirement than the > ones you are > > suggesting to remove? I cannot understand how they are > related or am I > > missing something here? > > > > regards > > Rajith > > > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > Behalf Of Mark > > Jones > > Sent: Thursday, October 09, 2008 9:46 PM > > To: dime@ietf.org > > Subject: [Dime] Application Id AVPs in message bodies > > > > The 3588bis still has requirements for application ids to be > > present in > > non-CER/CEA messages: > > > > 6.11. Vendor-Specific-Application-Id AVP > > ... > > > > This AVP MUST also be present as the first AVP in all > experimental > > commands defined in the vendor-specific application. > > --- > > > > 9.7.1. Accounting-Request > > ... > > One of Acct-Application-Id and > Vendor-Specific-Application-Id AVPs > > MUST be present. If the Vendor-Specific-Application-Id > grouped AVP > > is present, it MUST include an Acct-Application-Id AVP. > > > > --- > > > > 9.7.2. Accounting-Answer > > ... > > One of Acct-Application-Id and > Vendor-Specific-Application-Id AVPs > > MUST be present. If the Vendor-Specific-Application-Id > grouped AVP > > is present, it MUST contain an Acct-Application-Id AVP. > > --- > > > > The draft already states that an application id AVP in the > > message body > > (non-CER/CEA) MUST match the Application Id present in the > > Diameter message > > header so I propose the above requirements be removed from 3588bis. > > Objections? > > > > Regards > > Mark > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:42:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1681A3A6C95; Wed, 15 Oct 2008 10:42:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81AB73A6768 for ; Wed, 15 Oct 2008 10:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.256 X-Spam-Level: X-Spam-Status: No, score=-5.256 tagged_above=-999 required=5 tests=[AWL=1.343, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDLDSc8bSEBh for ; Wed, 15 Oct 2008 10:42:31 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7C19A3A6975 for ; Wed, 15 Oct 2008 10:42:31 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhD2R029637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhAAa009266 for ; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:08 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:43:07 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status Update Thread-Index: Acku6FhV8UUrzVrqSTGyGSmmyIZThw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Oct 2008 17:43:08.0289 (UTC) FILETIME=[7C373710:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194313-40303BB0-2DE44F15/0-0/0-15 X-purgate-size: 159/0 Subject: [Dime] Status Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I am going to distribute the status update in separate mails this time. PLEASE correct me if there is anything missing or incorrect. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:42:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429173A6C9D; Wed, 15 Oct 2008 10:42:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB483A691C for ; Wed, 15 Oct 2008 10:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-VgkSePq9ZB for ; Wed, 15 Oct 2008 10:42:32 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C801F3A6C92 for ; Wed, 15 Oct 2008 10:42:31 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhDfh013325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhAAc009266 for ; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:09 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:43:07 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-diameter-api Thread-Index: Acku6GrUEvwNO/KaR1md+5rNPMGfNA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Oct 2008 17:43:08.0836 (UTC) FILETIME=[7C8AAE40:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194313-73815BB0-6350D3E4/0-0/0-15 X-purgate-size: 338/0 Subject: [Dime] draft-ietf-dime-diameter-api X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org According to the tracker Dan is waiting for a revised draft, see draft-ietf-dime-diameter-api The tracker also contains a couple of review comments that need to be addressed. ACTION ITEM: Dave to URGENTLY submit an update based on the review comments. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:42:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDC03A6922; Wed, 15 Oct 2008 10:42:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29B63A691C for ; Wed, 15 Oct 2008 10:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.27 X-Spam-Level: X-Spam-Status: No, score=-5.27 tagged_above=-999 required=5 tests=[AWL=1.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vYa2lqkLI7b for ; Wed, 15 Oct 2008 10:42:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B108A3A6768 for ; Wed, 15 Oct 2008 10:42:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhW8G030121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Oct 2008 19:43:32 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhURD011889 for ; Wed, 15 Oct 2008 19:43:32 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:09 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:43:07 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-mip6-integrated Thread-Index: Acku6G7WT0J8XzR+SDGqW0iOC9RZiA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Oct 2008 17:43:09.0382 (UTC) FILETIME=[7CDDFE60:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194332-40305BB0-D9843DC1/0-0/0-15 X-purgate-size: 216/0 Subject: [Dime] draft-ietf-dime-mip6-integrated X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The document is in IESG Evaluation state and everything is fine from what I can tell, see https://datatracker.ietf.org/idtracker/draft-ietf-dime-mip6-integrated/ No action from our side required. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:42:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DDF28C298; Wed, 15 Oct 2008 10:42:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4902228C28F for ; Wed, 15 Oct 2008 10:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.295 X-Spam-Level: X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUlMlLA91kQ1 for ; Wed, 15 Oct 2008 10:42:55 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 404893A6768 for ; Wed, 15 Oct 2008 10:42:55 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhXX2013687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Oct 2008 19:43:33 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhURN011889 for ; Wed, 15 Oct 2008 19:43:33 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:12 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:43:07 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-qos-attributes Thread-Index: Acku6KafOT8iuXv+Rwqvxx2gnXkiwA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Oct 2008 17:43:12.0007 (UTC) FILETIME=[7E6E8970:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194333-73811BB0-4142578A/0-0/0-15 X-purgate-size: 510/0 Subject: [Dime] draft-ietf-dime-qos-attributes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The Ethernet part about C-LAN/S-LAN VID wasn't entirely correct in the document as commented by Dan. The nested AVP structure is incompatible with the RADIUS attribute design. Ideas on what todo are welcome! If no ideas then we would skip it for this draft. ACTION ITEM: 1) Mark to incorporate the comments by Dan and resubmit the draft. 2) After completion of (1), issue a short WGLC (1 week) 3) After completion of (2), Dave to write the PROTO writeup and submit it to the IESG. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:43:08 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1EF28C2A0; Wed, 15 Oct 2008 10:43:08 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1D928C2A0 for ; Wed, 15 Oct 2008 10:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.282 X-Spam-Level: X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMUeut23M-JI for ; Wed, 15 Oct 2008 10:43:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 814613A691C for ; Wed, 15 Oct 2008 10:43:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhhMT013957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Oct 2008 19:43:43 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhhAJ009644 for ; Wed, 15 Oct 2008 19:43:43 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:13 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:41:27 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-app-design-guide Thread-Index: Acku7UAyAgtFXqLoSb2+GIucXzHwag== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Oct 2008 17:43:13.0648 (UTC) FILETIME=[7F68EF00:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194343-73811BB0-E5DBA087/0-0/0-15 X-purgate-size: 260/0 Subject: [Dime] draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This document needs an update to reflect the comments received on the mailing list, see http://www.ietf.org/mail-archive/web/dime/current/msg02742.html ACTION ITEM: Document authors to resubmit an updated draft for the draft submission deadline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:46:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5183A6975; Wed, 15 Oct 2008 10:46:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F563A6922 for ; Wed, 15 Oct 2008 10:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.27 X-Spam-Level: X-Spam-Status: No, score=-5.27 tagged_above=-999 required=5 tests=[AWL=1.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWty-en0BGoI for ; Wed, 15 Oct 2008 10:46:35 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 779903A67EF for ; Wed, 15 Oct 2008 10:46:35 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhDQZ029659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhAAg009266 for ; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:13 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:41:16 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-diameter-qos Thread-Index: Acku7TlVNAqY64rGRvaY925c7yFXxw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Oct 2008 17:43:13.0101 (UTC) FILETIME=[7F1577D0:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194313-40305BB0-253C4D6E/0-0/0-15 X-purgate-size: 209/0 Subject: [Dime] draft-ietf-dime-diameter-qos X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This document passed the WGLC. Note that the document has a normative dependency on draft-ietf-dime-qos-attributes ACTION ITEM: * Dave to write the PROTO writeup and submit it to the IESG. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:46:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4545428C262; Wed, 15 Oct 2008 10:46:38 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3363A6A0C for ; Wed, 15 Oct 2008 10:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.294 X-Spam-Level: X-Spam-Status: No, score=-5.294 tagged_above=-999 required=5 tests=[AWL=1.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmt2GUc7-XuI for ; Wed, 15 Oct 2008 10:46:36 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7B9913A67EF for ; Wed, 15 Oct 2008 10:46:36 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhDvD029647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhAAe009266 for ; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:10 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:43:07 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-qos-parameters Thread-Index: Acku6HZjmb6dMungQ7Ws5hmoleTbFQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Oct 2008 17:43:09.0929 (UTC) FILETIME=[7D317590:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194313-40303BB0-31A5C062/0-0/0-15 X-purgate-size: 368/0 Subject: [Dime] draft-ietf-dime-qos-parameters X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Dan did his AD review and had a couple of comments, see https://datatracker.ietf.org/idtracker/draft-ietf-dime-qos-parameters/. The comments can be found here: http://www.ietf.org/mail-archive/web/dime/current/msg02797.html (Review already posted on the 28th August) ACTION ITEM: Jouni and Hannes to address the comments and to update the draft. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:46:39 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7435128C29B; Wed, 15 Oct 2008 10:46:39 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDFB28C29B for ; Wed, 15 Oct 2008 10:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 tagged_above=-999 required=5 tests=[AWL=1.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ2OySy1GKkS for ; Wed, 15 Oct 2008 10:46:37 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7FF3D3A691C for ; Wed, 15 Oct 2008 10:46:37 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhhKA030390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Oct 2008 19:43:43 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhhAH009644 for ; Wed, 15 Oct 2008 19:43:43 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:12 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:41:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-mip6-split Thread-Index: Acku7TESRB1TKNheQzem40WFx/0b5g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Oct 2008 17:43:12.0554 (UTC) FILETIME=[7EC200A0:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194343-40304BB0-5F97D7A5/0-0/0-15 X-purgate-size: 402/0 Subject: [Dime] draft-ietf-dime-mip6-split X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The draft was updated to reflect the comments. The only open issue was related to the split of the Mobile IPv6 Status Codes registry into an independent document. ACTION ITEM: 1) Hannes and Jouni to make the necessary draft changes 2) After completion of (1), issue a short WGLC (1 week) 3) After completion of (2), Dave to write the PROTO writeup and submit it to the IESG. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 10:47:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3BFA3A6C77; Wed, 15 Oct 2008 10:47:00 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979DB3A67EF for ; Wed, 15 Oct 2008 10:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy9k3BPndh2k for ; Wed, 15 Oct 2008 10:46:58 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id CAF223A691C for ; Wed, 15 Oct 2008 10:46:58 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2682708rvf.49 for ; Wed, 15 Oct 2008 10:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=bSgTL/IRFeP2SwBC+v2yUEmyxBzDyE+9ipbHiDCvDn8=; b=Xrjv1GOkKkMRqAgYpInYTmLJnjVIAdqMywLzsNgcnsPbvT2TwC0Ih0hmWD+5CFFigR 3ue9VHtSVoHR5Y2UdRHuWoNQCo6v+B8QtOjfsS3i7WvWByyE10Yc+v8n6J8EJE4HprzM 9I/9RR/11bWvuzGDDr3ZTq8Gme3JlvjJOR0R8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=OZuJ3dnoWiwv99iYew5or0kut+KVd7B7LmDNOiahrzbGlW3qr2sG4jcMwlAtQly3ls 0MNFEy94A44wejSFe7VLMyobMhyYb2mTBKn1drr/KBDmWnbKltv6hKSQDVTx7FJ5QehN WjzSJnT7h5T0P49uVJYg9v8lff758YlMXrqoQ= Received: by 10.141.168.7 with SMTP id v7mr907883rvo.95.1224092873887; Wed, 15 Oct 2008 10:47:53 -0700 (PDT) Received: by 10.141.142.9 with HTTP; Wed, 15 Oct 2008 10:47:53 -0700 (PDT) Message-ID: <9cf5ced20810151047l758bac5y99427517bf384e57@mail.gmail.com> Date: Wed, 15 Oct 2008 13:47:53 -0400 From: "David Frascone" To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 16206c75f9c81f37 Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-diameter-api X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0514172606==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0514172606== Content-Type: multipart/alternative; boundary="----=_Part_24494_23966976.1224092873899" ------=_Part_24494_23966976.1224092873899 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Working on it. Expect an updated draft this week. -Dave On Wed, Oct 15, 2008 at 1:43 PM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > According to the tracker Dan is waiting for a revised draft, see > draft-ietf-dime-diameter-api > > > The tracker also contains a couple of review comments that need to be > addressed. > > ACTION ITEM: Dave to URGENTLY submit an update based on the review > comments. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ------=_Part_24494_23966976.1224092873899 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Working on it.  Expect an updated draft this week.

-Dave

On Wed, Oct 15, 2008 at 1:43 PM, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:
According to the tracker Dan is waiting for a revised draft, see
draft-ietf-dime-diameter-api
<http://tools.ietf.org/wg/dime/draft-ietf-dime-diameter-api/>

The tracker also contains a couple of review comments that need to be
addressed.

ACTION ITEM: Dave to URGENTLY submit an update based on the review
comments.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

------=_Part_24494_23966976.1224092873899-- --===============0514172606== 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://www.ietf.org/mailman/listinfo/dime --===============0514172606==-- From dime-bounces@ietf.org Wed Oct 15 10:53:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3D53A6C99; Wed, 15 Oct 2008 10:53:51 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1273A6C94 for ; Wed, 15 Oct 2008 10:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAtbLipKQSXL for ; Wed, 15 Oct 2008 10:53:46 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0950C3A6C80 for ; Wed, 15 Oct 2008 10:53:45 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhDpg013318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9FHhAAY009266; Wed, 15 Oct 2008 19:43:13 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:07 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Oct 2008 19:43:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Oct 2008 20:43:06 +0300 Message-ID: In-Reply-To: <09C9068466B79E4C938DC7737562404D01F98827@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-sun-dime-itu-t-rw-01 Thread-Index: AckJFl3SUio9iUyTRtC58dZoelRc3gQoeExABOi/0OAAXnGnEA== References: <20080828135239.62230@gmx.net><09C9068466B79E4C938DC7737562404D01D90BFB@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D01F98827@ILEXC2U01.ndc.lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sun, Dong (Dong)" , "Hannes Tschofenig" X-OriginalArrivalTime: 15 Oct 2008 17:43:07.0476 (UTC) FILETIME=[7BBB2940:01C92EED] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081015194313-73811BB0-E5DBBE37/0-0/0-15 X-purgate-size: 5231/0 Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-sun-dime-itu-t-rw-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, >Hannes, All, > >I have one question concerning the use of AVP Flag, when the >'M' bit is placed in the MAY Column (in a Diameter application >defined by other SDOs), what does it exactly mean? Is this >interpretation correct? >- i.e. the originator may set the 'M' bit, if it did, the >receiver shall reject the message if the AVP or content is not >recognized. If originator = sender of the message then this is correct. Regarding the error behavior see Section 7 of RFC3588bis: http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-12#section-7 > >If it is the case, that means It depends on the >implementation, then how to ensure the interop? No, I don't see the interop problems. It just means that the setting of the AVP is not determined at the time of writing the specification but rather at the time when the message is sent or at the time the specific application is configured on a certain host. Ciao Hannes > >Thanks, >Dong > >-----Original Message----- >From: Sun, Dong (Dong) >Sent: Thursday, September 18, 2008 11:16 PM >To: 'Hannes Tschofenig'; 'aaa-doctors@ietf.org' >Cc: 'dime@ietf.org' >Subject: RE: [Dime] Review of draft-sun-dime-itu-t-rw-01 > >Hannes, > >I understood your concern on the modification of the ABNF of >existing Diameter Credit control commands e.g. CCR/CCA. >However, those changes are made originally by 3GPP 29.212 Gx >interface. The ITU-T Q.3303.3 just reuses what are defined by >Gx interface in order to avoid the interoperability problem >with other SDOs (e.g. including WiMAX and 3GPP2 since both >them are based on 3GPP Gx). > >Regarding the indications of "M"/"P" bits, all them are copied >from other specs. I will try to fix it for this spec if >possible. Same to the NASREQ issue. > >Thanks for the review and comments, although they are more >related to the ITU-T spec instead of this IETF I-D. > >Rgs, >Dong > >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Hannes Tschofenig >Sent: Thursday, August 28, 2008 9:53 AM >To: aaa-doctors@ietf.org >Cc: dime@ietf.org >Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01 > >I reviewed draft-sun-dime-itu-t-rw-01 the normative reference: > > [Q.3303.3] > ITU-T Recommendation Q.3303.3, "Resource control protocol > no. 3 (rcp3): Protocol at the Rw interface between the > Policy Decision Physical Entity (PD-PE) and the Policy > Enforcement Physical Entity (PE-PE): Diameter", 2008. > > >I think it is the right decision to define two new command codes (PIR / >PIA) as it is done in [Q.3303.3]. > >HOWEVER, more command codes must be specified as the ABNF of >existing Diameter Base Protocol and Diameter Credit Control >Commands has been modified. I therefore request that >[Q.3303.3] be changed in the following way since they would >cause interoperability problems with existing Diameter Base >Protocol and Diameter Credit Control implementations. > >* CCR Command > >The ABNF of the original CCR command is modified by removing >the required Service-Context-ID AVP. > >* CCA Command > >The ABNF of the original CCA command is modified by turning >the required Result-Code AVP into an optional one. > >* RAA Command > >The ABNF of the original RAA command is modified by turning >the required Result-Code AVP into an optional one. > >* ASR Command > >The ABNF of the original ASR command is modified by adding the >required Abort-Cause AVP. > >* ASA Command > >The ABNF of the original ASA command is modified by turning >the required Result-Code AVP into an optional one. > > >The simplest way to solve these issues is to register new >command codes. >Alternatively you could think about why you actually need to >modify the ABNF of these commands. > >Another remark: A couple of tables are listed with AVP flag >settings. I got the impression that these flag settings got >copied from other documents. This could be a problem since the >M-bit (and other flags) meaning is specific for the specific >application and command. A new Diameter application/Command >may require a different flag setting. I hope that the ITU-T >checked this aspect since otherwise they will experience a lot >of interop issues. > >Table 2 is missing indications about the M bit usage. >Table 3 is missing indications about the P bit usage. >Table 4 is missing indications about the P bit usage. > >A minor issue: > >The description about soft-state vs. hard-state was confusing >since there is no Reservation-Lifetime AVP specified. >Furthermore the text refers to NASREQ and the specification >does not use NASREQ. > > >Ciao >Hannes >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 12:24:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4953A691A; Wed, 15 Oct 2008 12:24:59 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB463A67A6 for ; Wed, 15 Oct 2008 12:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM8K+3dmlKfb for ; Wed, 15 Oct 2008 12:24:57 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by core3.amsl.com (Postfix) with ESMTP id 5D7B53A691A for ; Wed, 15 Oct 2008 12:24:57 -0700 (PDT) Received: from [83.245.213.73] (a83-245-213-73.elisa-laajakaista.fi [83.245.213.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id CB66E15153D; Wed, 15 Oct 2008 22:25:52 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <30D42911-F15C-4DF5-80FF-D3813F4E2A90@iki.fi> From: Jouni Korhonen Date: Wed, 15 Oct 2008 22:25:51 +0300 To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.753.1) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-mip6-split X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Oct 15, 2008, at 8:41 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > The draft was updated to reflect the comments. > The only open issue was related to the split of the Mobile IPv6 Status > Codes registry into an independent document. > > ACTION ITEM: > 1) Hannes and Jouni to make the necessary draft changes I presume you mean the hanging IPR issues? What do you suggest then as a way forward? > 2) After completion of (1), issue a short WGLC (1 week) > 3) After completion of (2), Dave to write the PROTO writeup and submit > it to the IESG. Sounds fine ;) Jouni > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 15 21:03:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8ED3A6B08; Wed, 15 Oct 2008 21:03:56 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7F93A6B08 for ; Wed, 15 Oct 2008 21:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxoqiY8hOuBV for ; Wed, 15 Oct 2008 21:03:54 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id F08C93A6843 for ; Wed, 15 Oct 2008 21:03:53 -0700 (PDT) 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 <0K8T00HIMCNV33@szxga01-in.huawei.com> for dime@ietf.org; Thu, 16 Oct 2008 12:04:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8T00JYRCNVAX@szxga01-in.huawei.com> for dime@ietf.org; Thu, 16 Oct 2008 12:04:43 +0800 (CST) Received: from huawei1515 ([10.18.28.31]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8T009RNCNUPI@szxml03-in.huawei.com> for dime@ietf.org; Thu, 16 Oct 2008 12:04:43 +0800 (CST) Date: Thu, 16 Oct 2008 09:34:42 +0530 From: Rajith R In-reply-to: To: 'Mark Jones' Message-id: <000c01c92f44$52199660$1f1c120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AckqKloMqqNff+crTtixmp6nrGXZDwEWWtfQABBSLFAAAiODMAABJRdAABxa86A= Cc: dime@ietf.org Subject: Re: [Dime] Application Id AVPs in message bodies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Some comments inline. > -----Original Message----- > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] > Sent: Wednesday, October 15, 2008 8:46 PM > To: rajithr@huawei.com > Cc: dime@ietf.org > Subject: RE: [Dime] Application Id AVPs in message bodies > > Hi Rajith, > > Answers inline... > > > -----Original Message----- > > From: Rajith R [mailto:rajithr@huawei.com] > > Sent: October 15, 2008 10:21 > > To: Mark Jones > > Cc: dime@ietf.org > > Subject: RE: [Dime] Application Id AVPs in message bodies > > > > Hi > > I know of some Diameter applications that share the > > same application > > Id value b/w an Auth. & Accounting application, for e.g. 3GPP > > Rel-6 Cx & > > Accounting (see 32.299 v6.0.0) share the same application Id > > viz. 16777216. > > An explicit Auth- or Acct-Application-Id AVP in the message > > is needed in > > this case. > > The Diameter command header contains an application id and a command > code. That is sufficient to uniquely identify a command type without > parsing the message for additional AVPs. [Rajith R] This is ok for the server application handling the command. However the relay, to route it to the correct server, viz. the HSS or the OCS, will use only the Application Id (& of course the Destination Realm), not the command code. In this case, the specific Application Id AVP in the message may have a use. > > > Also, if 2 vendors provide the implementation of the > > same Diameter > > application, would not the Vendor Specific Application Id be useful > in > > request routing? > > > > The Vendor-Specific-Application-Id AVP in the message body MUST > contain the same value as the Diameter command header so I don't see > how the AVP can be useful for request routing. You may want to review > section 6.11 in 3588bis because I think you may be misusing the > Vendor-Id in the Vendor-Specific-Application-Id AVP. > [Rajith R] I would like to retain this AVP also because I think it will help relays to route the Diameter message to an appropriate server, if there are 2 vendor specific implementations of the same application in a realm. > Regards > Mark > > > Regards > > Rajith > > > > -----Original Message----- > > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] > > Sent: Wednesday, October 15, 2008 6:30 PM > > To: rajithr@huawei.com > > Cc: dime@ietf.org > > Subject: RE: [Dime] Application Id AVPs in message bodies > > > > Hi Rajith, > > > > The application ID is always present in the Diameter command > > header. These > > requirements are mandating the presence of redundant > > application ID AVPs in > > the message body. Do you see any reason to keep these requirements? > > > > Regards > > Mark > > > > > -----Original Message----- > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > > Behalf Of Rajith R > > > Sent: October 15, 2008 01:14 > > > To: Mark Jones > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] Application Id AVPs in message bodies > > > > > > Hi > > > 1. Why these requirements should be removed? > > > 2. The draft already states that an application id > > AVP in the > > > message body (non-CER/CEA) MUST match the Application Id > > > present in the > > > Diameter message header > > > Is not this an altogether different requirement than the > > ones you are > > > suggesting to remove? I cannot understand how they are > > related or am I > > > missing something here? > > > > > > regards > > > Rajith > > > > > > -----Original Message----- > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > > Behalf Of Mark > > > Jones > > > Sent: Thursday, October 09, 2008 9:46 PM > > > To: dime@ietf.org > > > Subject: [Dime] Application Id AVPs in message bodies > > > > > > The 3588bis still has requirements for application ids to be > > > present in > > > non-CER/CEA messages: > > > > > > 6.11. Vendor-Specific-Application-Id AVP > > > ... > > > > > > This AVP MUST also be present as the first AVP in all > > experimental > > > commands defined in the vendor-specific application. > > > --- > > > > > > 9.7.1. Accounting-Request > > > ... > > > One of Acct-Application-Id and > > Vendor-Specific-Application-Id AVPs > > > MUST be present. If the Vendor-Specific-Application-Id > > grouped AVP > > > is present, it MUST include an Acct-Application-Id AVP. > > > > > > --- > > > > > > 9.7.2. Accounting-Answer > > > ... > > > One of Acct-Application-Id and > > Vendor-Specific-Application-Id AVPs > > > MUST be present. If the Vendor-Specific-Application-Id > > grouped AVP > > > is present, it MUST contain an Acct-Application-Id AVP. > > > --- > > > > > > The draft already states that an application id AVP in the > > > message body > > > (non-CER/CEA) MUST match the Application Id present in the > > > Diameter message > > > header so I propose the above requirements be removed from > 3588bis. > > > Objections? > > > > > > Regards > > > Mark > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 16 06:54:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6552A3A6805; Thu, 16 Oct 2008 06:54:02 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236673A6805 for ; Thu, 16 Oct 2008 06:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAV49wkuFJyG for ; Thu, 16 Oct 2008 06:54:00 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id C15743A6800 for ; Thu, 16 Oct 2008 06:53:59 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 16 Oct 2008 09:54:56 -0400 From: Mark Jones To: "rajithr@huawei.com" Date: Thu, 16 Oct 2008 09:54:55 -0400 Thread-Topic: [Dime] Application Id AVPs in message bodies Thread-Index: AckqKloMqqNff+crTtixmp6nrGXZDwEWWtfQABBSLFAAAiODMAABJRdAABxa86AAFBo+EA== Message-ID: References: <000c01c92f44$52199660$1f1c120a@china.huawei.com> In-Reply-To: <000c01c92f44$52199660$1f1c120a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Application Id AVPs in message bodies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Comments inline... > -----Original Message----- > From: Rajith R [mailto:rajithr@huawei.com] > Sent: October 16, 2008 00:05 > To: Mark Jones > Cc: dime@ietf.org > Subject: RE: [Dime] Application Id AVPs in message bodies > > Hi > Some comments inline. > > -----Original Message----- > > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] > > Sent: Wednesday, October 15, 2008 8:46 PM > > To: rajithr@huawei.com > > Cc: dime@ietf.org > > Subject: RE: [Dime] Application Id AVPs in message bodies > > > > Hi Rajith, > > > > Answers inline... > > > > > -----Original Message----- > > > From: Rajith R [mailto:rajithr@huawei.com] > > > Sent: October 15, 2008 10:21 > > > To: Mark Jones > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Application Id AVPs in message bodies > > > > > > Hi > > > I know of some Diameter applications that share the > > > same application > > > Id value b/w an Auth. & Accounting application, for e.g. 3GPP > > > Rel-6 Cx & > > > Accounting (see 32.299 v6.0.0) share the same application Id > > > viz. 16777216. > > > An explicit Auth- or Acct-Application-Id AVP in the message > > > is needed in > > > this case. > > > > The Diameter command header contains an application id and a command > > code. That is sufficient to uniquely identify a command type without > > parsing the message for additional AVPs. > [Rajith R] This is ok for the server application handling the command. > However the relay, to route it to the correct server, viz. > the HSS or the > OCS, will use only the Application Id (& of course the > Destination Realm), > not the command code. In this case, the specific Application > Id AVP in the > message may have a use. [MJ] You can not have one application id in the command header and a different one in the message body. This is explicitly forbidden by 3588bis sections 6.8/6.9/6.11. Are you requesting this text be removed from 3588bis? If you have a vendor-specific implementation that has its own vendor-specific Application Id then you would put that Id in the Diameter command header and proxies/relays would route based on it. > > > > > Also, if 2 vendors provide the implementation of the > > > same Diameter > > > application, would not the Vendor Specific Application Id > be useful > > in > > > request routing? > > > > > > > The Vendor-Specific-Application-Id AVP in the message body MUST > > contain the same value as the Diameter command header so I don't see > > how the AVP can be useful for request routing. You may want > to review > > section 6.11 in 3588bis because I think you may be misusing the > > Vendor-Id in the Vendor-Specific-Application-Id AVP. > > > [Rajith R] I would like to retain this AVP also because I > think it will help > relays to route the Diameter message to an appropriate > server, if there are > 2 vendor specific implementations of the same application in a realm. [MJ] The Vendor-Id in the Vendor-Specific-Application-Id is that of the application author. It is not the Id assigned to the vendor of the Diameter device so I don't see how it helps in message routing. > > Regards > > Mark > > > > > Regards > > > Rajith > > > > > > -----Original Message----- > > > From: Mark Jones [mailto:Mark.Jones@bridgewatersystems.com] > > > Sent: Wednesday, October 15, 2008 6:30 PM > > > To: rajithr@huawei.com > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] Application Id AVPs in message bodies > > > > > > Hi Rajith, > > > > > > The application ID is always present in the Diameter command > > > header. These > > > requirements are mandating the presence of redundant > > > application ID AVPs in > > > the message body. Do you see any reason to keep these > requirements? > > > > > > Regards > > > Mark > > > > > > > -----Original Message----- > > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > > > Behalf Of Rajith R > > > > Sent: October 15, 2008 01:14 > > > > To: Mark Jones > > > > Cc: dime@ietf.org > > > > Subject: Re: [Dime] Application Id AVPs in message bodies > > > > > > > > Hi > > > > 1. Why these requirements should be removed? > > > > 2. The draft already states that an application id > > > AVP in the > > > > message body (non-CER/CEA) MUST match the Application Id > > > > present in the > > > > Diameter message header > > > > Is not this an altogether different requirement than the > > > ones you are > > > > suggesting to remove? I cannot understand how they are > > > related or am I > > > > missing something here? > > > > > > > > regards > > > > Rajith > > > > > > > > -----Original Message----- > > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > > > Behalf Of Mark > > > > Jones > > > > Sent: Thursday, October 09, 2008 9:46 PM > > > > To: dime@ietf.org > > > > Subject: [Dime] Application Id AVPs in message bodies > > > > > > > > The 3588bis still has requirements for application ids to be > > > > present in > > > > non-CER/CEA messages: > > > > > > > > 6.11. Vendor-Specific-Application-Id AVP > > > > ... > > > > > > > > This AVP MUST also be present as the first AVP in all > > > experimental > > > > commands defined in the vendor-specific application. > > > > --- > > > > > > > > 9.7.1. Accounting-Request > > > > ... > > > > One of Acct-Application-Id and > > > Vendor-Specific-Application-Id AVPs > > > > MUST be present. If the Vendor-Specific-Application-Id > > > grouped AVP > > > > is present, it MUST include an Acct-Application-Id AVP. > > > > > > > > --- > > > > > > > > 9.7.2. Accounting-Answer > > > > ... > > > > One of Acct-Application-Id and > > > Vendor-Specific-Application-Id AVPs > > > > MUST be present. If the Vendor-Specific-Application-Id > > > grouped AVP > > > > is present, it MUST contain an Acct-Application-Id AVP. > > > > --- > > > > > > > > The draft already states that an application id AVP in the > > > > message body > > > > (non-CER/CEA) MUST match the Application Id present in the > > > > Diameter message > > > > header so I propose the above requirements be removed from > > 3588bis. > > > > Objections? > > > > > > > > Regards > > > > Mark > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 17 01:18:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98D83A6A1D; Fri, 17 Oct 2008 01:18:03 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E5B3A6A1D for ; Fri, 17 Oct 2008 01:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XJGwmqfcNxw for ; Fri, 17 Oct 2008 01:18:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DC7473A6A04 for ; Fri, 17 Oct 2008 01:18:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,430,1220227200"; d="scan'208";a="22904640" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Oct 2008 08:19:04 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9H8J4Ba006714 for ; Fri, 17 Oct 2008 10:19:04 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9H8J3LN016456 for ; Fri, 17 Oct 2008 08:19:04 GMT Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 10:19:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 10:19:00 +0200 Message-ID: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dime rechartering: Include Carrier-Grade NAT Control Application? Thread-Index: AckwMQINIrNJlrV1Q0+CULAtiftVyg== From: "Frank Brockners (fbrockne)" To: X-OriginalArrivalTime: 17 Oct 2008 08:19:02.0627 (UTC) FILETIME=[03748B30:01C93031] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1433; t=1224231544; x=1225095544; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fbrockne@cisco.com; z=From:=20=22Frank=20Brockners=20(fbrockne)=22=20 |Subject:=20Dime=20rechartering=3A=20Include=20Carrier-Grad e=20NAT=20Control=20Application? |Sender:=20; bh=fqm8B2GYIyAXzJLu340Q0qIvc5Ww+Sh+uFGqvr7XJJE=; b=rrYwVxGNYdCqyS3vN2xTBJSsPRX8NO7J6rAVdvkrYBxw0HNsiR3coy46kM F3V21DQFg6BbJ1XRs60fUhpj/1t3rjUxVJQBd1gX60nqHOLyL+QtIIUQmXCJ 6LgCqOT/xS; Authentication-Results: ams-dkim-2; header.From=fbrockne@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, while re-chartering DIME, could we consider a new application for Carrier-Grade NAT (CGN) control? CGN has become an important topic within the IPv4-completion/exhaustion debate - also proven by the significant number of drafts on this particular topic. Consequently, per endpoint control of a CGN is an important question to be addressed. Please find an abstract of a forthcoming draft below. I'm working on the full draft, but wanted to get the abstract out asap so that the work can be considered as part of the new charter. Thanks, Frank -- Title Diameter Carrier-Grade NAT Control Application Abstract The document will describe the framework, messages and procedures for the Diameter Carrier-Grade NAT Control (CGNC) application. The Diameter CGNC application allows gateways (e.g. Network Access Server (NAS)) to interact with Carrier-Grade NAT (CGN) devices. The interaction is to establish a context to commonly identify and manage endpoints on gateway and CGN. It is to allow the gateway to control and manage the behavior of a CGN on a per-endpoint basis (e.g. control the total number of bindings for a particular endpoint, request the allocation of a binding for a particular endpoint). In addition, it allows the CGN to provide information relevant to accounting purposes to the gateway (e.g. allocated NAT bindings etc.). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 17 05:04:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3CA3A6AB6; Fri, 17 Oct 2008 05:04:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383CD3A6AB2 for ; Fri, 17 Oct 2008 05:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLCgPRy-F80L for ; Fri, 17 Oct 2008 05:04:10 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id A89DC3A6A9C for ; Fri, 17 Oct 2008 05:04:10 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA10.westchester.pa.mail.comcast.net with comcast id TnMH1a01917dt5G5Ao5Ehg; Fri, 17 Oct 2008 12:05:14 +0000 Received: from gwzPC ([124.120.218.73]) by OMTA13.westchester.pa.mail.comcast.net with comcast id To4Q1a00T1bcMng3Zo4sKB; Fri, 17 Oct 2008 12:05:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=oAOlMMomtzoA:10 a=nCxB-eOLojEA:10 a=87HCN65oS2n4gQwaFmwA:9 a=Kz2V5eKc8xdUdYoHsjrt1vJl3cgA:4 a=JfD0Fch1gWkA:10 a=iYlkOlhu7C0A:10 From: "Glen Zorn" To: "'Frank Brockners \(fbrockne\)'" References: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com> In-Reply-To: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com> Date: Fri, 17 Oct 2008 19:03:30 +0700 Message-ID: <002a01c93050$6d9afac0$48d0f040$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckwMQINIrNJlrV1Q0+CULAtiftVygAHxUog Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Frank Brockners [fbrockne@cisco.com] writes: > Hi, > > while re-chartering DIME, could we consider a new application for > Carrier-Grade NAT (CGN) control? Sounds reasonable to me. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 17 06:52:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ADBB3A68A2; Fri, 17 Oct 2008 06:52:04 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985283A681D for ; Fri, 17 Oct 2008 06:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2Iwamyj5OsB for ; Fri, 17 Oct 2008 06:52:02 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id AA8F93A68A2 for ; Fri, 17 Oct 2008 06:52:02 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so494011rvf.49 for ; Fri, 17 Oct 2008 06:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=PgbUVv0dpHMTkx3954zz3tA6hNCc6bvtHECctyZqS4U=; b=gXINl1kZD8wLp90WM+ZMrlQIPeoqFGXBVFg2zRjrp4+o1f+78/Cs4BBMLybsNXr04b YSLV/stUbduHW4oCQo1PQ4VQ6mTFEuOhtaQzVahYmAu4FlMouqeFf41i0nQP7Arujfb/ A7RmBov31YwrU0KFnNwUV91jemkBL5FoxexnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=XAVHQIfHYSc9jSKAlkAD/Tojg5r2YM0snyx63AQjbDKzAlpLEe9WBCR2PRbYPJ94XR PVsN9R94R9qo5j//94JeackK9AOuczOYh389kJsSIlUBX01DvifLBsQZC2rdIA4k09Fb dOY4umDnFKBHSZGKMnAFFTGbmANdNxJCDBKT8= Received: by 10.141.128.19 with SMTP id f19mr2521648rvn.257.1224251586389; Fri, 17 Oct 2008 06:53:06 -0700 (PDT) Received: by 10.141.142.9 with HTTP; Fri, 17 Oct 2008 06:53:06 -0700 (PDT) Message-ID: <9cf5ced20810170653j4dd39b3dy851e21eb5da8e27f@mail.gmail.com> Date: Fri, 17 Oct 2008 09:53:06 -0400 From: "David Frascone" To: "Frank Brockners (fbrockne)" In-Reply-To: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com> MIME-Version: 1.0 References: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com> X-Google-Sender-Auth: eeda0d9e7070a26e Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0365138826==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0365138826== Content-Type: multipart/alternative; boundary="----=_Part_53675_25266391.1224251586379" ------=_Part_53675_25266391.1224251586379 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Do you think we could have a draft before the meeting? On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne) < fbrockne@cisco.com> wrote: > Hi, > > while re-chartering DIME, could we consider a new application for > Carrier-Grade NAT (CGN) control? CGN has become an important topic > within the IPv4-completion/exhaustion debate - also proven by the > significant number of drafts on this particular topic. Consequently, per > endpoint control of a CGN is an important question to be addressed. > Please find an abstract of a forthcoming draft below. I'm working on the > full draft, but wanted to get the abstract out asap so that the work can > be considered as part of the new charter. > > Thanks, Frank > > -- > > Title > > Diameter Carrier-Grade NAT Control Application > > Abstract > > The document will describe the framework, messages and procedures for > the Diameter Carrier-Grade NAT Control (CGNC) application. The > Diameter > CGNC application allows gateways (e.g. Network Access Server (NAS)) > to > interact with Carrier-Grade NAT (CGN) devices. The interaction is to > establish a context to commonly identify and manage endpoints on > gateway and CGN. It is to allow the gateway to control and manage the > > behavior of a CGN on a per-endpoint basis (e.g. control the total > number > of bindings for a particular endpoint, request the allocation of > a binding for a particular endpoint). In addition, it allows the CGN > to provide information relevant to accounting purposes to the gateway > > (e.g. allocated NAT bindings etc.). > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ------=_Part_53675_25266391.1224251586379 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Do you think we could have a draft before the meeting?

On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne) <fbrockne@cisco.com> wrote:
Hi,

while re-chartering DIME, could we consider a new application for
Carrier-Grade NAT (CGN) control? CGN has become an important topic
within the IPv4-completion/exhaustion debate - also proven by the
significant number of drafts on this particular topic. Consequently, per
endpoint control of a CGN is an important question to be addressed.
Please find an abstract of a forthcoming draft below. I'm working on the
full draft, but wanted to get the abstract out asap so that the work can
be considered as part of the new charter.

Thanks, Frank

--

Title

  Diameter Carrier-Grade NAT Control Application

Abstract

  The document will describe the framework, messages and procedures for
  the Diameter Carrier-Grade NAT Control (CGNC) application.  The
Diameter
  CGNC application allows gateways (e.g. Network Access Server (NAS))
to
  interact with Carrier-Grade NAT (CGN) devices. The interaction is to
  establish a context to commonly identify and manage endpoints on
  gateway and CGN. It is to allow the gateway to control and manage the

  behavior of a CGN on a per-endpoint basis (e.g. control the total
number
  of bindings for a particular endpoint, request the allocation of
  a binding for a particular endpoint). In addition, it allows the CGN
  to provide information relevant to accounting purposes to the gateway

  (e.g. allocated NAT bindings etc.).
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

------=_Part_53675_25266391.1224251586379-- --===============0365138826== 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://www.ietf.org/mailman/listinfo/dime --===============0365138826==-- From dime-bounces@ietf.org Fri Oct 17 07:12:40 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558723A68A2; Fri, 17 Oct 2008 07:12:40 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569913A68A2 for ; Fri, 17 Oct 2008 07:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ4hlVuCje1a for ; Fri, 17 Oct 2008 07:12:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C77583A6897 for ; Fri, 17 Oct 2008 07:12:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,431,1220227200"; d="scan'208,217";a="22960329" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Oct 2008 14:13:38 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9HEDcGA017411; Fri, 17 Oct 2008 16:13:38 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9HEDcqd003703; Fri, 17 Oct 2008 14:13:38 GMT Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 16:13:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 16:13:37 +0200 Message-ID: <693E0961C9EFD946AC7067D67746362506986661@xmb-ams-336.emea.cisco.com> In-Reply-To: <9cf5ced20810170653j4dd39b3dy851e21eb5da8e27f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? Thread-Index: AckwX+OUa1V7paSCTyOqDUGGJsMv2AAAoPmA From: "Frank Brockners (fbrockne)" To: "David Frascone" X-OriginalArrivalTime: 17 Oct 2008 14:13:38.0319 (UTC) FILETIME=[8CC181F0:01C93062] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6205; t=1224252818; x=1225116818; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fbrockne@cisco.com; z=From:=20=22Frank=20Brockners=20(fbrockne)=22=20 |Subject:=20RE=3A=20[Dime]=20Dime=20rechartering=3A=20Inclu de=20Carrier-Grade=20NAT=20Control=20Application? |Sender:=20; bh=TJumIzH/qe2gsJ+iNOdsAoX7bKrtWNW30uSmEU9VApk=; b=XYQ5uV7Ej883G5Aml7xZ2DqgKbl0pBlr2aSWJpHwVoYkqXb08nSxAGwTTd AOUUDjdFcO2gSmns/gaGLThK37h5a7b+jVWJZgxTYUB2Wlp9Lwk4C6ywFhvs IU2uo/NxlU; Authentication-Results: ams-dkim-1; header.From=fbrockne@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0952113348==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0952113348== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93062.8C8B33C1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93062.8C8B33C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ..will try but am not 100% sure yet. Frank ________________________________ From: frascone@gmail.com [mailto:frascone@gmail.com] On Behalf Of David Frascone Sent: Friday, October 17, 2008 3:53 PM To: Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? =09 =09 Do you think we could have a draft before the meeting? =09 =09 On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne) wrote: =09 Hi, =09 while re-chartering DIME, could we consider a new application for Carrier-Grade NAT (CGN) control? CGN has become an important topic within the IPv4-completion/exhaustion debate - also proven by the significant number of drafts on this particular topic. Consequently, per endpoint control of a CGN is an important question to be addressed. Please find an abstract of a forthcoming draft below. I'm working on the full draft, but wanted to get the abstract out asap so that the work can be considered as part of the new charter. =09 Thanks, Frank =09 -- =09 Title =09 Diameter Carrier-Grade NAT Control Application =09 Abstract =09 The document will describe the framework, messages and procedures for the Diameter Carrier-Grade NAT Control (CGNC) application. The Diameter CGNC application allows gateways (e.g. Network Access Server (NAS)) to interact with Carrier-Grade NAT (CGN) devices. The interaction is to establish a context to commonly identify and manage endpoints on gateway and CGN. It is to allow the gateway to control and manage the =09 behavior of a CGN on a per-endpoint basis (e.g. control the total number of bindings for a particular endpoint, request the allocation of a binding for a particular endpoint). In addition, it allows the CGN to provide information relevant to accounting purposes to the gateway =09 (e.g. allocated NAT bindings etc.). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =09 ------_=_NextPart_001_01C93062.8C8B33C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
..will try but am not 100% sure yet.=20 Frank

From: frascone@gmail.com=20 [mailto:frascone@gmail.com] On Behalf Of David = Frascone
Sent:=20 Friday, October 17, 2008 3:53 PM
To: Frank Brockners=20 (fbrockne)
Cc: dime@ietf.org
Subject: Re: [Dime] = Dime=20 rechartering: Include Carrier-Grade NAT Control=20 Application?

Do you think we could have a draft before the = meeting?

On Fri, Oct 17, 2008 at 4:19 AM, Frank = Brockners=20 (fbrockne) <fbrockne@cisco.com> = wrote:
Hi,

while=20 re-chartering DIME, could we consider a new application = for
Carrier-Grade=20 NAT (CGN) control? CGN has become an important topic
within the=20 IPv4-completion/exhaustion debate - also proven by = the
significant number=20 of drafts on this particular topic. Consequently, per
endpoint = control of=20 a CGN is an important question to be addressed.
Please find an = abstract=20 of a forthcoming draft below. I'm working on the
full draft, but = wanted=20 to get the abstract out asap so that the work can
be considered = as part=20 of the new charter.

Thanks,=20 Frank

--

Title

  Diameter Carrier-Grade = NAT=20 Control Application

Abstract

  The document will = describe=20 the framework, messages and procedures for
  the Diameter=20 Carrier-Grade NAT Control (CGNC) application.=20  The
Diameter
  CGNC application allows gateways = (e.g.=20 Network Access Server (NAS))
to
  interact with = Carrier-Grade NAT=20 (CGN) devices. The interaction is to
  establish a context = to=20 commonly identify and manage endpoints on
  gateway and CGN. = It is=20 to allow the gateway to control and manage the

  = behavior of a=20 CGN on a per-endpoint basis (e.g. control the = total
number
  of=20 bindings for a particular endpoint, request the allocation = of
  a=20 binding for a particular endpoint). In addition, it allows the = CGN
 =20 to provide information relevant to accounting purposes to the=20 gateway

  (e.g. allocated NAT bindings=20 etc.).
_______________________________________________
DiME = mailing=20 list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

------_=_NextPart_001_01C93062.8C8B33C1-- --===============0952113348== 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://www.ietf.org/mailman/listinfo/dime --===============0952113348==-- From dime-bounces@ietf.org Fri Oct 17 14:41:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F5A3A6AEF; Fri, 17 Oct 2008 14:41:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92023A69B9 for ; Fri, 17 Oct 2008 14:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCelGFuMP2Fg for ; Fri, 17 Oct 2008 14:41:14 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 80FE53A6AB6 for ; Fri, 17 Oct 2008 14:41:14 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Fri, 17 Oct 2008 17:42:15 -0400 From: Avi Lior To: David Frascone , "Frank Brockners (fbrockne)" Date: Fri, 17 Oct 2008 17:42:13 -0400 Thread-Topic: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? Thread-Index: AckwX8T3ySFkqEURSt+aixgVjkUpmAAQLsRA Message-ID: <8A8CFE8F89C38B41A749C19328C76D6308AE2281F6@exchange02.bridgewatersys.com> References: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com> <9cf5ced20810170653j4dd39b3dy851e21eb5da8e27f@mail.gmail.com> In-Reply-To: <9cf5ced20810170653j4dd39b3dy851e21eb5da8e27f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0412689557==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0412689557== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_8A8CFE8F89C38B41A749C19328C76D6308AE2281F6exchange02bri_" --_000_8A8CFE8F89C38B41A749C19328C76D6308AE2281F6exchange02bri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, I agree with Frank that having such an application is required and now is t= he time to work on it. I have been engaged with several wireless operators that are planning to de= ploy a CGN in the next year. I have been developing a set of AAA requireme= nts to support such deployements over the past month. It would be good to develop those as the CGN draft is being progressed. Avi ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Dav= id Frascone Sent: October 17, 2008 9:53 AM To: Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Ap= plication? Do you think we could have a draft before the meeting? On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne) > wrote: Hi, while re-chartering DIME, could we consider a new application for Carrier-Grade NAT (CGN) control? CGN has become an important topic within the IPv4-completion/exhaustion debate - also proven by the significant number of drafts on this particular topic. Consequently, per endpoint control of a CGN is an important question to be addressed. Please find an abstract of a forthcoming draft below. I'm working on the full draft, but wanted to get the abstract out asap so that the work can be considered as part of the new charter. Thanks, Frank -- Title Diameter Carrier-Grade NAT Control Application Abstract The document will describe the framework, messages and procedures for the Diameter Carrier-Grade NAT Control (CGNC) application. The Diameter CGNC application allows gateways (e.g. Network Access Server (NAS)) to interact with Carrier-Grade NAT (CGN) devices. The interaction is to establish a context to commonly identify and manage endpoints on gateway and CGN. It is to allow the gateway to control and manage the behavior of a CGN on a per-endpoint basis (e.g. control the total number of bindings for a particular endpoint, request the allocation of a binding for a particular endpoint). In addition, it allows the CGN to provide information relevant to accounting purposes to the gateway (e.g. allocated NAT bindings etc.). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_8A8CFE8F89C38B41A749C19328C76D6308AE2281F6exchange02bri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
David,
 
I=20 agree with Frank that having such an application is required and now is the= time=20 to work on it.
 
I=20 have been engaged with several wireless operators that are planning to depl= oy a=20 CGN in the next year.  I have been developing a set of AAA requirement= s to=20 support such deployements over the past month.
 
It=20 would be good to develop those as the CGN draft is being=20 progressed.
 
Avi 

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of David=20 Frascone
Sent: October 17, 2008 9:53 AM
To: Frank=20 Brockners (fbrockne)
Cc: dime@ietf.org
Subject: Re: [= Dime]=20 Dime rechartering: Include Carrier-Grade NAT Control=20 Application?

Do you think we could have a draft before the meeting?
=
On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners= =20 (fbrockne) <fbrockne@cisco.com> wrot= e:
Hi,

while=20 re-chartering DIME, could we consider a new application for
Carrier-= Grade=20 NAT (CGN) control? CGN has become an important topic
within the=20 IPv4-completion/exhaustion debate - also proven by the
significant n= umber=20 of drafts on this particular topic. Consequently, per
endpoint contr= ol of=20 a CGN is an important question to be addressed.
Please find an abstr= act=20 of a forthcoming draft below. I'm working on the
full draft, but wan= ted=20 to get the abstract out asap so that the work can
be considered as p= art=20 of the new charter.

Thanks,=20 Frank

--

Title

  Diameter Carrier-Grade NAT=20 Control Application

Abstract

  The document will des= cribe=20 the framework, messages and procedures for
  the Diameter=20 Carrier-Grade NAT Control (CGNC) application.=20  The
Diameter
  CGNC application allows gateways (e.g.= =20 Network Access Server (NAS))
to
  interact with Carrier-Grad= e NAT=20 (CGN) devices. The interaction is to
  establish a context to=20 commonly identify and manage endpoints on
  gateway and CGN. It= is=20 to allow the gateway to control and manage the

  behavior o= f a=20 CGN on a per-endpoint basis (e.g. control the total
number
 = of=20 bindings for a particular endpoint, request the allocation of
 = a=20 binding for a particular endpoint). In addition, it allows the CGN
&= nbsp;=20 to provide information relevant to accounting purposes to the=20 gateway

  (e.g. allocated NAT bindings=20 etc.).
_______________________________________________
DiME maili= ng=20 list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--_000_8A8CFE8F89C38B41A749C19328C76D6308AE2281F6exchange02bri_-- --===============0412689557== 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://www.ietf.org/mailman/listinfo/dime --===============0412689557==-- From dime-bounces@ietf.org Sat Oct 18 00:53:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E043A67EC; Sat, 18 Oct 2008 00:53:43 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05A33A67D2 for ; Sat, 18 Oct 2008 00:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fSZR6bJvCDh for ; Sat, 18 Oct 2008 00:53:41 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id D81723A67A4 for ; Sat, 18 Oct 2008 00:53:40 -0700 (PDT) Received: from a88-112-206-80.elisa-laajakaista.fi (a88-112-206-80.elisa-laajakaista.fi [88.112.206.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 23E52216726; Sat, 18 Oct 2008 10:54:42 +0300 (EEST) Message-Id: <37022780-C783-47A3-9B64-ADBCAC3255DD@iki.fi> From: Jouni Korhonen To: "Tschofenig, Hannes (NSN - FI/Espoo)" , dime@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 18 Oct 2008 10:54:42 +0300 References: X-Mailer: Apple Mail (2.929.2) Subject: Re: [Dime] draft-ietf-dime-mip6-integrated X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org A small but not-so-harmless typo in section 4.2.2 was found: The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address and contains IPv6 or IPv6 address of the HA. The Diameter server MAY ^^^^ It should say: The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address and contains IPv6 or IPv4 address of the HA. The Diameter server MAY Anyway, this can be fixed during AUTH48 or by the RFC editor (assuming we do not need to ship out a new revision of I-D anymore). Cheers, Jouni On Oct 15, 2008, at 8:43 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > The document is in IESG Evaluation state and everything is fine from > what I can tell, see > https://datatracker.ietf.org/idtracker/draft-ietf-dime-mip6- > integrated/ > > No action from our side required. > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 20 02:52:08 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348BA3A6AA8; Mon, 20 Oct 2008 02:52:08 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68B13A6AA7 for ; Mon, 20 Oct 2008 02:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.138 X-Spam-Level: *** X-Spam-Status: No, score=3.138 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4A7c4n2nc8L for ; Mon, 20 Oct 2008 02:52:06 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 19CC73A68C3 for ; Mon, 20 Oct 2008 02:52:06 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9100MLI790YP@szxga02-in.huawei.com> for dime@ietf.org; Mon, 20 Oct 2008 17:48:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9100FKM790B1@szxga02-in.huawei.com> for dime@ietf.org; Mon, 20 Oct 2008 17:48:36 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9100GDO78Z90@szxml03-in.huawei.com> for dime@ietf.org; Mon, 20 Oct 2008 17:48:36 +0800 (CST) Date: Mon, 20 Oct 2008 17:48:35 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <018501c93299$05704a40$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [Dime] Comments on dime routing problem statement draft? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0866992518==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0866992518== Content-type: multipart/alternative; boundary="Boundary_(ID_U/lIg4bUQmhW9t0XHZ873g)" This is a multi-part message in MIME format. --Boundary_(ID_U/lIg4bUQmhW9t0XHZ873g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi all, http://groups.google.com/group/diameter-routing/browse_thread/thread/8aa98d4b67800340 B. R. Tina --Boundary_(ID_U/lIg4bUQmhW9t0XHZ873g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi all,
 
B. R.
Tina
--Boundary_(ID_U/lIg4bUQmhW9t0XHZ873g)-- --===============0866992518== 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://www.ietf.org/mailman/listinfo/dime --===============0866992518==-- From dime-bounces@ietf.org Mon Oct 20 12:27:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF7C3A6AE7; Mon, 20 Oct 2008 12:27:07 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644AD3A68D0 for ; Mon, 20 Oct 2008 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZrlWn-9D46R for ; Mon, 20 Oct 2008 12:27:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D3BA63A6AE7 for ; Mon, 20 Oct 2008 12:27:01 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2008 19:27:45 -0000 Received: from chello084114137227.1.15.vie.surfer.at (EHLO 4FIL42860) [84.114.137.227] by mail.gmx.net (mp018) with SMTP; 20 Oct 2008 21:27:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+O8P4nBHiOuG8HMxYiu2/Wz70iLWPyGGyO9zybeO 3abOPA6dlyjbHL From: "Hannes Tschofenig" To: "'Avi Lior'" , "'David Frascone'" , "'Frank Brockners \(fbrockne\)'" References: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com><9cf5ced20810170653j4dd39b3dy851e21eb5da8e27f@mail.gmail.com> <8A8CFE8F89C38B41A749C19328C76D6308AE2281F6@exchange02.bridgewatersys.com> Date: Mon, 20 Oct 2008 22:27:45 +0300 Message-ID: <040001c932e9$efd93c90$0900a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <8A8CFE8F89C38B41A749C19328C76D6308AE2281F6@exchange02.bridgewatersys.com> Thread-Index: AckwX8T3ySFkqEURSt+aixgVjkUpmAAQLsRAAJIyjiA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org A few things: * The term CGN refers to the ongoing IPv4/IPv6 transition work, right? If so, I was not aware that they wanted to use an protocol to request mappings to be created. Instead, the NAT bindings are created based on the flow of data traffic. Am I wrong? * Other SDOs have done work on using Diameter for creating, maintaining and deleting NAT bindings already. We should re-use their work to avoid duplicate coding efforts. The entire idea of using Diameter in that space essentially comes from the MIDCOM days, see http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't really a AAA application as such (since the AAA server is not involved there). * Is the suggestion to only create a Diameter application for allocating NAT bindings or also QoS parameters and firewalling functionality? Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior Sent: 18 October, 2008 00:42 To: David Frascone; Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? David, I agree with Frank that having such an application is required and now is the time to work on it. I have been engaged with several wireless operators that are planning to deploy a CGN in the next year. I have been developing a set of AAA requirements to support such deployements over the past month. It would be good to develop those as the CGN draft is being progressed. Avi ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone Sent: October 17, 2008 9:53 AM To: Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? Do you think we could have a draft before the meeting? On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne) wrote: Hi, while re-chartering DIME, could we consider a new application for Carrier-Grade NAT (CGN) control? CGN has become an important topic within the IPv4-completion/exhaustion debate - also proven by the significant number of drafts on this particular topic. Consequently, per endpoint control of a CGN is an important question to be addressed. Please find an abstract of a forthcoming draft below. I'm working on the full draft, but wanted to get the abstract out asap so that the work can be considered as part of the new charter. Thanks, Frank -- Title Diameter Carrier-Grade NAT Control Application Abstract The document will describe the framework, messages and procedures for the Diameter Carrier-Grade NAT Control (CGNC) application. The Diameter CGNC application allows gateways (e.g. Network Access Server (NAS)) to interact with Carrier-Grade NAT (CGN) devices. The interaction is to establish a context to commonly identify and manage endpoints on gateway and CGN. It is to allow the gateway to control and manage the behavior of a CGN on a per-endpoint basis (e.g. control the total number of bindings for a particular endpoint, request the allocation of a binding for a particular endpoint). In addition, it allows the CGN to provide information relevant to accounting purposes to the gateway (e.g. allocated NAT bindings etc.). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 20 17:50:15 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55163A69EC; Mon, 20 Oct 2008 17:50:15 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03AA23A69EC for ; Mon, 20 Oct 2008 17:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=1.462, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On-vQ98WdtFW for ; Mon, 20 Oct 2008 17:50:14 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 2F01D3A6898 for ; Mon, 20 Oct 2008 17:50:14 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id V6eG1a00k17UAYkA9CrTZS; Tue, 21 Oct 2008 00:51:27 +0000 Received: from gwzPC ([124.120.220.239]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id VCqo1a00N5AWaGU8ZCrBmD; Tue, 21 Oct 2008 00:51:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=AcDVmBIgLP0A:10 a=nCxB-eOLojEA:10 a=CroyVGuUlpGqDkHB8jEA:9 a=rOnJbiRGL36ghXtxP-diWLFVHpIA:4 a=BFDKbZatV3MA:10 a=2uiCRmbCp6AA:10 From: "Glen Zorn" To: "'Hannes Tschofenig'" , "'Avi Lior'" , "'David Frascone'" , "'Frank Brockners \(fbrockne\)'" References: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com><9cf5ced20810170653j4dd39b3dy851e21eb5da8e27f@mail.gmail.com> <8A8CFE8F89C38B41A749C19328C76D6308AE2281F6@exchange02.bridgewatersys.com> <040001c932e9$efd93c90$0900a8c0@nsnintra.net> In-Reply-To: <040001c932e9$efd93c90$0900a8c0@nsnintra.net> Date: Tue, 21 Oct 2008 07:50:30 +0700 Message-ID: <000101c93317$0ffd6960$2ff83c20$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckwX8T3ySFkqEURSt+aixgVjkUpmAAQLsRAAJIyjiAACv/q0A== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes Tschofenig [Hannes.Tschofenig@gmx.net] writes: ... > Please note that this isn't really a > AAA application as such (since the AAA server is not involved there). One thing I've been complaining about for a long time is the tendency for people to talk about Diameter "servers" that don't actually exist (Diameter being a P2P protocol). I suppose that many thought me just a bit too picky (after all, they're only words & _we_ know what we _mean_ ;-) but this is a perfect example of sloppy language usage leading to sloppy thinking. IIRC, one of the reasons that Diameter was _not_ defined as a client-server protocol was to support exactly this kind of application... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 20 23:18:21 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63903A692B; Mon, 20 Oct 2008 23:18:21 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CB23A692B for ; Mon, 20 Oct 2008 23:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQi008gPcc2M for ; Mon, 20 Oct 2008 23:18:19 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id A70353A67E5 for ; Mon, 20 Oct 2008 23:18:19 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id ED974B8B2C for ; Tue, 21 Oct 2008 08:19:31 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id DEC58AF03A for ; Tue, 21 Oct 2008 08:19:31 +0200 (CEST) Message-ID: <48FD7473.8050205@restena.lu> Date: Tue, 21 Oct 2008 08:19:31 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080922) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.95.7 X-Virus-Scanned: ClamAV Subject: [Dime] Diameter Peer Discovery - A/AAAA vs. SRV X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, 3588 and -bis define a peer lookup mechanism that first looks for NAPTR records for a realm, and if that fails use an underscore construct in conjunction with A and AAAA records: "If no NAPTR records are found, the requester queries for those address records for the destination address, '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address records include A RR's, AAAA RR's or other similar records, chosen according to the requester's network protocol capabilities." When looking into the same issue for RadSec, I received some (IMHO justifie= d) off-list opposition. It appears to be seen as a very bad practice by a l= ot of DNS people to use underscore constructs in A or AAAA records. The question had been raised why the lookup mechanism does not use SRV reco= rds as fallback after NAPTR - these were specifically designed for service = discovery with underscores. The SRV RR RFC is also older than 3588, so the = option to use it existed back then. I wonder if there is a reason and/or actual deployed experience with this b= it of the Diameter spec, and whether it is maybe about time to introduce SR= V record lookups in 3588bis (and RadSec). Greetings, Stefan Winter -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 21 04:49:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51453A6B58; Tue, 21 Oct 2008 04:49:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE4328C0EF for ; Tue, 21 Oct 2008 04:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5Ew+jXShhp5 for ; Tue, 21 Oct 2008 04:49:25 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id BA8043A6B52 for ; Tue, 21 Oct 2008 04:49:24 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Tue, 21 Oct 2008 07:50:28 -0400 From: Avi Lior To: Hannes Tschofenig , 'David Frascone' , "'Frank Brockners (fbrockne)'" Date: Tue, 21 Oct 2008 07:50:28 -0400 Thread-Topic: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? Thread-Index: AckwX8T3ySFkqEURSt+aixgVjkUpmAAQLsRAAJIyjiAAIf+9Gw== Message-ID: <8A8CFE8F89C38B41A749C19328C76D6308AE276689@exchange02.bridgewatersys.com> References: <693E0961C9EFD946AC7067D67746362506986352@xmb-ams-336.emea.cisco.com><9cf5ced20810170653j4dd39b3dy851e21eb5da8e27f@mail.gmail.com> <8A8CFE8F89C38B41A749C19328C76D6308AE2281F6@exchange02.bridgewatersys.com>, <040001c932e9$efd93c90$0900a8c0@nsnintra.net> In-Reply-To: <040001c932e9$efd93c90$0900a8c0@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, I belive that the AAA work associated with CGN needs to cover the following: -Whether the session will be NATed or not. In all cases that I am aware of the NAT is located at the Gateway such as an HA/LMA for mobility services and for simple IP the first attachement point, the NAS, (ASN-GW in WiMAX, PDSN in 3GPP2) -The configuration of the CGN for the subscriber. This inlcudes the number of ports, the binding times etc. Different users will have different requirements, the AAA can deliver those to the CGN when the user is authenticated. -Deliver policy to the CGN on what pinholes can be opened and what must not be opened by the mobile. -Authorize any entity that is requesting to open or close a pinhole etc.. In the past, as you are aware, 3GPP2 had a project call NFCC - Network Firewal Configuration and Control - That project used AAA for the coniguration and authorization part. It is very similar to be sure. That application used the AAA to set policy at the firewall and also authorize creation deletion of firewall pinholes. THe question is whether we can mix Firewall and CGN? Regarding QoS, it is possible that QoS will also be configured at the same time and some of the pinholes may be associated with QoS configurations. But other then that, I think they are seperate beasts. I think the approach for CGN should be like the QoS. We develope a set of attributes, and also an CGN applications that uses those attributes. The set of attributes can be used by folks that want a combined QoS / CGN and Newtwork Access Authentication (NASREQ) application. ________________________________________ From: Hannes Tschofenig [Hannes.Tschofenig@gmx.net] Sent: Monday, October 20, 2008 3:27 PM To: Avi Lior; 'David Frascone'; 'Frank Brockners (fbrockne)' Cc: dime@ietf.org Subject: RE: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? A few things: * The term CGN refers to the ongoing IPv4/IPv6 transition work, right? If so, I was not aware that they wanted to use an protocol to request mappings to be created. Instead, the NAT bindings are created based on the flow of data traffic. Am I wrong? * Other SDOs have done work on using Diameter for creating, maintaining and deleting NAT bindings already. We should re-use their work to avoid duplicate coding efforts. The entire idea of using Diameter in that space essentially comes from the MIDCOM days, see http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't really a AAA application as such (since the AAA server is not involved there). * Is the suggestion to only create a Diameter application for allocating NAT bindings or also QoS parameters and firewalling functionality? Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior Sent: 18 October, 2008 00:42 To: David Frascone; Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? David, I agree with Frank that having such an application is required and now is the time to work on it. I have been engaged with several wireless operators that are planning to deploy a CGN in the next year. I have been developing a set of AAA requirements to support such deployements over the past month. It would be good to develop those as the CGN draft is being progressed. Avi ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone Sent: October 17, 2008 9:53 AM To: Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NAT Control Application? Do you think we could have a draft before the meeting? On Fri, Oct 17, 2008 at 4:19 AM, Frank Brockners (fbrockne) wrote: Hi, while re-chartering DIME, could we consider a new application for Carrier-Grade NAT (CGN) control? CGN has become an important topic within the IPv4-completion/exhaustion debate - also proven by the significant number of drafts on this particular topic. Consequently, per endpoint control of a CGN is an important question to be addressed. Please find an abstract of a forthcoming draft below. I'm working on the full draft, but wanted to get the abstract out asap so that the work can be considered as part of the new charter. Thanks, Frank -- Title Diameter Carrier-Grade NAT Control Application Abstract The document will describe the framework, messages and procedures for the Diameter Carrier-Grade NAT Control (CGNC) application. The Diameter CGNC application allows gateways (e.g. Network Access Server (NAS)) to interact with Carrier-Grade NAT (CGN) devices. The interaction is to establish a context to commonly identify and manage endpoints on gateway and CGN. It is to allow the gateway to control and manage the behavior of a CGN on a per-endpoint basis (e.g. control the total number of bindings for a particular endpoint, request the allocation of a binding for a particular endpoint). In addition, it allows the CGN to provide information relevant to accounting purposes to the gateway (e.g. allocated NAT bindings etc.). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 21 05:11:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FD63A6B30; Tue, 21 Oct 2008 05:11:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510543A6B0F for ; Tue, 21 Oct 2008 05:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFIVHv6q5QvU for ; Tue, 21 Oct 2008 05:11:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9CEC33A6B5F for ; Tue, 21 Oct 2008 05:11:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,456,1220227200"; d="scan'208";a="23257008" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2008 12:12:36 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9LCCarK032242; Tue, 21 Oct 2008 14:12:36 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9LCCauN019431; Tue, 21 Oct 2008 12:12:36 GMT Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 14:12:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 14:12:35 +0200 Message-ID: <693E0961C9EFD946AC7067D677463625069E1E3F@xmb-ams-336.emea.cisco.com> In-Reply-To: <040001c932e9$efd93c90$0900a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? Thread-Index: AckwX8T3ySFkqEURSt+aixgVjkUpmAAQLsRAAJIyjiAAIFD+8A== From: "Frank Brockners (fbrockne)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 21 Oct 2008 12:12:36.0529 (UTC) FILETIME=[4E0B4A10:01C93376] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6197; t=1224591156; x=1225455156; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fbrockne@cisco.com; z=From:=20=22Frank=20Brockners=20(fbrockne)=22=20 |Subject:=20RE=3A=20[Dime]=20Dime=20rechartering=3A=20Inclu de=20Carrier-Grade=20NATControl=09Application? |Sender:=20; bh=b72e0sj/EDpxoysQqlchTq03JNu8D/CViSnDW9DVeA0=; b=qL26w6p1lbPcM3GuuJcFWYFvC8OrRE7lhorJItf05v2rVV53TYb6KgBYmO vNTFBV9F9ezFQe/QiogOiPy6QUPVAR0Egb4Tj4EKco5vdC3SgfEHd0bZ2Te3 pR8ZAyROg+; Authentication-Results: ams-dkim-2; header.From=fbrockne@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, October 20, 2008 9:28 PM > > A few things: > > * The term CGN refers to the ongoing IPv4/IPv6 transition > work, right? If so, I was not aware that they wanted to use > an protocol to request mappings to be created. Instead, the > NAT bindings are created based on the flow of data traffic. > Am I wrong? ...FB: "CGN" refers to a Carrier Grade NAT device as used in e.g. draft-nishitani-cgn or draft-arkko-townsley-coexistence. And I agree that for the general case the bindings would be defined by the CGN (taken from external and internal address pools), i.e. typically the binding would not be defined by an external entity through an interface. Having said that, for certain use cases it might be beneficial to also cover the case where you want a specific binding to be established. As stated in the abstract, the idea of the CGN Control Application it largely to perform per endpoint control of the CGN, i.e. - specify the maximum number of bindings per end-point (and possibly associated hold-timers) - provide resports/stats on the currently allocated bindings - control parameters of binding(s) (i.e. request a specific external ip-address, ip-address/port, ip-address/port-ranges). As a corner case this could allow defintion of a complete binding. > > * Other SDOs have done work on using Diameter for creating, > maintaining and deleting NAT bindings already. We should > re-use their work to avoid duplicate coding efforts. The > entire idea of using Diameter in that space essentially comes > from the MIDCOM days, see > http://www.ietf.org/rfc/rfc4097.txt. Please note that this > isn't really a AAA application as such (since the AAA server > is not involved there). ...FB: We should of course see whether we can leverage work which was done in other SDOs. As noted above, creating, maintaining and deleting NAT bindings would not be the primary objective of the CGN Control Application. This is what typical control interfaces to "border gateway functions" (like a session border controller) would do. Here we'd focus more on the per-endpoint control aspects. > > * Is the suggestion to only create a Diameter application for > allocating NAT bindings or also QoS parameters and > firewalling functionality? ...FB: Along the lines of what I stated above, the CGN Control Application would really focus on controlling bindings on a per-endpoint basis (i.e. provide a set of focused functions for NAT control). QoS and also specific firewall rules are somewhat orthogonal (or complimentary). Regards, Frank > > Ciao > Hannes > > > ________________________________ > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior > Sent: 18 October, 2008 00:42 > To: David Frascone; Frank Brockners (fbrockne) > Cc: dime@ietf.org > Subject: Re: [Dime] Dime rechartering: Include > Carrier-Grade NATControl Application? > > > David, > > I agree with Frank that having such an application is > required and now is the time to work on it. > > I have been engaged with several wireless operators > that are planning to deploy a CGN in the next year. I have > been developing a set of AAA requirements to support such > deployements over the past month. > > It would be good to develop those as the CGN draft is > being progressed. > > Avi > > > ________________________________ > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone > Sent: October 17, 2008 9:53 AM > To: Frank Brockners (fbrockne) > Cc: dime@ietf.org > Subject: Re: [Dime] Dime rechartering: Include > Carrier-Grade NAT Control Application? > > > Do you think we could have a draft before the meeting? > > > On Fri, Oct 17, 2008 at 4:19 AM, Frank > Brockners (fbrockne) wrote: > > > Hi, > > while re-chartering DIME, could we > consider a new application for > Carrier-Grade NAT (CGN) control? CGN > has become an important topic > within the IPv4-completion/exhaustion > debate - also proven by the > significant number of drafts on this > particular topic. Consequently, per > endpoint control of a CGN is an > important question to be addressed. > Please find an abstract of a > forthcoming draft below. I'm working on the > full draft, but wanted to get the > abstract out asap so that the work can > be considered as part of the new charter. > > Thanks, Frank > > -- > > Title > > Diameter Carrier-Grade NAT Control Application > > Abstract > > The document will describe the > framework, messages and procedures for > the Diameter Carrier-Grade NAT > Control (CGNC) application. The > Diameter > CGNC application allows gateways > (e.g. Network Access Server (NAS)) > to > interact with Carrier-Grade NAT (CGN) > devices. The interaction is to > establish a context to commonly > identify and manage endpoints on > gateway and CGN. It is to allow the > gateway to control and manage the > > behavior of a CGN on a per-endpoint > basis (e.g. > control the total > number > of bindings for a particular > endpoint, request the allocation of > a binding for a particular endpoint). > In addition, it allows the CGN > to provide information relevant to > accounting purposes to the gateway > > (e.g. allocated NAT bindings etc.). > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 21 11:14:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE143A6B83; Tue, 21 Oct 2008 11:14:01 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6773A6B83 for ; Tue, 21 Oct 2008 11:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFyFfTuz+0Kx for ; Tue, 21 Oct 2008 11:13:59 -0700 (PDT) Received: from smtp122.rog.mail.re2.yahoo.com (smtp122.rog.mail.re2.yahoo.com [206.190.53.27]) by core3.amsl.com (Postfix) with SMTP id A43DF3A69C4 for ; Tue, 21 Oct 2008 11:13:58 -0700 (PDT) Received: (qmail 30913 invoked from network); 21 Oct 2008 18:15:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fBjNOB4Y+ZRg+Rdzfm6CbkAb76fzAjnBAHzNQBwDXMqBP/erZTTZU2LRWafYv9CEW+bRB0vJ3gKh0sCUdX6NNPZjV/UprDfaYB7lgqVbhZNahMt6hZYZ/eibrl1duaDHqdYkhkQ+aU+cFxlSBDOfJege5NWJqfEtPMYUdSUqg3o= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp122.rog.mail.re2.yahoo.com with SMTP; 21 Oct 2008 18:15:06 -0000 X-YMail-OSG: nHREMNMVM1nH2ke_CisPWiMsNgm4RlYc0FrXbut9XLV9XIk1XHdfKEnMiol10_tAsQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48FE1C2C.4090202@rogers.com> Date: Tue, 21 Oct 2008 14:15:08 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Frank Brockners (fbrockne)" References: <693E0961C9EFD946AC7067D677463625069E1E3F@xmb-ams-336.emea.cisco.com> In-Reply-To: <693E0961C9EFD946AC7067D677463625069E1E3F@xmb-ams-336.emea.cisco.com> Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I would want to understand the difference between this and the Gq' application that now exists. Just from your words: is it that you are talking about imposing static conditions per end point rather than per-session control? Frank Brockners (fbrockne) wrote: > Hannes, > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, October 20, 2008 9:28 PM >> >> A few things: >> >> * The term CGN refers to the ongoing IPv4/IPv6 transition >> work, right? If so, I was not aware that they wanted to use >> an protocol to request mappings to be created. Instead, the >> NAT bindings are created based on the flow of data traffic. >> Am I wrong? > > ...FB: "CGN" refers to a Carrier Grade NAT device as used in > e.g. draft-nishitani-cgn or draft-arkko-townsley-coexistence. > And I agree that for the general case the bindings would be > defined by the CGN (taken from external and internal > address pools), i.e. typically the binding would not be defined > by an external entity through an interface. Having > said that, for certain use cases it might be beneficial to > also cover the case where you want a specific binding to be > established. As stated in the abstract, the idea of > the CGN Control Application it largely to perform per endpoint > control of the CGN, i.e. > - specify the maximum number of bindings per end-point > (and possibly associated hold-timers) > - provide resports/stats on the currently allocated > bindings > - control parameters of binding(s) (i.e. request a > specific external ip-address, ip-address/port, > ip-address/port-ranges). As a corner case this could > allow defintion of a complete binding. > >> >> * Other SDOs have done work on using Diameter for creating, >> maintaining and deleting NAT bindings already. We should >> re-use their work to avoid duplicate coding efforts. The >> entire idea of using Diameter in that space essentially comes >> from the MIDCOM days, see >> http://www.ietf.org/rfc/rfc4097.txt. Please note that this >> isn't really a AAA application as such (since the AAA server >> is not involved there). > > ...FB: We should of course see whether we can leverage work > which was done in other SDOs. As noted above, creating, > maintaining and deleting NAT bindings would not be the > primary objective of the CGN Control Application. This > is what typical control interfaces to "border gateway > functions" (like a session border controller) would do. > Here we'd focus more on the per-endpoint control aspects. > > >> >> * Is the suggestion to only create a Diameter application for >> allocating NAT bindings or also QoS parameters and >> firewalling functionality? > > ...FB: Along the lines of what I stated above, the > CGN Control Application would really focus on controlling > bindings on a per-endpoint basis (i.e. provide a set of > focused functions for NAT control). QoS and also specific > firewall rules are somewhat orthogonal (or complimentary). > > > Regards, Frank > >> >> Ciao >> Hannes >> >> >> ________________________________ >> >> From: dime-bounces@ietf.org >> [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior >> Sent: 18 October, 2008 00:42 >> To: David Frascone; Frank Brockners (fbrockne) >> Cc: dime@ietf.org >> Subject: Re: [Dime] Dime rechartering: Include >> Carrier-Grade NATControl Application? >> >> >> David, >> >> I agree with Frank that having such an application is >> required and now is the time to work on it. >> >> I have been engaged with several wireless operators >> that are planning to deploy a CGN in the next year. I have >> been developing a set of AAA requirements to support such >> deployements over the past month. >> >> It would be good to develop those as the CGN draft is >> being progressed. >> >> Avi >> >> >> ________________________________ >> >> From: dime-bounces@ietf.org >> [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone >> Sent: October 17, 2008 9:53 AM >> To: Frank Brockners (fbrockne) >> Cc: dime@ietf.org >> Subject: Re: [Dime] Dime rechartering: Include >> Carrier-Grade NAT Control Application? >> >> >> Do you think we could have a draft before the meeting? >> >> >> On Fri, Oct 17, 2008 at 4:19 AM, Frank >> Brockners (fbrockne) wrote: >> >> >> Hi, >> >> while re-chartering DIME, could we >> consider a new application for >> Carrier-Grade NAT (CGN) control? CGN >> has become an important topic >> within the IPv4-completion/exhaustion >> debate - also proven by the >> significant number of drafts on this >> particular topic. Consequently, per >> endpoint control of a CGN is an >> important question to be addressed. >> Please find an abstract of a >> forthcoming draft below. I'm working on the >> full draft, but wanted to get the >> abstract out asap so that the work can >> be considered as part of the new charter. >> >> Thanks, Frank >> >> -- >> >> Title >> >> Diameter Carrier-Grade NAT Control Application >> >> Abstract >> >> The document will describe the >> framework, messages and procedures for >> the Diameter Carrier-Grade NAT >> Control (CGNC) application. The >> Diameter >> CGNC application allows gateways >> (e.g. Network Access Server (NAS)) >> to >> interact with Carrier-Grade NAT (CGN) >> devices. The interaction is to >> establish a context to commonly >> identify and manage endpoints on >> gateway and CGN. It is to allow the >> gateway to control and manage the >> >> behavior of a CGN on a per-endpoint >> basis (e.g. >> control the total >> number >> of bindings for a particular >> endpoint, request the allocation of >> a binding for a particular endpoint). >> In addition, it allows the CGN >> to provide information relevant to >> accounting purposes to the gateway >> >> (e.g. allocated NAT bindings etc.). >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> >> >> >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 22 00:22:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B77C3A69BA; Wed, 22 Oct 2008 00:22:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950AA3A69BA for ; Wed, 22 Oct 2008 00:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.494 X-Spam-Level: * X-Spam-Status: No, score=1.494 tagged_above=-999 required=5 tests=[AWL=1.988, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i21CasgQ9jcJ for ; Wed, 22 Oct 2008 00:22:34 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C199D3A6904 for ; Wed, 22 Oct 2008 00:22:34 -0700 (PDT) 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 <0K94005FKPVB87@szxga01-in.huawei.com> for dime@ietf.org; Wed, 22 Oct 2008 15:23:35 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9400NQCPVB0H@szxga01-in.huawei.com> for dime@ietf.org; Wed, 22 Oct 2008 15:23:35 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K94005DJPVAO6@szxml03-in.huawei.com> for dime@ietf.org; Wed, 22 Oct 2008 15:23:35 +0800 (CST) Date: Wed, 22 Oct 2008 15:23:34 +0800 From: Tina TSOU To: dime@ietf.org, "Tschofenig, Hannes (NSN - FI/Espoo)" Message-id: <095b01c93417$1812b0a0$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Dime] draft-ietf-dime-diameter-qos X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1077106479==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1077106479== Content-type: multipart/alternative; boundary="Boundary_(ID_YNEazWkUlO0MTehX9Sq1ow)" This is a multi-part message in MIME format. --Boundary_(ID_YNEazWkUlO0MTehX9Sq1ow) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Hannes, Will there be a next version (i.e. -07) of draft-ietf-dime-diameter-qos-06? When? B. R. Tina ----- Original Message ----- From: Tschofenig, Hannes (NSN - FI/Espoo) To: dime@ietf.org Sent: Thursday, October 16, 2008 1:41 AM Subject: [Dime] draft-ietf-dime-diameter-qos This document passed the WGLC. Note that the document has a normative dependency on draft-ietf-dime-qos-attributes ACTION ITEM: * Dave to write the PROTO writeup and submit it to the IESG. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_YNEazWkUlO0MTehX9Sq1ow) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Hannes,
Will there be a next version (i.e. -07) of draft-ietf-dime-diameter-qos-06? When?
 
B. R.
Tina
----- Original Message -----
Sent: Thursday, October 16, 2008 1:41 AM
Subject: [Dime] draft-ietf-dime-diameter-qos

This document passed the WGLC.

Note that the document has a normative dependency on
draft-ietf-dime-qos-attributes

ACTION ITEM:
* Dave to write the PROTO writeup and submit it to the IESG.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--Boundary_(ID_YNEazWkUlO0MTehX9Sq1ow)-- --===============1077106479== 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://www.ietf.org/mailman/listinfo/dime --===============1077106479==-- From dime-bounces@ietf.org Wed Oct 22 01:33:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8928B3A67F5; Wed, 22 Oct 2008 01:33:28 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCDD3A67F5 for ; Wed, 22 Oct 2008 01:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxBpKurztWKY for ; Wed, 22 Oct 2008 01:33:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 06EE63A67F2 for ; Wed, 22 Oct 2008 01:33:25 -0700 (PDT) Received: (qmail invoked by alias); 22 Oct 2008 08:34:38 -0000 Received: from unknown (EHLO 4FIL42860) [193.170.196.25] by mail.gmx.net (mp036) with SMTP; 22 Oct 2008 10:34:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18CFiJLlYgCklXC/jHsePBO2jNexuf1dE3yGtBk8p l8ivU0eeeJpdg6 From: "Hannes Tschofenig" To: "'Tina TSOU'" , , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <095b01c93417$1812b0a0$7427460a@china.huawei.com> Date: Wed, 22 Oct 2008 11:34:41 +0300 Message-ID: <026601c93421$0796ac90$0200000a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <095b01c93417$1812b0a0$7427460a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Ack0FyNs+QOoIjHcSAud5vCgDML5wAACdEiA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57,0.59 Subject: Re: [Dime] draft-ietf-dime-diameter-qos X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0649500562==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0649500562== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0267_01C9343A.2CE3E490" This is a multi-part message in MIME format. ------=_NextPart_000_0267_01C9343A.2CE3E490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit there will be no new version. We are waiting for Dave to write and submit the PROTO writeup _____ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tina TSOU Sent: 22 October, 2008 10:24 To: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo) Subject: Re: [Dime] draft-ietf-dime-diameter-qos Hi Hannes, Will there be a next version (i.e. -07) of draft-ietf-dime-diameter-qos-06? When? B. R. Tina ----- Original Message ----- From: Tschofenig, Hannes (NSN - FI/Espoo) To: dime@ietf.org Sent: Thursday, October 16, 2008 1:41 AM Subject: [Dime] draft-ietf-dime-diameter-qos This document passed the WGLC. Note that the document has a normative dependency on draft-ietf-dime-qos-attributes ACTION ITEM: * Dave to write the PROTO writeup and submit it to the IESG. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ------=_NextPart_000_0267_01C9343A.2CE3E490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
there will be no new version. We are waiting = for Dave to=20 write and submit the PROTO writeup

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Tina = TSOU
Sent:=20 22 October, 2008 10:24
To: dime@ietf.org; Tschofenig, Hannes = (NSN -=20 FI/Espoo)
Subject: Re: [Dime]=20 draft-ietf-dime-diameter-qos

Hi Hannes,
Will there be a next version (i.e. = -07) of=20 draft-ietf-dime-diameter-qos-06? When?
 
B. R.
Tina
----- Original Message -----
From:=20 Tschofenig, Hannes (NSN -=20 FI/Espoo)
Sent: Thursday, October 16, = 2008 1:41=20 AM
Subject: [Dime]=20 draft-ietf-dime-diameter-qos

This document passed the WGLC.

Note that the = document=20 has a normative dependency=20 on
draft-ietf-dime-qos-attributes

ACTION ITEM:
* Dave = to write=20 the PROTO writeup and submit it to the IESG.=20

_______________________________________________
DiME = mailing=20 list
DiME@ietf.org
https://www.ietf.org/= mailman/listinfo/dime ------=_NextPart_000_0267_01C9343A.2CE3E490-- --===============0649500562== 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://www.ietf.org/mailman/listinfo/dime --===============0649500562==-- From dime-bounces@ietf.org Wed Oct 22 04:48:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D787A3A6A4D; Wed, 22 Oct 2008 04:48:02 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF3F3A69E9 for ; Wed, 22 Oct 2008 04:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.366 X-Spam-Level: * X-Spam-Status: No, score=1.366 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+-FSFvXCKDU for ; Wed, 22 Oct 2008 04:48:00 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C223E3A67F3 for ; Wed, 22 Oct 2008 04:47:59 -0700 (PDT) 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 <0K9500AIR25KQN@szxga03-in.huawei.com> for dime@ietf.org; Wed, 22 Oct 2008 19:48:56 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9500EZT25KX0@szxga03-in.huawei.com> for dime@ietf.org; Wed, 22 Oct 2008 19:48:56 +0800 (CST) Received: from [192.168.0.100] (56.73.61.58.broad.sz.gd.dynamic.163data.com.cn [58.61.73.56]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9500A6J25IHY@szxml02-in.huawei.com>; Wed, 22 Oct 2008 19:48:56 +0800 (CST) Date: Wed, 22 Oct 2008 19:48:54 +0800 From: Tina TSOU In-reply-to: <0074F19FF6F8534E8F74C56BB84397BB0367A4AE@esealmw118.eemea.ericsson.se> To: Raymond Forbes Message-id: <59C262AF-826F-4741-BDD7-28532CB48E17@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) References: <0074F19FF6F8534E8F74C56BB84397BB0367A4AE@esealmw118.eemea.ericsson.se> Cc: dime@ietf.org, Sonia Compans Subject: Re: [Dime] Approval of TISPAN-03117 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0293103249==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0293103249== Content-type: multipart/alternative; boundary="Boundary_(ID_nqwpGm0Ry6/ac8M8NyNNTQ)" --Boundary_(ID_nqwpGm0Ry6/ac8M8NyNNTQ) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi Ray, Thanks for the information. I cc to dime@ietf.org. Hi Hannes, Dave, Sonia and DIME colleagues, How can we get an AVP Code on Location Data? Can it be allocated by ETSI itself? Thank you all. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) On Oct 22, 2008, at 6:38 PM, Raymond Forbes wrote: > 4.1.1 DTS/TISPAN-03117-NGN-R2 a2 interface Stage 3 > NASS > > 17bTD293r2 was accepted as the latest draft of part 1 at version > 0.5.3 available in the meeting. The WG approval of this deliverable > is now aimed for approval at TISPAN#17bis May 2008 as part of NGN > Release 2. This DTS was WG approved Frozen subject to the AVP Code > on Location Data being assigned by the IETF. > > The DTS is now under WG internal change control at v0.5.3 as > 17bTD293r2. > > Next CR number is CR001 > > TS 183 059 > current > WG approval > Work Item reference > Rapporteur Current status > version target date > (183 059-1 R2) DTS/TISPAN-03117-1-NGN-R2 Tsou > (zou) Frozen in WG > 0.5.3 30/05/2008 > a2 intf - DIAMETER based > No contributions were available at this meeting > > 17bTD293r2 was accepted as the latest draft of part 1 at version > 0.5.3 available in the meeting. The WG approval of this deliverable > is now aimed for approval at TISPAN#17bis May 2008 as part of NGN > Release 2. This DTS was WG approved Frozen subject to the IETF > assigning the AVP Code on Location-Data being assigned by the IETF. > WG approval postponed until TISPAN#19 November 2008. > > > > This is pending the IETF to allocate an AVP code this is a boring > reason not to WG approve the TS. If the AVP code is available could > you write a Cr to add it to the Table. > > I think this can be discussed and approved as maintenance; even with > your absence. > > Regards, > > Ray Forbes > TISPAN WG3 Chairman > > Telephone: +442476435151 > Fax: +442476436136 (832)36136 > Switchboard: +441483303666 x 35151 > Mobile: +447718511361 > Email: Raymond.Forbes@Ericsson.com --Boundary_(ID_nqwpGm0Ry6/ac8M8NyNNTQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi Ray,
Thanks for the information.
I cc to dime@ietf.org.

Hi Hannes, Dave, Sonia and DIME colleagues,
How can we get an AVP Code on Location Data? Can it be allocated by ETSI itself?

Thank you all.


B. R.
Tina

Messengers:

MSN: tinatsou6@hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: tina@jabber.org    Google talk: tinatsou6@gmail.com

+86-755-28971872 (Office)    +86-13922884380(Mobile)




4.1.1                 a2 interface Stage 3 NASS

17bTD293r2 was accepted as the latest draft of part 1 at version 0.5.3 available in the meeting. The WG approval of this deliverable is now aimed for approval at TISPAN#17bis May 2008 as part of NGN Release 2. This DTS was WG approved Frozen subject to the AVP Code on Location Data being assigned by the IETF.

The DTS is now under WG internal change control at v0.5.3 as 17bTD293r2.

Next CR number is CR001
 
     183 059
                                                                      &nb sp;                                                                                       current            WG approval
< div styl n-right: 0cm; margin-bottom: 0pt; margin-left: 0cm; ">Work Item reference                                                Rapporteur                  Current status   &n sp;     version             target date

(183 059-1 R2) DTS/TISPAN-03117-1-NGN-R2              Tsou (zou)              Frozen in WG                    0.5.3                 30/05/2008

a2 intf - DIAMETER based                                                                               

17bTD293r2 was accepted as the latest draft of part 1 at version 0.5.3 available in the meeting. The WG approval of this deliverable is now aimed for approval at TISPAN#17bis May 2008 as part of NGN Release 2. This DTS was WG approved Frozen subject to the IETF assigning the AVP Code on Location-Data being assigned by the IETF. WG approval postponed until TISPAN#19 November 2008.

 

This is pending the IETF to allocate an AVP code this is a boring reason not to WG approve the TS. If the AVP code is available could you write a Cr to add it to the Table.

I think this can be discussed and approved as maintenance; even with your absence. 

< span lan ILY: Arial; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-GB">

Regards,

Ray Forbes
TISPAN WG3 Chairman
 
Telephone: +442476435151
Fax: +442476436136 (832)36136Switchboard: +441483303666 x 35151 
Mobile: +447718511361
Email: Raymond.Forbes@Ericsson.com

--Boundary_(ID_nqwpGm0Ry6/ac8M8NyNNTQ)-- --===============0293103249== 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://www.ietf.org/mailman/listinfo/dime --===============0293103249==-- From dime-bounces@ietf.org Wed Oct 22 06:25:35 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38133A6B75; Wed, 22 Oct 2008 06:25:35 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A813A6A9B for ; Wed, 22 Oct 2008 06:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v183gQdMfeCp for ; Wed, 22 Oct 2008 06:25:29 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 33AE33A69E9 for ; Wed, 22 Oct 2008 06:25:29 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id VnyF1a0020lTkoCAApSHtr; Wed, 22 Oct 2008 13:26:17 +0000 Received: from gwzPC ([124.120.222.75]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id VpRi1a00K1eCvHG8QpS2M2; Wed, 22 Oct 2008 13:26:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=-O5YPv7yAAAA:8 a=mUDSwthrMhfsngC08moA:9 a=jiqX8II7O8DZiy20xj0A:7 a=dNbxGcE4LtLJR8Qpy8zS0vQl0C4A:4 a=lZB815dzVvQA:10 a=EfJqPEOeqlMA:10 a=DOYNd9a5gwgA:10 a=MSl-tDqOz04A:10 a=f7GxY0FH8QIA:10 a=50e4U0PicR4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Qa6Twilgn06dhkJRvm8A:9 a=wrHfJbtw___fpVBWtQ0A:7 a=O0eX-TrW-fjDrHpFUhZBBhD7O8MA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Tina TSOU'" , "'Raymond Forbes'" References: <0074F19FF6F8534E8F74C56BB84397BB0367A4AE@esealmw118.eemea.ericsson.se> <59C262AF-826F-4741-BDD7-28532CB48E17@huawei.com> In-Reply-To: <59C262AF-826F-4741-BDD7-28532CB48E17@huawei.com> Date: Wed, 22 Oct 2008 20:25:14 +0700 Message-ID: <005101c93449$a80ef7e0$f82ce7a0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack0PDnZITQDK7xdTA+gUG55vKCh6AADQb4Q Content-Language: en-us Cc: 'Sonia Compans' , dime@ietf.org Subject: Re: [Dime] Approval of TISPAN-03117 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1637172709==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1637172709== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C93484.546DCFE0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0052_01C93484.546DCFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ray, Thanks for the information. I cc to dime@ietf.org. Hi Hannes, Dave, Sonia and DIME colleagues, How can we get an AVP Code on Location Data? Can it be allocated by ETSI itself? According to http://portal.etsi.org/ptcc/diameternumbers.asp, ETSI's enterprise number is 13019. and ETSI PTCC manages the allocation of ETSI AVP codes, AVP specific values and Experimental Result Codes. Thank you all. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) 4.1.1 a2 interface Stage 3 NASS 17bTD293r2 was accepted as the latest draft of part 1 at version 0.5.3 available in the meeting. The WG approval of this deliverable is now aimed for approval at TISPAN#17bis May 2008 as part of NGN Release 2. This DTS was WG approved Frozen subject to the AVP Code on Location Data being assigned by the IETF. The DTS is now under WG internal change control at v0.5.3 as 17bTD293r2. Next CR number is CR001 183 059  current WG approval < div styl n-right: 0cm; margin-bottom: 0pt; margin-left: 0cm; ">Work Item reference Rapporteur Current status &nsp;version target date (183 059-1 R2) DTS/TISPAN-03117-1-NGN-R2 Tsou (zou) Frozen in WG 0.5.3 30/05/2008 a2 intf - DIAMETER based 17bTD293r2 was accepted as the latest draft of part 1 at version 0.5.3 available in the meeting. The WG approval of this deliverable is now aimed for approval at TISPAN#17bis May 2008 as part of NGN Release 2. This DTS was WG approved Frozen subject to the IETF assigning the AVP Code on Location-Data being assigned by the IETF. WG approval postponed until TISPAN#19 November 2008. This is pending the IETF to allocate an AVP code this is a boring reason not to WG approve the TS. If the AVP code is available could you write a Cr to add it to the Table. I think this can be discussed and approved as maintenance; even with your absence. < span lan ILY: Arial; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-GB"> Regards, Ray Forbes TISPAN WG3 Chairman Telephone: +442476435151 Fax: +442476436136 (832)36136Switchboard: +441483303666 x 35151 Mobile: +447718511361 Email: Raymond.Forbes @Ericsson.com ------=_NextPart_000_0052_01C93484.546DCFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ray,

Thanks for the information.

I cc to dime@ietf.org.

 

Hi Hannes, Dave, Sonia and DIME = colleagues,

How can we get an AVP Code on = Location Data? Can it be allocated by ETSI itself?

 

According to http://portal.etsi.org/ptcc/diameternumbers.asp, ETSI’s enterprise number is 13019. and ETSI PTCC = manages the allocation of ETSI AVP codes, AVP specific values and Experimental = Result Codes. 

 

Thank you = all.

 

 

B. R.

Tina

 

Messengers:

MSN: tinatsou6@hotmail.com &nbs= p; Yahoo: tina_tsou    Skype: tinaTSOU    = Jabber: tina@jabber.org    = Google talk: tinatsou6@gmail.com

+86-755-28971872 (Office)    +86-13922884380(Mobile)

 

 



4.1.1        = ;         a2 interface Stage 3 = NASS

17bTD293r2 was accepted as the latest = draft of part 1 at version 0.5.3 available in the meeting. The WG = approval of this deliverable is now aimed for approval at TISPAN#17bis May 2008 as = part of NGN Release 2. This DTS was WG approved Frozen subject to the AVP Code = on Location Data being assigned by the IETF.

The DTS is now under WG internal = change control at v0.5.3 as 17bTD293r2.

Next CR number is CR001

 

       &nbs= p;                &nbs= p;       183 = 059

     &nbs= p;          =        &nbs= p;        = &nbsp;current      = WG = approval

< div styl n-right: 0cm; margin-bottom: 0pt; margin-left: 0cm; ">Work Item reference       &nbs= p;   Rapporteur       &nbs= p;     Current = status       &nbs= p;        = &nsp;version       &nbs= p; target = date

(183 059-1 R2) = DTS/TISPAN-03117-1-NGN-R2          Tsou = (zou)     Frozen in = WG          =     0.5.3          =    30/05/2008

a2 intf - DIAMETER based    

17bTD293r2 was accepted as the latest draft of part 1 at version 0.5.3 available in = the meeting. The WG approval of this deliverable is now aimed for approval at TISPAN#17bis = May 2008 as part of NGN Release 2. This DTS was WG approved Frozen subject to the = IETF assigning the AVP Code on Location-Data being assigned by the IETF. = WG approval = postponed until TISPAN#19 November 2008.

 

This is pending the IETF to allocate an AVP code this is a boring reason not to WG approve the TS. = If the AVP code is available could you write a Cr to add it to the Table. =

I think this can be discussed and = approved as maintenance; even with your absence. 

< span lan ILY: Arial; mso-bidi-font-family: = 'Times New Roman'; mso-ansi-language: EN-GB"> =

Regards,

Ray Forbes
= TISPAN WG3 Chairman

 

Telephone: +442476435151

Fax: +442476436136 (832)36136Switchboard: +441483303666 x 35151 
Mobile: +447718511361<= br> Email: = Raymond.Forbes@= Ericsson.com<= o:p>

 

------=_NextPart_000_0052_01C93484.546DCFE0-- --===============1637172709== 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://www.ietf.org/mailman/listinfo/dime --===============1637172709==-- From dime-bounces@ietf.org Wed Oct 22 06:47:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A93B28C11A; Wed, 22 Oct 2008 06:47:11 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D216228C11A for ; Wed, 22 Oct 2008 06:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=1.361, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N84+aE9SgU3C for ; Wed, 22 Oct 2008 06:47:03 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 7382E3A679C for ; Wed, 22 Oct 2008 06:47:03 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Vpjf1a0080ldTLk57po8S7; Wed, 22 Oct 2008 13:48:08 +0000 Received: from gwzPC ([124.120.222.75]) by OMTA04.westchester.pa.mail.comcast.net with comcast id Vpmr1a00K1eCvHG3Qpndah; Wed, 22 Oct 2008 13:48:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=-O5YPv7yAAAA:8 a=mUDSwthrMhfsngC08moA:9 a=L2frXHJoKB-w0PuSVaEA:7 a=AeslyGm2_jTN3HtfOiGqQ3QbkHcA:4 a=lZB815dzVvQA:10 a=EfJqPEOeqlMA:10 a=DOYNd9a5gwgA:10 a=MSl-tDqOz04A:10 a=f7GxY0FH8QIA:10 a=5WZzfXpOq_gA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=XE6alZbHhxoowMgvY5EA:9 a=gvmTr0QFds8w0LsS63cA:7 a=NzHU8Oeu-vB1fo5vhHqnZTW4fRQA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Glen Zorn'" , "'Tina TSOU'" , "'Raymond Forbes'" References: <0074F19FF6F8534E8F74C56BB84397BB0367A4AE@esealmw118.eemea.ericsson.se> <59C262AF-826F-4741-BDD7-28532CB48E17@huawei.com> <005101c93449$a80ef7e0$f82ce7a0$@net> In-Reply-To: <005101c93449$a80ef7e0$f82ce7a0$@net> Date: Wed, 22 Oct 2008 20:46:23 +0700 Message-ID: <005c01c9344c$abe9e0c0$03bda240$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack0PDnZITQDK7xdTA+gUG55vKCh6AADQb4QAAC1ybA= Content-Language: en-us Cc: dime@ietf.org, 'Sonia Compans' Subject: Re: [Dime] Approval of TISPAN-03117 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============2007137548==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============2007137548== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C93487.5848B8C0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_005D_01C93487.5848B8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In any case, the IETF doesn't assign AVP Codes, IANA does; in this case, IANA would request expert review of the spec in question. From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, October 22, 2008 8:25 PM To: 'Tina TSOU'; 'Raymond Forbes' Cc: 'Sonia Compans'; dime@ietf.org Subject: Re: [Dime] Approval of TISPAN-03117 Hi Ray, Thanks for the information. I cc to dime@ietf.org. Hi Hannes, Dave, Sonia and DIME colleagues, How can we get an AVP Code on Location Data? Can it be allocated by ETSI itself? According to http://portal.etsi.org/ptcc/diameternumbers.asp, ETSI's enterprise number is 13019. and ETSI PTCC manages the allocation of ETSI AVP codes, AVP specific values and Experimental Result Codes. Thank you all. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) 4.1.1 a2 interface Stage 3 NASS 17bTD293r2 was accepted as the latest draft of part 1 at version 0.5.3 available in the meeting. The WG approval of this deliverable is now aimed for approval at TISPAN#17bis May 2008 as part of NGN Release 2. This DTS was WG approved Frozen subject to the AVP Code on Location Data being assigned by the IETF. The DTS is now under WG internal change control at v0.5.3 as 17bTD293r2. Next CR number is CR001 183 059  current WG approval < div styl n-right: 0cm; margin-bottom: 0pt; margin-left: 0cm; ">Work Item reference Rapporteur Current status &nsp;version target date (183 059-1 R2) DTS/TISPAN-03117-1-NGN-R2 Tsou (zou) Frozen in WG 0.5.3 30/05/2008 a2 intf - DIAMETER based 17bTD293r2 was accepted as the latest draft of part 1 at version 0.5.3 available in the meeting. The WG approval of this deliverable is now aimed for approval at TISPAN#17bis May 2008 as part of NGN Release 2. This DTS was WG approved Frozen subject to the IETF assigning the AVP Code on Location-Data being assigned by the IETF. WG approval postponed until TISPAN#19 November 2008. This is pending the IETF to allocate an AVP code this is a boring reason not to WG approve the TS. If the AVP code is available could you write a Cr to add it to the Table. I think this can be discussed and approved as maintenance; even with your absence. < span lan ILY: Arial; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-GB"> Regards, Ray Forbes TISPAN WG3 Chairman Telephone: +442476435151 Fax: +442476436136 (832)36136Switchboard: +441483303666 x 35151 Mobile: +447718511361 Email: Raymond.Forbes @Ericsson.com ------=_NextPart_000_005D_01C93487.5848B8C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In any case, the IETF doesn't assign AVP Codes, IANA = does; in this case, IANA would request expert review of the spec in = question.

 

From:= = dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn
Sent: Wednesday, October 22, 2008 8:25 PM
To: 'Tina TSOU'; 'Raymond Forbes'
Cc: 'Sonia Compans'; dime@ietf.org
Subject: Re: [Dime] Approval of = TISPAN-03117

 

Hi Ray,

Thanks for the information.

I cc to dime@ietf.org.

 

Hi Hannes, Dave, Sonia and DIME = colleagues,

How can we get an AVP Code on = Location Data? Can it be allocated by ETSI itself?

 

According to http://portal.etsi.org/ptcc/diameternumbers.asp, ETSI’s enterprise number is 13019. and ETSI PTCC manages the = allocation of ETSI AVP codes, AVP specific values and Experimental Result = Codes. 

 

Thank you = all.

 

 

B. R.

Tina

 

Messengers:

MSN: tinatsou6@hotmail.com &nbs= p; Yahoo: tina_tsou    Skype: tinaTSOU    = Jabber: tina@jabber.org    = Google talk: tinatsou6@gmail.com

+86-755-28971872 (Office)    +86-13922884380(Mobile)

 

 

 

4.1.1        = ;         a2 interface Stage 3 = NASS

17bTD293r2 was accepted as the latest = draft of part 1 at version 0.5.3 available in the meeting. The WG = approval of this deliverable is now aimed for approval at TISPAN#17bis May 2008 as = part of NGN Release 2. This DTS was WG approved Frozen subject to the AVP Code = on Location Data being assigned by the IETF.

The DTS is now under WG internal = change control at v0.5.3 as 17bTD293r2.

Next CR number is CR001

 

       &nbs= p;                &nbs= p;       183 059

     &nbs= p;                 &nbs= p;        &nbsp;current      = WG = approval

< div styl n-right: 0cm; margin-bottom: 0pt; margin-left: 0cm; ">Work Item reference       &nbs= p;   Rapporteur       &nbs= p;     Current status       &nbs= p;        &nsp;version       &nbs= p; target date

(183 059-1 R2) = DTS/TISPAN-03117-1-NGN-R2          Tsou (zou)     Frozen in WG          =     0.5.3          =    30/05/2008

a2 intf - DIAMETER based    

17bTD293r2 was accepted as the latest draft of part 1 at version 0.5.3 available in = the meeting. The WG approval of this deliverable is now aimed for approval at TISPAN#17bis = May 2008 as part of NGN Release 2. This DTS was WG approved Frozen subject to the = IETF assigning the AVP Code on Location-Data being assigned by the IETF. = WG approval = postponed until TISPAN#19 November 2008.

 

This is pending the IETF to allocate an AVP code this is a boring reason not to WG approve the TS. = If the AVP code is available could you write a Cr to add it to the Table. =

I think this can be discussed and = approved as maintenance; even with your absence. 

< span lan ILY: Arial; mso-bidi-font-family: = 'Times New Roman'; mso-ansi-language: EN-GB"> =

Regards,

Ray Forbes
= TISPAN WG3 Chairman

 

Telephone: +442476435151

Fax: +442476436136 (832)36136Switchboard: +441483303666 x 35151 
Mobile: +447718511361<= br> Email: = Raymond.Forbes@= Ericsson.com<= o:p>

 

------=_NextPart_000_005D_01C93487.5848B8C0-- --===============2007137548== 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://www.ietf.org/mailman/listinfo/dime --===============2007137548==-- From dime-bounces@ietf.org Wed Oct 22 09:24:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD6F3A69D0; Wed, 22 Oct 2008 09:24:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DF63A69D0 for ; Wed, 22 Oct 2008 09:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbMe83yjwqxC for ; Wed, 22 Oct 2008 09:24:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A5DBE3A6778 for ; Wed, 22 Oct 2008 09:24:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,465,1220227200"; d="scan'208";a="23426741" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2008 16:25:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9MGPBhj004407; Wed, 22 Oct 2008 18:25:11 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9MGPBQO016911; Wed, 22 Oct 2008 16:25:11 GMT Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 18:25:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 18:25:09 +0200 Message-ID: <693E0961C9EFD946AC7067D677463625069E284F@xmb-ams-336.emea.cisco.com> In-Reply-To: <48FE1C2C.4090202@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? Thread-Index: AckzqPoUzN+PoIctQquEGe2uGkgn0QAsoxaQ From: "Frank Brockners (fbrockne)" To: "Tom Taylor" X-OriginalArrivalTime: 22 Oct 2008 16:25:10.0941 (UTC) FILETIME=[C130CCD0:01C93462] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9174; t=1224692711; x=1225556711; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fbrockne@cisco.com; z=From:=20=22Frank=20Brockners=20(fbrockne)=22=20 |Subject:=20RE=3A=20[Dime]=20Dime=20rechartering=3A=20Inclu de=20Carrier-Grade=20NATControl=20Application? |Sender:=20; bh=at5o+qu0CdisYJy1Pu6SbhgsqqZsbseJpj536Mt39m4=; b=uuLlE1CzkqrZrR54LFfRT5STE5tuuYQhP1D9PZJmES5akhp8uSvfNHbwpM PWJdeNZ8/i4HUNDclmPl2l7V7rkBP+J2PJhSRG5QMfM1yonOlZQyREEjSPRZ WGPHUdMzY4; Authentication-Results: ams-dkim-2; header.From=fbrockne@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tom, TISPAN Gq' includes NAT-binding control capabilities for sessions at the service-layer (e.g. SIP sessions) - representing services provided by the SP: Among other things, Gq' allows P-CSCF to request allocation and/or modification of a binding in BGF for a specific media flow. This makes BGF an anchor point and natural NAT gateway for service-layer controlled traffic. Hence, Gq' is focused on controlling individual bindings for service-level traffic flows. Different from that, the CGN Control application is intended as a control interface to the CGN, i.e. a NAT device placed between subscriber-CPE and the public Internet by a carrier - typically traversed by all the traffic (deployment dependent minus the traffic handled by BGFs). As noted earlier, bindings within the CGN would typically not be created through an external interface (with per-binding signaling procedures) but be created on the fly within the CGN. A CGN and a BGF would typically operate in parallel - where CGN would provide NAT-services for all of the traffic that is not "steered" towards a BGF by a P-CSCF (or similar). Still, it is desirable to control and monitor some of the behavior of the CGN on a per end-point (or subscriber) basis, i.e. restrict the number of bindings per subscriber, pre-set certain ip-address/port-ranges, report allocated bindings etc. Given that those rules are typically per subscriber (and won't change frequently), one could call this "static conditions per end-point" as you note, though we of course would want to include the possibility of dynamic changes. Regards, Frank > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: Tuesday, October 21, 2008 8:15 PM > To: Frank Brockners (fbrockne) > Cc: Hannes Tschofenig; dime@ietf.org > Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade > NATControl Application? > > I would want to understand the difference between this and > the Gq' application that now exists. Just from your words: is > it that you are talking about imposing static conditions per > end point rather than per-session control? > > Frank Brockners (fbrockne) wrote: > > Hannes, > > > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Monday, October 20, 2008 9:28 PM > >> > >> A few things: > >> > >> * The term CGN refers to the ongoing IPv4/IPv6 transition work, > >> right? If so, I was not aware that they wanted to use an > protocol to > >> request mappings to be created. Instead, the NAT bindings > are created > >> based on the flow of data traffic. > >> Am I wrong? > > > > ...FB: "CGN" refers to a Carrier Grade NAT device as used in > > e.g. draft-nishitani-cgn or draft-arkko-townsley-coexistence. > > And I agree that for the general case the bindings would be > > defined by the CGN (taken from external and internal > > address pools), i.e. typically the binding would not be defined > > by an external entity through an interface. Having > > said that, for certain use cases it might be beneficial to > > also cover the case where you want a specific binding to be > > established. As stated in the abstract, the idea of > > the CGN Control Application it largely to perform per endpoint > > control of the CGN, i.e. > > - specify the maximum number of bindings per end-point > > (and possibly associated hold-timers) > > - provide resports/stats on the currently allocated > > bindings > > - control parameters of binding(s) (i.e. request a > > specific external ip-address, ip-address/port, > > ip-address/port-ranges). As a corner case this could > > allow defintion of a complete binding. > > > >> > >> * Other SDOs have done work on using Diameter for creating, > >> maintaining and deleting NAT bindings already. We should > re-use their > >> work to avoid duplicate coding efforts. The entire idea of using > >> Diameter in that space essentially comes from the MIDCOM days, see > >> http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't > >> really a AAA application as such (since the AAA server is not > >> involved there). > > > > ...FB: We should of course see whether we can leverage work > > which was done in other SDOs. As noted above, creating, > > maintaining and deleting NAT bindings would not be the > > primary objective of the CGN Control Application. This > > is what typical control interfaces to "border gateway > > functions" (like a session border controller) would do. > > Here we'd focus more on the per-endpoint control aspects. > > > > > >> > >> * Is the suggestion to only create a Diameter application for > >> allocating NAT bindings or also QoS parameters and firewalling > >> functionality? > > > > ...FB: Along the lines of what I stated above, the > > CGN Control Application would really focus on controlling > > bindings on a per-endpoint basis (i.e. provide a set of > > focused functions for NAT control). QoS and also specific > > firewall rules are somewhat orthogonal (or complimentary). > > > > > > Regards, Frank > > > >> > >> Ciao > >> Hannes > >> > >> > >> ________________________________ > >> > >> From: dime-bounces@ietf.org > >> [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior > >> Sent: 18 October, 2008 00:42 > >> To: David Frascone; Frank Brockners (fbrockne) > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade > >> NATControl Application? > >> > >> > >> David, > >> > >> I agree with Frank that having such an application is > required and > >> now is the time to work on it. > >> > >> I have been engaged with several wireless operators that are > >> planning to deploy a CGN in the next year. I have been > developing a > >> set of AAA requirements to support such deployements over the past > >> month. > >> > >> It would be good to develop those as the CGN draft is being > >> progressed. > >> > >> Avi > >> > >> > >> ________________________________ > >> > >> From: dime-bounces@ietf.org > >> [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone > >> Sent: October 17, 2008 9:53 AM > >> To: Frank Brockners (fbrockne) > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] Dime rechartering: Include > Carrier-Grade NAT > >> Control Application? > >> > >> > >> Do you think we could have a draft before the meeting? > >> > >> > >> On Fri, Oct 17, 2008 at 4:19 AM, Frank > Brockners (fbrockne) > >> wrote: > >> > >> > >> Hi, > >> > >> while re-chartering DIME, could we > consider a new application for > >> Carrier-Grade NAT (CGN) control? CGN > has become an important topic > >> within the IPv4-completion/exhaustion > debate - also proven by the > >> significant number of drafts on this > particular topic. > >> Consequently, per > >> endpoint control of a CGN is an > >> important question to be addressed. > >> Please find an abstract of a > >> forthcoming draft below. I'm working on the > >> full draft, but wanted to get the > abstract out asap so that the > >> work can > >> be considered as part of the new charter. > >> > >> Thanks, Frank > >> > >> -- > >> > >> Title > >> > >> Diameter Carrier-Grade NAT Control Application > >> > >> Abstract > >> > >> The document will describe the > >> framework, messages and procedures for > >> the Diameter Carrier-Grade NAT > >> Control (CGNC) application. The > >> Diameter > >> CGNC application allows gateways > (e.g. Network Access Server > >> (NAS)) > >> to > >> interact with Carrier-Grade NAT (CGN) > devices. The interaction > >> is to > >> establish a context to commonly > identify and manage endpoints on > >> gateway and CGN. It is to allow the > gateway to control and > >> manage the > >> > >> behavior of a CGN on a per-endpoint > basis (e.g. > >> control the total > >> number > >> of bindings for a particular > >> endpoint, request the allocation of > >> a binding for a particular endpoint). > >> In addition, it allows the CGN > >> to provide information relevant to > accounting purposes to the > >> gateway > >> > >> (e.g. allocated NAT bindings etc.). > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >> > >> > >> > >> > >> > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 22 10:16:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631B328C169; Wed, 22 Oct 2008 10:16:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0F13A6778 for ; Wed, 22 Oct 2008 10:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sdnxjwU5l3Q for ; Wed, 22 Oct 2008 10:16:09 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id E3A643A6999 for ; Wed, 22 Oct 2008 10:16:08 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3291284wfd.31 for ; Wed, 22 Oct 2008 10:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=2GX0mzJ1oQH+kS4cW/dcV2G1T77FEdb0ArD1eePyaZ8=; b=onJCbgMp/GnOeFAl4tM3oDcSNRvce2XXb4bv1ZEtLn0E35z49T62u/LnqBVKlo6mEf d7v/rAhkH8IAC42h513TQ8BbrIbrrwoQYIjO5heNrhIxWLqmTC/d02BaM+lz+gtkcekT Fn6mv3DALsvOkvT/c3LyMq4JVaM8ravrQFa80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=yDWBAeTKAPMiPsp2bNRk+hgq13tYRImNRLpwk+1JgAEQk3obZ8SM6m14YdZ94p5+3f BsoxOaDrifNZ0FCXUuCHAYAWq6GjaSf/wx3Yyzh5Opd4+SnG9QxG0PfkanZFEdv8dmg/ o6Yr+eBKZdwhmJAF2OvJdxw1NVDkLq3IZmRi0= Received: by 10.141.142.15 with SMTP id u15mr6625914rvn.171.1224695813633; Wed, 22 Oct 2008 10:16:53 -0700 (PDT) Received: by 10.141.142.9 with HTTP; Wed, 22 Oct 2008 10:16:53 -0700 (PDT) Message-ID: <9cf5ced20810221016t5954b5adp322c23fa340105d9@mail.gmail.com> Date: Wed, 22 Oct 2008 13:16:53 -0400 From: "David Frascone" To: "Frank Brockners (fbrockne)" In-Reply-To: <693E0961C9EFD946AC7067D677463625069E284F@xmb-ams-336.emea.cisco.com> MIME-Version: 1.0 References: <48FE1C2C.4090202@rogers.com> <693E0961C9EFD946AC7067D677463625069E284F@xmb-ams-336.emea.cisco.com> X-Google-Sender-Auth: 27c59863547be468 Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControl Application? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1867538700==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1867538700== Content-Type: multipart/alternative; boundary="----=_Part_20723_12494935.1224695813627" ------=_Part_20723_12494935.1224695813627 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline It is sounding like this may be somewhere we would want to focus some attention as a WG, no? -Dave On Wed, Oct 22, 2008 at 12:25 PM, Frank Brockners (fbrockne) < fbrockne@cisco.com> wrote: > Tom, > > TISPAN Gq' includes NAT-binding control capabilities for sessions at the > service-layer (e.g. SIP sessions) - representing services provided by > the SP: Among other things, Gq' allows P-CSCF to request allocation > and/or modification of a binding in BGF for a specific media flow. This > makes BGF an anchor point and natural NAT gateway for service-layer > controlled traffic. Hence, Gq' is focused on controlling individual > bindings for service-level traffic flows. > > Different from that, the CGN Control application is intended as a > control interface to the CGN, i.e. a NAT device placed between > subscriber-CPE and the public Internet by a carrier - typically > traversed by all the traffic (deployment dependent minus the traffic > handled by BGFs). As noted earlier, bindings within the CGN would > typically not be created through an external interface (with per-binding > signaling procedures) but be created on the fly within the CGN. A CGN > and a BGF would typically operate in parallel - where CGN would provide > NAT-services for all of the traffic that is not "steered" towards a BGF > by a P-CSCF (or similar). Still, it is desirable to control and monitor > some of the behavior of the CGN on a per end-point (or subscriber) > basis, i.e. restrict the number of bindings per subscriber, pre-set > certain ip-address/port-ranges, report allocated bindings etc. Given > that those rules are typically per subscriber (and won't change > frequently), one could call this "static conditions per end-point" as > you note, though we of course would want to include the possibility of > dynamic changes. > > Regards, Frank > > > -----Original Message----- > > From: Tom Taylor [mailto:tom.taylor@rogers.com] > > Sent: Tuesday, October 21, 2008 8:15 PM > > To: Frank Brockners (fbrockne) > > Cc: Hannes Tschofenig; dime@ietf.org > > Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade > > NATControl Application? > > > > I would want to understand the difference between this and > > the Gq' application that now exists. Just from your words: is > > it that you are talking about imposing static conditions per > > end point rather than per-session control? > > > > Frank Brockners (fbrockne) wrote: > > > Hannes, > > > > > > > > > > > >> -----Original Message----- > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> Sent: Monday, October 20, 2008 9:28 PM > > >> > > >> A few things: > > >> > > >> * The term CGN refers to the ongoing IPv4/IPv6 transition work, > > >> right? If so, I was not aware that they wanted to use an > > protocol to > > >> request mappings to be created. Instead, the NAT bindings > > are created > > >> based on the flow of data traffic. > > >> Am I wrong? > > > > > > ...FB: "CGN" refers to a Carrier Grade NAT device as used in > > > e.g. draft-nishitani-cgn or draft-arkko-townsley-coexistence. > > > And I agree that for the general case the bindings would be > > > defined by the CGN (taken from external and internal > > > address pools), i.e. typically the binding would not be defined > > > by an external entity through an interface. Having > > > said that, for certain use cases it might be beneficial to > > > also cover the case where you want a specific binding to be > > > established. As stated in the abstract, the idea of > > > the CGN Control Application it largely to perform per endpoint > > > control of the CGN, i.e. > > > - specify the maximum number of bindings per end-point > > > (and possibly associated hold-timers) > > > - provide resports/stats on the currently allocated > > > bindings > > > - control parameters of binding(s) (i.e. request a > > > specific external ip-address, ip-address/port, > > > ip-address/port-ranges). As a corner case this could > > > allow defintion of a complete binding. > > > > > >> > > >> * Other SDOs have done work on using Diameter for creating, > > >> maintaining and deleting NAT bindings already. We should > > re-use their > > >> work to avoid duplicate coding efforts. The entire idea of using > > >> Diameter in that space essentially comes from the MIDCOM days, see > > >> http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't > > >> really a AAA application as such (since the AAA server is not > > >> involved there). > > > > > > ...FB: We should of course see whether we can leverage work > > > which was done in other SDOs. As noted above, creating, > > > maintaining and deleting NAT bindings would not be the > > > primary objective of the CGN Control Application. This > > > is what typical control interfaces to "border gateway > > > functions" (like a session border controller) would do. > > > Here we'd focus more on the per-endpoint control aspects. > > > > > > > > >> > > >> * Is the suggestion to only create a Diameter application for > > >> allocating NAT bindings or also QoS parameters and firewalling > > >> functionality? > > > > > > ...FB: Along the lines of what I stated above, the > > > CGN Control Application would really focus on controlling > > > bindings on a per-endpoint basis (i.e. provide a set of > > > focused functions for NAT control). QoS and also specific > > > firewall rules are somewhat orthogonal (or complimentary). > > > > > > > > > Regards, Frank > > > > > >> > > >> Ciao > > >> Hannes > > >> > > >> > > >> ________________________________ > > >> > > >> From: dime-bounces@ietf.org > > >> [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior > > >> Sent: 18 October, 2008 00:42 > > >> To: David Frascone; Frank Brockners (fbrockne) > > >> Cc: dime@ietf.org > > >> Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade > > >> NATControl Application? > > >> > > >> > > >> David, > > >> > > >> I agree with Frank that having such an application is > > required and > > >> now is the time to work on it. > > >> > > >> I have been engaged with several wireless operators that are > > >> planning to deploy a CGN in the next year. I have been > > developing a > > >> set of AAA requirements to support such deployements over the past > > >> month. > > >> > > >> It would be good to develop those as the CGN draft is being > > >> progressed. > > >> > > >> Avi > > >> > > >> > > >> ________________________________ > > >> > > >> From: dime-bounces@ietf.org > > >> [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone > > >> Sent: October 17, 2008 9:53 AM > > >> To: Frank Brockners (fbrockne) > > >> Cc: dime@ietf.org > > >> Subject: Re: [Dime] Dime rechartering: Include > > Carrier-Grade NAT > > >> Control Application? > > >> > > >> > > >> Do you think we could have a draft before the meeting? > > >> > > >> > > >> On Fri, Oct 17, 2008 at 4:19 AM, Frank > > Brockners (fbrockne) > > >> wrote: > > >> > > >> > > >> Hi, > > >> > > >> while re-chartering DIME, could we > > consider a new application for > > >> Carrier-Grade NAT (CGN) control? CGN > > has become an important topic > > >> within the IPv4-completion/exhaustion > > debate - also proven by the > > >> significant number of drafts on this > > particular topic. > > >> Consequently, per > > >> endpoint control of a CGN is an > > >> important question to be addressed. > > >> Please find an abstract of a > > >> forthcoming draft below. I'm working on the > > >> full draft, but wanted to get the > > abstract out asap so that the > > >> work can > > >> be considered as part of the new charter. > > >> > > >> Thanks, Frank > > >> > > >> -- > > >> > > >> Title > > >> > > >> Diameter Carrier-Grade NAT Control Application > > >> > > >> Abstract > > >> > > >> The document will describe the > > >> framework, messages and procedures for > > >> the Diameter Carrier-Grade NAT > > >> Control (CGNC) application. The > > >> Diameter > > >> CGNC application allows gateways > > (e.g. Network Access Server > > >> (NAS)) > > >> to > > >> interact with Carrier-Grade NAT (CGN) > > devices. The interaction > > >> is to > > >> establish a context to commonly > > identify and manage endpoints on > > >> gateway and CGN. It is to allow the > > gateway to control and > > >> manage the > > >> > > >> behavior of a CGN on a per-endpoint > > basis (e.g. > > >> control the total > > >> number > > >> of bindings for a particular > > >> endpoint, request the allocation of > > >> a binding for a particular endpoint). > > >> In addition, it allows the CGN > > >> to provide information relevant to > > accounting purposes to the > > >> gateway > > >> > > >> (e.g. allocated NAT bindings etc.). > > >> _______________________________________________ > > >> DiME mailing list > > >> DiME@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dime > > >> > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ------=_Part_20723_12494935.1224695813627 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline It is sounding like this may be somewhere we would want to focus some attention as a WG, no?

-Dave

On Wed, Oct 22, 2008 at 12:25 PM, Frank Brockners (fbrockne) <fbrockne@cisco.com> wrote:
Tom,

TISPAN Gq' includes NAT-binding control capabilities for sessions at the
service-layer (e.g. SIP sessions) - representing services provided by
the SP: Among other things, Gq' allows P-CSCF to request allocation
and/or modification of a binding in BGF for a specific media flow. This
makes BGF an anchor point and natural NAT gateway for service-layer
controlled traffic. Hence, Gq' is focused on controlling individual
bindings for service-level traffic flows.

Different from that, the CGN Control application is intended as a
control interface to the CGN, i.e. a NAT device placed between
subscriber-CPE and the public Internet by a carrier - typically
traversed by all the traffic (deployment dependent minus the traffic
handled by BGFs). As noted earlier, bindings within the CGN would
typically not be created through an external interface (with per-binding
signaling procedures) but be created on the fly within the CGN. A CGN
and a BGF would typically operate in parallel - where CGN would provide
NAT-services for all of the traffic that is not "steered" towards a BGF
by a P-CSCF (or similar). Still, it is desirable to control and monitor
some of the behavior of the CGN on a per end-point (or subscriber)
basis, i.e. restrict the number of bindings per subscriber, pre-set
certain ip-address/port-ranges, report allocated bindings etc. Given
that those rules are typically per subscriber (and won't change
frequently), one could call this "static conditions per end-point" as
you note, though we of course would want to include the possibility of
dynamic changes.

Regards, Frank

> -----Original Message-----
> From: Tom Taylor [mailto:tom.taylor@rogers.com]
> Sent: Tuesday, October 21, 2008 8:15 PM
> To: Frank Brockners (fbrockne)
> Cc: Hannes Tschofenig; dime@ietf.org
> Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade
> NATControl Application?
>
> I would want to understand the difference between this and
> the Gq' application that now exists. Just from your words: is
> it that you are talking about imposing static conditions per
> end point rather than per-session control?
>
> Frank Brockners (fbrockne) wrote:
> > Hannes,
> >
> >
> >
> >> -----Original Message-----
> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> >> Sent: Monday, October 20, 2008 9:28 PM
> >>
> >> A few things:
> >>
> >> * The term CGN refers to the ongoing IPv4/IPv6 transition work,
> >> right? If so, I was not aware that they wanted to use an
> protocol to
> >> request mappings to be created. Instead, the NAT bindings
> are created
> >> based on the flow of data traffic.
> >> Am I wrong?
> >
> > ...FB: "CGN" refers to a Carrier Grade NAT device as used in
> >   e.g. draft-nishitani-cgn or draft-arkko-townsley-coexistence.
> >   And I agree that for the general case the bindings would be
> >   defined by the CGN (taken from external and internal
> >   address pools), i.e. typically the binding would not be defined
> >   by an external entity through an interface. Having
> >   said that, for certain use cases it might be beneficial to
> >   also cover the case where you want a specific binding to be
> >   established. As stated in the abstract, the idea of
> >   the CGN Control Application it largely to perform per endpoint
> >   control of the CGN, i.e.
> >    - specify the maximum number of bindings per end-point
> >      (and possibly associated hold-timers)
> >    - provide resports/stats on the currently allocated
> >      bindings
> >    - control parameters of binding(s) (i.e. request a
> >      specific external ip-address, ip-address/port,
> >      ip-address/port-ranges). As a corner case this could
> >      allow defintion of a complete binding.
> >
> >>
> >> * Other SDOs have done work on using Diameter for creating,
> >> maintaining and deleting NAT bindings already. We should
> re-use their
> >> work to avoid duplicate coding efforts. The entire idea of using
> >> Diameter in that space essentially comes from the MIDCOM days, see
> >> http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't
> >> really a AAA application as such (since the AAA server is not
> >> involved there).
> >
> > ...FB: We should of course see whether we can leverage work
> >   which was done in other SDOs. As noted above, creating,
> >   maintaining and deleting NAT bindings would not be the
> >   primary objective of the CGN Control Application. This
> >   is what typical control interfaces to "border gateway
> >   functions" (like a session border controller) would do.
> >   Here we'd focus more on the per-endpoint control aspects.
> >
> >
> >>
> >> * Is the suggestion to only create a Diameter application for
> >> allocating NAT bindings or also QoS parameters and firewalling
> >> functionality?
> >
> > ...FB: Along the lines of what I stated above, the
> >   CGN Control Application would really focus on controlling
> >   bindings on a per-endpoint basis (i.e. provide a set of
> >   focused functions for NAT control). QoS and also specific
> >   firewall rules are somewhat orthogonal (or complimentary).
> >
> >
> > Regards, Frank
> >
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >> ________________________________
> >>
> >>    From: dime-bounces@ietf.org
> >> [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior
> >>    Sent: 18 October, 2008 00:42
> >>    To: David Frascone; Frank Brockners (fbrockne)
> >>    Cc: dime@ietf.org
> >>    Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade
> >> NATControl Application?
> >>
> >>
> >>    David,
> >>
> >>    I agree with Frank that having such an application is
> required and
> >> now is the time to work on it.
> >>
> >>    I have been engaged with several wireless operators that are
> >> planning to deploy a CGN in the next year.  I have been
> developing a
> >> set of AAA requirements to support such deployements over the past
> >> month.
> >>
> >>    It would be good to develop those as the CGN draft is being
> >> progressed.
> >>
> >>    Avi
> >>
> >>
> >> ________________________________
> >>
> >>            From: dime-bounces@ietf.org
> >> [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone
> >>            Sent: October 17, 2008 9:53 AM
> >>            To: Frank Brockners (fbrockne)
> >>            Cc: dime@ietf.org
> >>            Subject: Re: [Dime] Dime rechartering: Include
> Carrier-Grade NAT
> >> Control Application?
> >>
> >>
> >>            Do you think we could have a draft before the meeting?
> >>
> >>
> >>            On Fri, Oct 17, 2008 at 4:19 AM, Frank
> Brockners (fbrockne)
> >> <fbrockne@cisco.com> wrote:
> >>
> >>
> >>                    Hi,
> >>
> >>                    while re-chartering DIME, could we
> consider a new application for
> >>                    Carrier-Grade NAT (CGN) control? CGN
> has become an important topic
> >>                    within the IPv4-completion/exhaustion
> debate - also proven by the
> >>                    significant number of drafts on this
> particular topic.
> >> Consequently, per
> >>                    endpoint control of a CGN is an
> >> important question to be addressed.
> >>                    Please find an abstract of a
> >> forthcoming draft below. I'm working on the
> >>                    full draft, but wanted to get the
> abstract out asap so that the
> >> work can
> >>                    be considered as part of the new charter.
> >>
> >>                    Thanks, Frank
> >>
> >>                    --
> >>
> >>                    Title
> >>
> >>                      Diameter Carrier-Grade NAT Control Application
> >>
> >>                    Abstract
> >>
> >>                      The document will describe the
> >> framework, messages and procedures for
> >>                      the Diameter Carrier-Grade NAT
> >> Control (CGNC) application.  The
> >>                    Diameter
> >>                      CGNC application allows gateways
> (e.g. Network Access Server
> >> (NAS))
> >>                    to
> >>                      interact with Carrier-Grade NAT (CGN)
> devices. The interaction
> >> is to
> >>                      establish a context to commonly
> identify and manage endpoints on
> >>                      gateway and CGN. It is to allow the
> gateway to control and
> >> manage the
> >>
> >>                      behavior of a CGN on a per-endpoint
> basis (e.g.
> >> control the total
> >>                    number
> >>                      of bindings for a particular
> >> endpoint, request the allocation of
> >>                      a binding for a particular endpoint).
> >> In addition, it allows the CGN
> >>                      to provide information relevant to
> accounting purposes to the
> >> gateway
> >>
> >>                      (e.g. allocated NAT bindings etc.).
> >>                    _______________________________________________
> >>                    DiME mailing list
> >>                    DiME@ietf.org
> >>                    https://www.ietf.org/mailman/listinfo/dime
> >>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime
> >
> >
>
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

------=_Part_20723_12494935.1224695813627-- --===============1867538700== 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://www.ietf.org/mailman/listinfo/dime --===============1867538700==-- From dime-bounces@ietf.org Wed Oct 22 10:23:09 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B2A3A6A80; Wed, 22 Oct 2008 10:23:09 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724A13A6A7A for ; Wed, 22 Oct 2008 10:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqpI2luCnvx9 for ; Wed, 22 Oct 2008 10:23:07 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 90DCC3A69D0 for ; Wed, 22 Oct 2008 10:23:06 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 19:23:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 19:23:47 +0200 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE07BCDEEE@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Dime rechartering: Include Carrier-Grade NATControlApplication? thread-index: AckzqPoUzN+PoIctQquEGe2uGkgn0QAsoxaQAAKhXnA= References: <693E0961C9EFD946AC7067D677463625069E284F@xmb-ams-336.emea.cisco.com> From: To: , X-OriginalArrivalTime: 22 Oct 2008 17:23:57.0988 (UTC) FILETIME=[F7797640:01C9346A] Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControlApplication? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tom, Frank, Since were are talking about a control interface sitting just above the NAT= device I would compare it to ITU-T Rw (Recommendation Q.3303.3)rather than= ETSI Gq'. Having said that, I'm still not sure to understand the differenc= es between this GCN control application and existing applications such as G= q' and Q.3303.3 (16777256). Both Gq' and Rw enable controlling more things = than just NAT bindings. Is it a correct understanding that the Diameter app= lication defined in Q.3303.3 is roughly equivalent to the GCN Control Appli= cation combined with the Diameter QoS Application but does not currently co= ver the first two items identified in Frank's message (i.e specify the maxi= mum number of bindings per end-point & provide resports/stats)? Or is there= another fundamental difference that I overlooked? Best Regards Bruno -----Message d'origine----- De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Fra= nk Brockners (fbrockne) Envoy=E9 : mercredi 22 octobre 2008 18:25 =C0 : Tom Taylor Cc : dime@ietf.org Objet : Re: [Dime] Dime rechartering: Include Carrier-Grade NATControlAppli= cation? Tom, TISPAN Gq' includes NAT-binding control capabilities for sessions at the se= rvice-layer (e.g. SIP sessions) - representing services provided by the SP:= Among other things, Gq' allows P-CSCF to request allocation and/or modific= ation of a binding in BGF for a specific media flow. This makes BGF an anch= or point and natural NAT gateway for service-layer controlled traffic. Henc= e, Gq' is focused on controlling individual bindings for service-level traf= fic flows. Different from that, the CGN Control application is intended as a control i= nterface to the CGN, i.e. a NAT device placed between subscriber-CPE and th= e public Internet by a carrier - typically traversed by all the traffic (de= ployment dependent minus the traffic handled by BGFs). As noted earlier, bi= ndings within the CGN would typically not be created through an external in= terface (with per-binding signaling procedures) but be created on the fly w= ithin the CGN. A CGN and a BGF would typically operate in parallel - where = CGN would provide NAT-services for all of the traffic that is not "steered"= towards a BGF by a P-CSCF (or similar). Still, it is desirable to control = and monitor some of the behavior of the CGN on a per end-point (or subscrib= er) basis, i.e. restrict the number of bindings per subscriber, pre-set cer= tain ip-address/port-ranges, report allocated bindings etc. Given that thos= e rules are typically per subscriber (and won't change frequently), one cou= ld call this "static conditions per end-point" as you note, though we of co= urse would want to include the possibility of dynamic changes. Regards, Frank > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: Tuesday, October 21, 2008 8:15 PM > To: Frank Brockners (fbrockne) > Cc: Hannes Tschofenig; dime@ietf.org > Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade = > NATControl Application? > = > I would want to understand the difference between this and the Gq' = > application that now exists. Just from your words: is it that you are = > talking about imposing static conditions per end point rather than = > per-session control? > = > Frank Brockners (fbrockne) wrote: > > Hannes, > > = > > = > > = > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Monday, October 20, 2008 9:28 PM > >> > >> A few things: = > >> = > >> * The term CGN refers to the ongoing IPv4/IPv6 transition work, = > >> right? If so, I was not aware that they wanted to use an > protocol to > >> request mappings to be created. Instead, the NAT bindings > are created > >> based on the flow of data traffic. > >> Am I wrong? = > > = > > ...FB: "CGN" refers to a Carrier Grade NAT device as used in > > e.g. draft-nishitani-cgn or draft-arkko-townsley-coexistence. > > And I agree that for the general case the bindings would be > > defined by the CGN (taken from external and internal = > > address pools), i.e. typically the binding would not be defined > > by an external entity through an interface. Having > > said that, for certain use cases it might be beneficial to > > also cover the case where you want a specific binding to be > > established. As stated in the abstract, the idea of > > the CGN Control Application it largely to perform per endpoint > > control of the CGN, i.e. = > > - specify the maximum number of bindings per end-point > > (and possibly associated hold-timers) > > - provide resports/stats on the currently allocated > > bindings > > - control parameters of binding(s) (i.e. request a = > > specific external ip-address, ip-address/port, > > ip-address/port-ranges). As a corner case this could = > > allow defintion of a complete binding. = > > = > >> = > >> * Other SDOs have done work on using Diameter for creating, = > >> maintaining and deleting NAT bindings already. We should > re-use their > >> work to avoid duplicate coding efforts. The entire idea of using = > >> Diameter in that space essentially comes from the MIDCOM days, see = > >> http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't = > >> really a AAA application as such (since the AAA server is not = > >> involved there). > > = > > ...FB: We should of course see whether we can leverage work > > which was done in other SDOs. As noted above, creating, > > maintaining and deleting NAT bindings would not be the > > primary objective of the CGN Control Application. This > > is what typical control interfaces to "border gateway > > functions" (like a session border controller) would do. > > Here we'd focus more on the per-endpoint control aspects. > > = > > = > >> = > >> * Is the suggestion to only create a Diameter application for = > >> allocating NAT bindings or also QoS parameters and firewalling = > >> functionality? > > = > > ...FB: Along the lines of what I stated above, the = > > CGN Control Application would really focus on controlling > > bindings on a per-endpoint basis (i.e. provide a set of = > > focused functions for NAT control). QoS and also specific > > firewall rules are somewhat orthogonal (or complimentary). > > = > > = > > Regards, Frank > > = > >> = > >> Ciao > >> Hannes > >> > >> > >> ________________________________ > >> > >> From: dime-bounces@ietf.org > >> [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior > >> Sent: 18 October, 2008 00:42 > >> To: David Frascone; Frank Brockners (fbrockne) > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade = > >> NATControl Application? > >> = > >> = > >> David, > >> = > >> I agree with Frank that having such an application is > required and > >> now is the time to work on it. > >> = > >> I have been engaged with several wireless operators that are = > >> planning to deploy a CGN in the next year. I have been > developing a > >> set of AAA requirements to support such deployements over the past = > >> month. > >> = > >> It would be good to develop those as the CGN draft is being = > >> progressed. > >> = > >> Avi > >> > >> > >> ________________________________ > >> > >> From: dime-bounces@ietf.org > >> [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone > >> Sent: October 17, 2008 9:53 AM > >> To: Frank Brockners (fbrockne) > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] Dime rechartering: Include > Carrier-Grade NAT > >> Control Application? > >> = > >> = > >> Do you think we could have a draft before the meeting? > >> = > >> = > >> On Fri, Oct 17, 2008 at 4:19 AM, Frank > Brockners (fbrockne) > >> wrote: > >> = > >> > >> Hi, > >> = > >> while re-chartering DIME, could we > consider a new application for > >> Carrier-Grade NAT (CGN) control? CGN > has become an important topic > >> within the IPv4-completion/exhaustion > debate - also proven by the > >> significant number of drafts on this > particular topic. = > >> Consequently, per > >> endpoint control of a CGN is an > >> important question to be addressed. > >> Please find an abstract of a > >> forthcoming draft below. I'm working on the > >> full draft, but wanted to get the > abstract out asap so that the > >> work can > >> be considered as part of the new charter. > >> = > >> Thanks, Frank > >> = > >> -- > >> = > >> Title > >> = > >> Diameter Carrier-Grade NAT Control Application > >> = > >> Abstract > >> = > >> The document will describe the framework, messages and = > >> procedures for > >> the Diameter Carrier-Grade NAT Control (CGNC) application. = > >> The > >> Diameter > >> CGNC application allows gateways > (e.g. Network Access Server > >> (NAS)) > >> to > >> interact with Carrier-Grade NAT (CGN) > devices. The interaction > >> is to > >> establish a context to commonly > identify and manage endpoints on > >> gateway and CGN. It is to allow the > gateway to control and > >> manage the > >> = > >> behavior of a CGN on a per-endpoint > basis (e.g. > >> control the total > >> number > >> of bindings for a particular > >> endpoint, request the allocation of > >> a binding for a particular endpoint). = > >> In addition, it allows the CGN > >> to provide information relevant to > accounting purposes to the > >> gateway > >> = > >> (e.g. allocated NAT bindings etc.). > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >> = > >> > >> > >> > >> > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > = > > = > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 22 14:05:21 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE553A698F; Wed, 22 Oct 2008 14:05:21 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E797A3A6945 for ; Wed, 22 Oct 2008 14:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+9gyEK5smtM for ; Wed, 22 Oct 2008 14:05:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B564428C161 for ; Wed, 22 Oct 2008 14:05:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,466,1220227200"; d="scan'208";a="23444829" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2008 21:06:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9ML6EeN028554; Wed, 22 Oct 2008 23:06:14 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9ML6EKB007494; Wed, 22 Oct 2008 21:06:14 GMT Received: from xmb-ams-336.cisco.com ([144.254.231.81]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 23:06:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 23:06:12 +0200 Message-ID: <693E0961C9EFD946AC7067D677463625069E2908@xmb-ams-336.emea.cisco.com> In-Reply-To: <2AF8FF7D89242541B12E7A47F6ECB4BE07BCDEEE@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Dime rechartering: Include Carrier-Grade NATControlApplication? Thread-Index: AckzqPoUzN+PoIctQquEGe2uGkgn0QAsoxaQAAKhXnAACJVPQA== From: "Frank Brockners (fbrockne)" To: , X-OriginalArrivalTime: 22 Oct 2008 21:06:14.0111 (UTC) FILETIME=[046C56F0:01C9348A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12594; t=1224709574; x=1225573574; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fbrockne@cisco.com; z=From:=20=22Frank=20Brockners=20(fbrockne)=22=20 |Subject:=20RE=3A=20[Dime]=20Dime=20rechartering=3A=20Inclu de=20Carrier-Grade=20NATControlApplication? |Sender:=20; bh=8G6sqWCYk5TiaXfpvL8wZP5NY2aNw5iXxw21CwMnzs4=; b=NUK6RT8x+BocTeBcEYdUo36JNnT/1TodzF94xkPZ1Nxr4KMK/O5zxkN9tc W1pp4jiiyEm89xI+qJOt1DIR12PI9qw9ncU2AwKJfE28sYQNLRJwpYgMzDaE LSM9E20QGk; Authentication-Results: ams-dkim-2; header.From=fbrockne@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: dime@ietf.org Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade NATControlApplication? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Bruno, hmm - I agree that Rw/Q.3303.3 has some NAT and QoS control capabilities, t= hough wrt/ NAT, Rw also largely follows the assumption of an external entit= y (i.e. a P-CSCF) which controls the allocation of bindings within the gate= ways (i.e. request creation/modification/removal of bindings)- which is fun= damentally different from a typical environment where a CGN would get deplo= yed. For CGN one would typically not have an external controller request al= location of specific bindings - but create bindings from pre-defined pools = "on the fly". All a CGN-Control app would do is control the basic behavior = of the CGN for all/most of the binding per subscriber/end-point (and the al= location of a specific binding on a per request basis is really a corner ca= se, which would be the exception rather than the rule). As noted earlier - = I'm working on a full draft - which should provide more background and also= be a solid base for discussions (unfortunately it does not evolve as quick= ly as I'd wish because of ongoing internal & external discussions with inte= rested parties). Regards, Frank > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com = > [mailto:bruno.chatras@orange-ftgroup.com] = > Sent: Wednesday, October 22, 2008 7:24 PM > To: Frank Brockners (fbrockne); tom.taylor@rogers.com > Cc: dime@ietf.org > Subject: RE: [Dime] Dime rechartering: Include Carrier-Grade = > NATControlApplication? > = > Tom, Frank, > = > Since were are talking about a control interface sitting just = > above the NAT device I would compare it to ITU-T Rw = > (Recommendation Q.3303.3)rather than ETSI Gq'. Having said = > that, I'm still not sure to understand the differences = > between this GCN control application and existing = > applications such as Gq' and Q.3303.3 (16777256). Both Gq' = > and Rw enable controlling more things than just NAT bindings. = > Is it a correct understanding that the Diameter application = > defined in Q.3303.3 is roughly equivalent to the GCN Control = > Application combined with the Diameter QoS Application but = > does not currently cover the first two items identified in = > Frank's message (i.e specify the maximum number of bindings = > per end-point & provide resports/stats)? Or is there another = > fundamental difference that I overlooked? > = > Best Regards > Bruno > = > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De = > la part de Frank Brockners (fbrockne) Envoy=E9 : mercredi 22 = > octobre 2008 18:25 =C0 : Tom Taylor Cc : dime@ietf.org Objet : = > Re: [Dime] Dime rechartering: Include Carrier-Grade = > NATControlApplication? > = > Tom, > = > TISPAN Gq' includes NAT-binding control capabilities for = > sessions at the service-layer (e.g. SIP sessions) - = > representing services provided by the SP: Among other things, = > Gq' allows P-CSCF to request allocation and/or modification = > of a binding in BGF for a specific media flow. This makes BGF = > an anchor point and natural NAT gateway for service-layer = > controlled traffic. Hence, Gq' is focused on controlling = > individual bindings for service-level traffic flows. > = > Different from that, the CGN Control application is intended = > as a control interface to the CGN, i.e. a NAT device placed = > between subscriber-CPE and the public Internet by a carrier - = > typically traversed by all the traffic (deployment dependent = > minus the traffic handled by BGFs). As noted earlier, = > bindings within the CGN would typically not be created = > through an external interface (with per-binding signaling = > procedures) but be created on the fly within the CGN. A CGN = > and a BGF would typically operate in parallel - where CGN = > would provide NAT-services for all of the traffic that is not = > "steered" towards a BGF by a P-CSCF (or similar). Still, it = > is desirable to control and monitor some of the behavior of = > the CGN on a per end-point (or subscriber) basis, i.e. = > restrict the number of bindings per subscriber, pre-set = > certain ip-address/port-ranges, report allocated bindings = > etc. Given that those rules are typically per subscriber (and = > won't change frequently), one could call this "static = > conditions per end-point" as you note, though we of course = > would want to include the possibility of dynamic changes. > = > Regards, Frank > = > > -----Original Message----- > > From: Tom Taylor [mailto:tom.taylor@rogers.com] > > Sent: Tuesday, October 21, 2008 8:15 PM > > To: Frank Brockners (fbrockne) > > Cc: Hannes Tschofenig; dime@ietf.org > > Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade = > > NATControl Application? > > = > > I would want to understand the difference between this and the Gq' = > > application that now exists. Just from your words: is it = > that you are = > > talking about imposing static conditions per end point rather than = > > per-session control? > > = > > Frank Brockners (fbrockne) wrote: > > > Hannes, > > > = > > > = > > > = > > >> -----Original Message----- > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> Sent: Monday, October 20, 2008 9:28 PM > > >> > > >> A few things: = > > >> = > > >> * The term CGN refers to the ongoing IPv4/IPv6 transition work, = > > >> right? If so, I was not aware that they wanted to use an > > protocol to > > >> request mappings to be created. Instead, the NAT bindings > > are created > > >> based on the flow of data traffic. > > >> Am I wrong? = > > > = > > > ...FB: "CGN" refers to a Carrier Grade NAT device as used in > > > e.g. draft-nishitani-cgn or draft-arkko-townsley-coexistence. > > > And I agree that for the general case the bindings would be > > > defined by the CGN (taken from external and internal = > > > address pools), i.e. typically the binding would not be defined > > > by an external entity through an interface. Having > > > said that, for certain use cases it might be beneficial to > > > also cover the case where you want a specific binding to be > > > established. As stated in the abstract, the idea of > > > the CGN Control Application it largely to perform per endpoint > > > control of the CGN, i.e. = > > > - specify the maximum number of bindings per end-point > > > (and possibly associated hold-timers) > > > - provide resports/stats on the currently allocated > > > bindings > > > - control parameters of binding(s) (i.e. request a = > > > specific external ip-address, ip-address/port, > > > ip-address/port-ranges). As a corner case this could = > > > allow defintion of a complete binding. = > > > = > > >> = > > >> * Other SDOs have done work on using Diameter for creating, = > > >> maintaining and deleting NAT bindings already. We should > > re-use their > > >> work to avoid duplicate coding efforts. The entire idea of using = > > >> Diameter in that space essentially comes from the MIDCOM = > days, see = > > >> http://www.ietf.org/rfc/rfc4097.txt. Please note that this isn't = > > >> really a AAA application as such (since the AAA server is not = > > >> involved there). > > > = > > > ...FB: We should of course see whether we can leverage work > > > which was done in other SDOs. As noted above, creating, > > > maintaining and deleting NAT bindings would not be the > > > primary objective of the CGN Control Application. This > > > is what typical control interfaces to "border gateway > > > functions" (like a session border controller) would do. > > > Here we'd focus more on the per-endpoint control aspects. > > > = > > > = > > >> = > > >> * Is the suggestion to only create a Diameter application for = > > >> allocating NAT bindings or also QoS parameters and firewalling = > > >> functionality? > > > = > > > ...FB: Along the lines of what I stated above, the = > > > CGN Control Application would really focus on controlling > > > bindings on a per-endpoint basis (i.e. provide a set of = > > > focused functions for NAT control). QoS and also specific > > > firewall rules are somewhat orthogonal (or complimentary). > > > = > > > = > > > Regards, Frank > > > = > > >> = > > >> Ciao > > >> Hannes > > >> > > >> > > >> ________________________________ > > >> > > >> From: dime-bounces@ietf.org > > >> [mailto:dime-bounces@ietf.org] On Behalf Of Avi Lior > > >> Sent: 18 October, 2008 00:42 > > >> To: David Frascone; Frank Brockners (fbrockne) > > >> Cc: dime@ietf.org > > >> Subject: Re: [Dime] Dime rechartering: Include Carrier-Grade = > > >> NATControl Application? > > >> = > > >> = > > >> David, > > >> = > > >> I agree with Frank that having such an application is > > required and > > >> now is the time to work on it. > > >> = > > >> I have been engaged with several wireless operators that are = > > >> planning to deploy a CGN in the next year. I have been > > developing a > > >> set of AAA requirements to support such deployements = > over the past = > > >> month. > > >> = > > >> It would be good to develop those as the CGN draft is being = > > >> progressed. > > >> = > > >> Avi > > >> > > >> > > >> ________________________________ > > >> > > >> From: dime-bounces@ietf.org > > >> [mailto:dime-bounces@ietf.org] On Behalf Of David Frascone > > >> Sent: October 17, 2008 9:53 AM > > >> To: Frank Brockners (fbrockne) > > >> Cc: dime@ietf.org > > >> Subject: Re: [Dime] Dime rechartering: Include > > Carrier-Grade NAT > > >> Control Application? > > >> = > > >> = > > >> Do you think we could have a draft before the meeting? > > >> = > > >> = > > >> On Fri, Oct 17, 2008 at 4:19 AM, Frank > > Brockners (fbrockne) > > >> wrote: > > >> = > > >> > > >> Hi, > > >> = > > >> while re-chartering DIME, could we > > consider a new application for > > >> Carrier-Grade NAT (CGN) control? CGN > > has become an important topic > > >> within the IPv4-completion/exhaustion > > debate - also proven by the > > >> significant number of drafts on this > > particular topic. = > > >> Consequently, per > > >> endpoint control of a CGN is an > > >> important question to be addressed. > > >> Please find an abstract of a > > >> forthcoming draft below. I'm working on the > > >> full draft, but wanted to get the > > abstract out asap so that the > > >> work can > > >> be considered as part of the new charter. > > >> = > > >> Thanks, Frank > > >> = > > >> -- > > >> = > > >> Title > > >> = > > >> Diameter Carrier-Grade NAT Control Application > > >> = > > >> Abstract > > >> = > > >> The document will describe the = > framework, messages and = > > >> procedures for > > >> the Diameter Carrier-Grade NAT = > Control (CGNC) application. = > > >> The > > >> Diameter > > >> CGNC application allows gateways > > (e.g. Network Access Server > > >> (NAS)) > > >> to > > >> interact with Carrier-Grade NAT (CGN) > > devices. The interaction > > >> is to > > >> establish a context to commonly > > identify and manage endpoints on > > >> gateway and CGN. It is to allow the > > gateway to control and > > >> manage the > > >> = > > >> behavior of a CGN on a per-endpoint > > basis (e.g. > > >> control the total > > >> number > > >> of bindings for a particular > > >> endpoint, request the allocation of > > >> a binding for a particular endpoint). = > > >> In addition, it allows the CGN > > >> to provide information relevant to > > accounting purposes to the > > >> gateway > > >> = > > >> (e.g. allocated NAT bindings etc.). > > >> _______________________________________________ > > >> DiME mailing list > > >> DiME@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dime > > >> = > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > = > > > = > > = > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 22 22:58:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37BDB3A69B1; Wed, 22 Oct 2008 22:58:03 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467A43A6902 for ; Wed, 22 Oct 2008 22:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7JLKMxXeCdm for ; Wed, 22 Oct 2008 22:58:00 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id 864953A69B2 for ; Wed, 22 Oct 2008 22:58:00 -0700 (PDT) Received: by gxk9 with SMTP id 9so730577gxk.13 for ; Wed, 22 Oct 2008 22:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=slWv7IfIBfs6H83ri9qofUPDLZURrzdA8q8YOaR2dkM=; b=n8I57uf4B/6Rdj/r36Gz5M4FOyiVBgsfq7O6V65+EEeQhMoVY/ZJZg1mzMiOXKxFNk htNxauvhVYYA1GDYG3bnsiNHRJVEqk1D8mUZBUbhT95+r9wK5NtNuU7erst+EEVoSJ8B z8PvGCd4yJjRMSsYyn73wVMcc4pbNoujF7uIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=YZKXWIzVJuUuQ9/SiOsnFCbX6FSMYCBXhfVNC60aVVhxwajyUyhHeodx3cTcWaHbHz 35hCdAZC89RVQRkzvN5k4hTfYpRyEnw62JfP13+yHln2dVkKP/ThJ0i2edORUtGL5aZP 1kyslq/QdRcibKtYThBocH3MNMsuJ8KIPSQ8o= Received: by 10.150.12.3 with SMTP id 3mr3193573ybl.17.1224741558067; Wed, 22 Oct 2008 22:59:18 -0700 (PDT) Received: by 10.150.12.8 with HTTP; Wed, 22 Oct 2008 22:59:17 -0700 (PDT) Message-ID: Date: Thu, 23 Oct 2008 11:29:18 +0530 From: "naveen sarma" To: dime@ietf.org MIME-Version: 1.0 Subject: [Dime] Disconnect cause as BUSY in DPR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1741179908==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1741179908== Content-Type: multipart/alternative; boundary="----=_Part_30135_5006118.1224741558020" ------=_Part_30135_5006118.1224741558020 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Can anyone explain why the receiver of DPR with cause BUSY shouldn't attempt to retry the connection? Is BUSY not a temporary problem? Thanks & Regards, Naveen. ------=_Part_30135_5006118.1224741558020 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Can anyone explain why the receiver of DPR with cause BUSY shouldn't attempt to retry the connection?  Is BUSY not a temporary problem?

Thanks & Regards,
Naveen.
------=_Part_30135_5006118.1224741558020-- --===============1741179908== 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://www.ietf.org/mailman/listinfo/dime --===============1741179908==-- From dime-bounces@ietf.org Thu Oct 23 00:07:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319BD3A6BFC; Thu, 23 Oct 2008 00:07:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DE43A69B1 for ; Thu, 23 Oct 2008 00:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.927 X-Spam-Level: * X-Spam-Status: No, score=1.927 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rIzSfimB+yJ for ; Thu, 23 Oct 2008 00:07:09 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 98DE83A6BD8 for ; Thu, 23 Oct 2008 00:07:09 -0700 (PDT) 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 <0K960027UJTN5M@szxga01-in.huawei.com> for dime@ietf.org; Thu, 23 Oct 2008 15:08:11 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K960094ZJTNNL@szxga01-in.huawei.com> for dime@ietf.org; Thu, 23 Oct 2008 15:08:11 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9600896JTN0Z@szxml03-in.huawei.com> for dime@ietf.org; Thu, 23 Oct 2008 15:08:11 +0800 (CST) Date: Thu, 23 Oct 2008 15:08:10 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <008d01c934de$1b7498e0$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <693E0961C9EFD946AC7067D677463625069E2908@xmb-ams-336.emea.cisco.com> Subject: [Dime] Diameter Routing Problem Statement draft for your comments X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0296656637==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0296656637== Content-type: multipart/alternative; boundary="Boundary_(ID_Jug6rSRm5Uq5yOKDEx2FgQ)" This is a multi-part message in MIME format. --Boundary_(ID_Jug6rSRm5Uq5yOKDEx2FgQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, Here is Diameter Routing Problem Statement draft for your comments. Filename: draft-ietf-dime-routing-problem-statement Version: 00 Staging URL: http://www3.ietf.org/proceedings/staging/draft-ietf-dime-routing-problem-statement-00.txt Title: Diameter Routing Problem Statement Creation_date: 2008-10-19 WG ID: dime Number_of_pages: 8 Abstract: This document describes use cases that suggest requirements to be able to add constraints to the existing Diameter routing mechanisms. B. R. Tina --Boundary_(ID_Jug6rSRm5Uq5yOKDEx2FgQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,
Here is Diameter Routing Problem Statement draft for your comments.
Filename:    draft-ietf-dime-routing-problem-statement
Version:    00
Staging URL:    http://www3.ietf.org/proceedings/staging/draft-ietf-dime-routing-problem-statement-00.txt
Title:    Diameter Routing Problem Statement
Creation_date:    2008-10-19
WG ID:    dime
Number_of_pages: 8
Abstract:
This document describes use cases that suggest requirements to be
able to add constraints to the existing Diameter routing mechanisms.
 
B. R.
Tina
 
 
--Boundary_(ID_Jug6rSRm5Uq5yOKDEx2FgQ)-- --===============0296656637== 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://www.ietf.org/mailman/listinfo/dime --===============0296656637==-- From dime-bounces@ietf.org Mon Oct 27 00:48:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0545628C147; Mon, 27 Oct 2008 00:48:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014B93A68CC for ; Mon, 27 Oct 2008 00:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.854 X-Spam-Level: X-Spam-Status: No, score=-4.854 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrbZ6g8dOCoV for ; Mon, 27 Oct 2008 00:48:25 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 19EF73A68F1 for ; Mon, 27 Oct 2008 00:48:24 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9R7mNE3022224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Oct 2008 08:48:23 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9R7mJVr029863 for ; Mon, 27 Oct 2008 08:48:22 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 08:48:19 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 08:48:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 09:48:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim meeting in January Thread-Index: Ack4CGBsJzffXtJXTeGvPsuqAeo7Qg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 27 Oct 2008 07:48:19.0145 (UTC) FILETIME=[60C90390:01C93808] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027084823-115F7BB0-374F7059/0-0/0-15 X-purgate-size: 955/0 Subject: [Dime] Interim meeting in January X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0855417809==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0855417809== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93808.60940784" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93808.60940784 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me know ASAP if you would like to have an interim meeting in January next year.=20 ------_=_NextPart_001_01C93808.60940784 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interim meeting in January

Let me know ASAP if you would = like to have an interim meeting in January next year.


------_=_NextPart_001_01C93808.60940784-- --===============0855417809== 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://www.ietf.org/mailman/listinfo/dime --===============0855417809==-- From dime-bounces@ietf.org Mon Oct 27 03:10:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B0A3A688B; Mon, 27 Oct 2008 03:10:24 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA3D3A6855 for ; Mon, 27 Oct 2008 03:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lylu0APs8ZTd for ; Mon, 27 Oct 2008 03:10:22 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id 16A273A688B for ; Mon, 27 Oct 2008 03:10:21 -0700 (PDT) Received: from [192.130.165.76] (pc-xc76.wlan.inet.fi [192.130.165.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 6EC091395DF; Mon, 27 Oct 2008 12:10:16 +0200 (EET) Message-ID: <49059384.8060802@kolumbus.fi> Date: Mon, 27 Oct 2008 12:10:12 +0200 From: Jouni User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: In-Reply-To: Cc: dime@ietf.org Subject: Re: [Dime] Interim meeting in January X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jouni.korhonen@iki.fi List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org If we cannot progress those I-Ds with 3GPP dependency to IESG within a month, then I think we an interim could be justified. Cheers, Jouni Tschofenig, Hannes (NSN - FI/Espoo) kirjoitti: > > Let me know ASAP if you would like to have an interim meeting in > January next year. > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 27 04:49:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F3C3A6A0F; Mon, 27 Oct 2008 04:49:25 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D763D3A69CC; Mon, 27 Oct 2008 04:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+GnoYN+wmKS; Mon, 27 Oct 2008 04:49:21 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 80C9E3A69EF; Mon, 27 Oct 2008 04:49:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9RBnJD7000703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Oct 2008 12:49:19 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9RBnGsq010607; Mon, 27 Oct 2008 12:49:19 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 12:49:11 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.16]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 12:49:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 13:49:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Interim Meeting Opportunity in January 2009 Thread-Index: AckyEW0uQ2P+BHW7RPqTb+mqLvqD5wGGBYAw From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" , , X-OriginalArrivalTime: 27 Oct 2008 11:49:11.0087 (UTC) FILETIME=[06D05BF0:01C9382A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::081027124919-63996BB0-C09AB10F/0-0/0-15 X-purgate-size: 2561/0 Subject: [Dime] FW: WG Interim Meeting Opportunity in January 2009 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org It seems that not everyone is following various discussions on IETF mailing lists and is therefore not informed about the new plans of our IETF Chair Russ Housely. Here is a forward: >-----Original Message----- >From: wgchairs-bounces@ietf.org >[mailto:wgchairs-bounces@ietf.org] On Behalf Of IETF Chair >Sent: 16 October, 2008 23:34 >To: Working Group Chairs >Cc: chair@ietf.org >Subject: WG Interim Meeting Opportunity in January 2009 > >In our continuing effort to ensure that IETF WGs are getting >enough meeting time to progress their work, we are conducting >another experiment. > Many WGs have found interim meetings an effective way to >tackle thorny technical issues, resolve contentious technical >issues, accelerate standards development, and provide traction >for new work. As always, an interim WG meeting is not a >substitute for a regular session at the traditional IETF >meeting. Since some WG Chairs and ADs have found the amount >of time necessary to put together an interim meeting can be >excessive, we are trying to reduce the effort necessary to >conduct an interim meeting to determine whether reducing this >burden will expedite IETF standards development. To this end, >the Secretariat will facilitate a large interim meeting from >20-22 January 2009 in Malta. If you are interested in >participating in this experiment, please contact your Area >Director for approval. All face-to-face interim meetings >require AD approval, and this is no exception. The IETF >Secretariat is putting together a program with three full days >and four tracks on each day. Each WG interim meeting is >expected to consume at least one full day on one of the tracks. > >ADs will schedule the sessions. A URL for the schedule will >be announced shortly. Once it is available, if you detect a >scheduling conflict, please raise the concern with your AD for >resolution. Session time is limited, and sessions will be >allocated first come, first served. > >The Secretariat will provide registration, food and beverage, >audio visual facilities, and on site registration support. >VeriLAN will provide network and audio streaming support. It >is expected that the meeting fee will be $375 for early >registration and $475 for late registration. > >The Internet Society is looking for meeting sponsors for this event. >Anyone interested please contact Drew Dvorshak . > >Russ > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 27 10:00:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3BF3A6B9D; Mon, 27 Oct 2008 10:00:07 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0DC763A6B33; Mon, 27 Oct 2008 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081027170002.0DC763A6B33@core3.amsl.com> Date: Mon, 27 Oct 2008 10:00:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org 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 Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-13.txt Pages : 35 Date : 2008-10-27 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dime-mip6-split-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27095407.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Oct 28 12:30:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E2E3A68A4; Tue, 28 Oct 2008 12:30:01 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2C8993A68A4; Tue, 28 Oct 2008 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081028193001.2C8993A68A4@core3.amsl.com> Date: Tue, 28 Oct 2008 12:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org 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 Attributes for Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-08.txt Pages : 38 Date : 2008-10-28 This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dime-qos-attributes-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-28122623.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Oct 28 19:57:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328873A6A08; Tue, 28 Oct 2008 19:57:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D8E3A6A08 for ; Tue, 28 Oct 2008 19:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFMAVfw+oKEc for ; Tue, 28 Oct 2008 19:57:48 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C21953A677D for ; Tue, 28 Oct 2008 19:57:48 -0700 (PDT) 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 <0K9H0064VC8A8B@szxga01-in.huawei.com> for dime@ietf.org; Wed, 29 Oct 2008 10:57:46 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9H00H9PC8A02@szxga01-in.huawei.com> for dime@ietf.org; Wed, 29 Oct 2008 10:57:46 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9H00L8IC8AYS@szxml03-in.huawei.com> for dime@ietf.org; Wed, 29 Oct 2008 10:57:46 +0800 (CST) Date: Wed, 29 Oct 2008 10:57:46 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <00b701c93972$1ed6fa30$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [Dime] draft-tsou-dime-routing-problem-statement-00.txt is available for your comments X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1872667456==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1872667456== Content-type: multipart/alternative; boundary="Boundary_(ID_DGsCHyYb6TSUjEsVaJDuwQ)" This is a multi-part message in MIME format. --Boundary_(ID_DGsCHyYb6TSUjEsVaJDuwQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT >> A new version of I-D, draft-tsou-dime-routing-problem-statement-00.txt >> has been successfuly submitted by Tina Tsou and posted to the IETF >> repository. >> >> Filename: draft-tsou-dime-routing-problem-statement >> Revision: 00 >> Title: Diameter Routing Problem Statement >> Creation_date: 2008-10-27 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> This document describes use cases that suggest requirements to be >> able to add constraints to the existing Diameter routing mechanisms. B. R. Tina --Boundary_(ID_DGsCHyYb6TSUjEsVaJDuwQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
>> A new version of I-D, draft-tsou-dime-routing-problem-statement-00.txt
>> has been successfuly submitted by Tina Tsou and posted to the IETF
>> repository.
>>
>> Filename:     draft-tsou-dime-routing-problem-statement
>> Revision:     00
>> Title:         Diameter Routing Problem Statement
>> Creation_date:     2008-10-27
>> WG ID:         Independent Submission
>> Number_of_pages: 8
>>
>> Abstract:
>> This document describes use cases that suggest requirements to be
>> able to add constraints to the existing Diameter routing mechanisms.
B. R.
Tina
--Boundary_(ID_DGsCHyYb6TSUjEsVaJDuwQ)-- --===============1872667456== 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://www.ietf.org/mailman/listinfo/dime --===============1872667456==-- From dime-bounces@ietf.org Wed Oct 29 00:46:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9974A3A6AAE; Wed, 29 Oct 2008 00:46:59 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C64E3A6934 for ; Wed, 29 Oct 2008 00:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akSjz1BcxM4T for ; Wed, 29 Oct 2008 00:46:56 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 87CE03A6AAE for ; Wed, 29 Oct 2008 00:46:55 -0700 (PDT) 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 <0K9H00KZPPLWME@szxga03-in.huawei.com> for dime@ietf.org; Wed, 29 Oct 2008 15:46:44 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9H007N3PLWBT@szxga03-in.huawei.com> for dime@ietf.org; Wed, 29 Oct 2008 15:46:44 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9H00HZUPLWG1@szxml05-in.huawei.com> for dime@ietf.org; Wed, 29 Oct 2008 15:46:44 +0800 (CST) Date: Wed, 29 Oct 2008 15:46:44 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <020601c9399a$7d0ed280$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [Dime] Fw: [Q5/11] Fw: Q.3303.3 Application-Id value X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0798329128==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0798329128== Content-type: multipart/alternative; boundary="Boundary_(ID_R9LbTA1TbxZ3Q/dGuGGpsg)" This is a multi-part message in MIME format. --Boundary_(ID_R9LbTA1TbxZ3Q/dGuGGpsg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT B. R. Tina ----- Original Message ----- From: Tina TSOU To: Tom Taylor ; Sun, Dong (Dong) ; tsg11q5@itu.int Cc: dime@ietf.org Sent: Wednesday, October 29, 2008 3:22 PM Subject: [Q5/11] Fw: Q.3303.3 Application-Id value Dong, Thanks for your reply and work effort with Hannes. All, Per the observation from Q.5/11, may I summarize the consensus as the following? Does PIA/PIR code need to be included in Q.3303.3 BEFORE TSB publish it? [Q.5/11: Yes. And we are waiting for IETF to allocate this command code, nevertheless how long it will take.] Would you send us the precise marked up text sections/paragraphs showing the exact text and its location where the codes are to be inserted in the text? [Q.5/11: In the attachment.] If no objection received before 24:00 Oct 29th CET, I will take the above as Q.5/11 consensus answer to ITU-T SG11 TSB. P.s. if this email is not able to reach dime@ietf.org as there is attachment, I will forward it again to that list. B. R. Tina ITU-T Q.5/11 Rapporteur ----- Original Message ----- From: Sun, Dong (Dong) To: Tina TSOU ; Tom Taylor Cc: tsg11q5@itu.int Sent: Wednesday, October 29, 2008 1:35 AM Subject: RE: [Q5/11] Fw: Q.3303.3 Application-Id value Yes. I think so. Otherwise, it is incomplete and cannot be implemented. I am working with Hannes to work it out for the command code. Certainly it is out of our control in terms of the timeframe to get it done. But as a general issue, it will be helpful if your guys can also express the concern in IETF. Dong ------------------------------------------------------------------------------ From: Tina TSOU [mailto:tena@huawei.com] Sent: Tuesday, October 28, 2008 2:46 AM To: Tom Taylor; Sun, Dong (Dong) Cc: tsg11q5@itu.int Subject: [Q5/11] Fw: Q.3303.3 Application-Id value Hi Dong, Tom et al, What's your answer to this question? > 1) Does PIA/PIR code need to be included in Q.3303.3 BEFORE TSB publish it? B. R. Tina ----- Original Message ----- From: Sun, Dong (Dong) To: Tina TSOU ; Tom Taylor Cc: tsg11q5@itu.int Sent: Monday, October 27, 2008 12:15 PM Subject: RE: [Q5/11] Fw: Q.3303.3 Application-Id value Tina, All, I prefer to get an official command code from the IETF eventually since this command PIR/PIA is also used by the ETSI TISPAN Re interface. If it is really a matter to publish this Rec timely, iat least a note is needed for this issue. In addition, I made some update on the AVP flags according to Hannes comment and the application ID. Pls take a look. Thanks, Dong ---------------------------------------------------------------------------- From: owner-tsg11q5@itu.int [mailto:owner-tsg11q5@itu.int] On Behalf Of Tina TSOU Sent: Monday, October 27, 2008 12:05 AM To: Tom Taylor Cc: tsg11q5@itu.int Subject: [Q5/11] Fw: Q.3303.3 Application-Id value Hi Tom, Thanks for your detailed comments. Then, can we get it as ITU-specified command code? If no, we can write down in Q.3303.3 that it is mandatory to check the auth-application-ID when using PIR/PIA command. B. R. Tina ----- Original Message ----- From: Tom Taylor To: Tina TSOU Cc: tsg11q5@itu.int Sent: Monday, October 27, 2008 10:20 AM Subject: Re: [Q5/11] Fw: Q.3303.3 Application-Id value The argument for using the experimental command code is that it lets us approve our document and publish it. I don't think use of that command code is automatically a threat to interoperability, but this assumes that implementations are careful about checking the auth-application-ID for every command. The arguments against are: -- This clearly violates the IETF's original intent for command codes, although their attitude may be more relaxed now. -- No vendor can add their own experimental commands to their implementation of Q.3303.3, since that would result in a collision with the ITU-specified command code. I have no idea whether vendors actually do this sort of thing. Tom Taylor Tina TSOU wrote: > Dear all, > Kind reminder... > Hope we can reach consensus before 24:00 Oct 27th CET. > > B. R. > Tina > ----- Original Message ----- > From: Tina TSOU > To: tsg11q5@itu.int > Sent: Thursday, October 23, 2008 3:17 PM > Subject: [Q5/11] Fw: Q.3303.3 Application-Id value > > > Dear all, > My personal answer is in line below. > You are encouraged to express your thought. > > B. R. > Tina > ----- Original Message ----- > From: Tina TSOU > To: tsg11q5@itu.int > Sent: Monday, October 20, 2008 11:39 AM > Subject: [Q5/11] Fw: Q.3303.3 Application-Id value > > > Dear all, > Some questions to the list. Hope we can reach consensus before 24:00 Oct 27th CET. And then I can reply to TSB on behalf of Q.5/11. > 1) Does PIA/PIR code need to be included in Q.3303.3 BEFORE TSB publish it? > [Tina: Yes.] > > 2) Do you agree that since the command messages would contain the Q.3303.3 application identifier, the code would be unambiguously identified? > [Tina: Yes. We can use the values 16,777,214 as PIR/PIA commands, with the Q.3303.3 application identifier 16777256.] > > 3) For the editor Dong SUN, would you send us the precise marked up text sections/paragraphs showing the exact text and its location where the codes are to be inserted in the text? > > > B. R. > Tina > ITU-T Q.5/11 Rapporteur ... --Boundary_(ID_R9LbTA1TbxZ3Q/dGuGGpsg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
 
B. R.
Tina
----- Original Message -----
From: Tina TSOU
Sent: Wednesday, October 29, 2008 3:22 PM
Subject: [Q5/11] Fw: Q.3303.3 Application-Id value

Dong,
Thanks for your reply and work effort with Hannes.
 
All,
Per the observation from Q.5/11, may I summarize the consensus as the following?
 
Does PIA/PIR code need to be included in Q.3303.3 BEFORE TSB publish it?
[Q.5/11: Yes. And we are waiting for IETF to allocate this command code, nevertheless how long it will take.]
 
Would you send us the precise marked up text sections/paragraphs showing the exact text and its location where the codes are to be inserted in the text?
[Q.5/11: In the attachment.]
 
If no objection received before 24:00 Oct 29th CET, I will take the above as Q.5/11 consensus answer to ITU-T SG11 TSB.
P.s. if this email is not able to reach dime@ietf.org as there is attachment, I will forward it again to that list.
 
B. R.
Tina
ITU-T Q.5/11 Rapporteur
----- Original Message -----
Sent: Wednesday, October 29, 2008 1:35 AM
Subject: RE: [Q5/11] Fw: Q.3303.3 Application-Id value

Yes. I think so. Otherwise, it is incomplete and cannot be implemented.
I am working with Hannes to work it out for the command code. Certainly it is out of our control in terms of the timeframe to get it done. But as a general issue, it will be helpful if your guys can also express the concern in IETF.
 
Dong

From: Tina TSOU [mailto:tena@huawei.com]
Sent: Tuesday, October 28, 2008 2:46 AM
To: Tom Taylor; Sun, Dong (Dong)
Cc: tsg11q5@itu.int
Subject: [Q5/11] Fw: Q.3303.3 Application-Id value

Hi Dong, Tom et al,
What's your answer to this question?
>     1) Does PIA/PIR code need to be included in Q.3303.3 BEFORE TSB publish it?
B. R.
Tina
----- Original Message -----
Sent: Monday, October 27, 2008 12:15 PM
Subject: RE: [Q5/11] Fw: Q.3303.3 Application-Id value

Tina, All,

I prefer to get an official command code from the IETF eventually since this command PIR/PIA is also used by the ETSI TISPAN Re interface. If it is really a matter to publish this Rec timely, iat least a note is needed for this issue.

In addition, I made some update on the AVP flags according to Hannes comment and the application ID. Pls take a look.

Thanks,

Dong


From: owner-tsg11q5@itu.int [mailto:owner-tsg11q5@itu.int] On Behalf Of Tina TSOU
Sent: Monday, October 27, 2008 12:05 AM
To: Tom Taylor
Cc: tsg11q5@itu.int
Subject: [Q5/11] Fw: Q.3303.3 Application-Id value

Hi Tom,
Thanks for your detailed comments.

Then, can we get it as ITU-specified command code?
 
If no, we can write down in Q.3303.3 that it is mandatory to check the auth-application-ID when using PIR/PIA command.
 
B. R.
Tina
----- Original Message -----
From: Tom Taylor
Sent: Monday, October 27, 2008 10:20 AM
Subject: Re: [Q5/11] Fw: Q.3303.3 Application-Id value

The argument for using the experimental command code is that it lets us approve
our document and publish it. I don't think use of that command code is
automatically a threat to interoperability, but this assumes that
implementations are careful about checking the auth-application-ID for every
command.

The arguments against are:

-- This clearly violates the IETF's original intent for command codes, although
their attitude may be more relaxed now.

-- No vendor can add their own experimental commands to their implementation of
Q.3303.3, since that would result in a collision with the ITU-specified command
code. I have no idea whether vendors actually do this sort of thing.

Tom Taylor

Tina TSOU wrote:
> Dear all,
> Kind reminder...
> Hope we can reach consensus before 24:00 Oct 27th CET.
>
> B. R.
> Tina
>   ----- Original Message -----
>   From: Tina TSOU
>   To: tsg11q5@itu.int
>   Sent: Thursday, October 23, 2008 3:17 PM
>   Subject: [Q5/11] Fw: Q.3303.3 Application-Id value
>
>
>   Dear all,
>   My personal answer is in line below.
>   You are encouraged to express your thought.
>
>   B. R.
>   Tina
>     ----- Original Message -----
>     From: Tina TSOU
>     To: tsg11q5@itu.int
>     Sent: Monday, October 20, 2008 11:39 AM
>     Subject: [Q5/11] Fw: Q.3303.3 Application-Id value
>
>
>     Dear all,
>     Some questions to the list. Hope we can reach consensus before 24:00 Oct 27th CET. And then I can reply to TSB on behalf of Q.5/11.
>     1) Does PIA/PIR code need to be included in Q.3303.3 BEFORE TSB publish it?
>     [Tina: Yes.]
>
>     2) Do you agree that since the command messages would contain the Q.3303.3 application identifier, the code would be unambiguously identified?
>     [Tina: Yes. We can use the values 16,777,214 as PIR/PIA commands, with the Q.3303.3 application identifier 16777256.]
>
>     3) For the editor Dong SUN, would you send us the precise marked up text sections/paragraphs showing the exact text and its location where the codes are to be inserted in the text?
>
>
>     B. R.
>     Tina
>     ITU-T Q.5/11 Rapporteur
...


--Boundary_(ID_R9LbTA1TbxZ3Q/dGuGGpsg)-- --===============0798329128== 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://www.ietf.org/mailman/listinfo/dime --===============0798329128==-- From dime-bounces@ietf.org Thu Oct 30 05:46:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4016B3A689B; Thu, 30 Oct 2008 05:46:03 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49773A68D1 for ; Thu, 30 Oct 2008 05:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhbZBTVcpyNh for ; Thu, 30 Oct 2008 05:46:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 144DD3A691D for ; Thu, 30 Oct 2008 05:45:44 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9UCjghD018621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 30 Oct 2008 13:45:42 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9UCjeow023213 for ; Thu, 30 Oct 2008 13:45:41 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 13:45:39 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 13:45:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 14:45:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short WGLC for draft-ietf-dime-mip6-split-13.txt Thread-Index: Ack6jWiII9AePjeKRki5PgFEyeYtqg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 30 Oct 2008 12:45:39.0029 (UTC) FILETIME=[696C8850:01C93A8D] Subject: [Dime] Short WGLC for draft-ietf-dime-mip6-split-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, Recently a revision of http://tools.ietf.org/html/draft-ietf-dime-mip6-split-13 was released to capture the feedback from the group on the previous WGLC. Based on the changes we need to issue another short last call. Please respond to the list with your reviews and comments by Friday, November 14. Ciao Hannes & Dave PS: Please note that some functionality got moved into a separate small document http://tools.ietf.org/id/draft-korhonen-dime-mip6-feature-bits-00.txt that will be submitted to the RFC Editor directly (i.e., not through the working group) to register some optional functionality. We would need another person to support Jouni with getting the document through the standardization process. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 30 05:46:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626463A69DB; Thu, 30 Oct 2008 05:46:03 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5063A691D for ; Thu, 30 Oct 2008 05:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnCVYi9rMwkU for ; Thu, 30 Oct 2008 05:46:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3DF8A3A689B for ; Thu, 30 Oct 2008 05:45:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9UCjblD018372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 30 Oct 2008 13:45:37 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9UCjXMN022816 for ; Thu, 30 Oct 2008 13:45:37 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 13:45:36 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 13:45:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 14:45:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short WGLC for draft-ietf-dime-qos-attributes-08.txt Thread-Index: Ack6jWck1V/BcHVHSI+Ol1VXosp+tg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 30 Oct 2008 12:45:36.0326 (UTC) FILETIME=[67D01660:01C93A8D] Subject: [Dime] Short WGLC for draft-ietf-dime-qos-attributes-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1907604913==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1907604913== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93A8D.6790A4F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93A8D.6790A4F6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all,=20 Recently a revision of=20 http://tools.ietf.org/html/draft-ietf-dime-qos-attributes-08 was released to capture the feedback from the group on the previous WGLC. Based on the changes we need to issue another short last call. Please respond to the list with your reviews and comments by Friday, November 14. Ciao Hannes & Dave=20 ------_=_NextPart_001_01C93A8D.6790A4F6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Short WGLC for draft-ietf-dime-qos-attributes-08.txt

Hi all,

Recently a revision of
= http://tools.ietf.org/html/draft-ietf-dime-qos-attributes-08<= /U>
was released to capture the = feedback from the group on the previous WGLC.

Based on the changes we need to = issue another short last call.  Please respond to the list with = your reviews and comments by Friday, November 14.

Ciao
Hannes & Dave

------_=_NextPart_001_01C93A8D.6790A4F6-- --===============1907604913== 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://www.ietf.org/mailman/listinfo/dime --===============1907604913==-- From dime-bounces@ietf.org Thu Oct 30 06:14:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507E23A6957; Thu, 30 Oct 2008 06:14:20 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0243A6957 for ; Thu, 30 Oct 2008 06:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.21 X-Spam-Level: X-Spam-Status: No, score=-5.21 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nb1UnuYPGAj for ; Thu, 30 Oct 2008 06:14:14 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 857823A6822 for ; Thu, 30 Oct 2008 06:14:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9UDEBZU008610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 30 Oct 2008 14:14:11 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9UDEBtw023112 for ; Thu, 30 Oct 2008 14:14:11 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 14:14:11 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 14:14:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 15:14:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter QoS Application Thread-Index: Ack6kWOl00Nf1e/sTtSjM5EFtRSXOA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 30 Oct 2008 13:14:09.0370 (UTC) FILETIME=[64DDDBA0:01C93A91] Subject: [Dime] Diameter QoS Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Dan made a good comment in his review of the QoS parameter document: >3. This document will trigger again the issue of exceeding the >AAA scope of DIAMETER as described by RFC 3588, raised in a >number of previous occasions, last by Brian Carpenter in his >GenART review for draft-sun-dime-itu-t-rw. I suggest to put >text in the Introduction section mentioning the issue of scope >and referring to rfc3588bis as an Informational Reference. dime-qos-parameters-06.txt does not raise this issue and the same is true for http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/. However, when used in http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt then there are again the same issues as previously raised already. As such, I suggest that the group helps Dong with his document (draft-sun-dime-itu-t-rw) since the same issue will come up again. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 30 14:35:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2C128C130; Thu, 30 Oct 2008 14:35:58 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7BD3A67A4 for ; Thu, 30 Oct 2008 14:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8OQPCdVYGfy for ; Thu, 30 Oct 2008 14:35:55 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 53BAA3A6B54 for ; Thu, 30 Oct 2008 14:35:45 -0700 (PDT) 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 m9ULZTY4006630; Thu, 30 Oct 2008 16:35:31 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Oct 2008 16:35:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C93AD7.6EA58209" Date: Thu, 30 Oct 2008 16:35:29 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D0204C90B@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Application Thread-Index: Ack6kWOl00Nf1e/sTtSjM5EFtRSXOAAPH7AQ References: From: "Sun, Dong \(Dong\)" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , X-OriginalArrivalTime: 30 Oct 2008 21:35:30.0807 (UTC) FILETIME=[6ECCE070:01C93AD7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Dime] Diameter QoS Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C93AD7.6EA58209 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hannes, All, Thanks for bringing up this issue. Indeed, we need a quick reaction on this matter. It is now affecting the work progress (holding on the publication of approved Recommendation) in both ITU-T and ETSI TISPAN since there are a couple of interface spec (i.e. ITU-T Rw in the RACF and TISPAN Re in the RACS) are using this new command code - PIR/PIA. According to Dan's comment (see attached), further review should be performed with some clarification, the only action item related to this draft is the ITEM 3 -=20 "Propose text for an update to the document including reasoning for=20 > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will=20 > draft such a text" i.e. why a Diameter application is defined for non-AAA case. just wondering how to proceed. Who will draft the texts for the question - why Diameter protocol is used for non-AAA application? When the next round of review will be performed? I can sumbmit an updated version when we have the agreed texts. Thanks, Dong -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, October 30, 2008 9:14 AM To: dime@ietf.org Subject: [Dime] Diameter QoS Application Dan made a good comment in his review of the QoS parameter document:=20 >3. This document will trigger again the issue of exceeding the AAA=20 >scope of DIAMETER as described by RFC 3588, raised in a number of=20 >previous occasions, last by Brian Carpenter in his GenART review for=20 >draft-sun-dime-itu-t-rw. I suggest to put text in the Introduction=20 >section mentioning the issue of scope and referring to rfc3588bis as an >Informational Reference. dime-qos-parameters-06.txt does not raise this issue and the same is true for http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/.=20 However, when used in http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt then there are again the same issues as previously raised already.=20 As such, I suggest that the group helps Dong with his document (draft-sun-dime-itu-t-rw) since the same issue will come up again.=20 Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C93AD7.6EA58209 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from ilexp02.ndc.lucent.com ([135.3.39.2]) by ILEXC2U01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 02:48:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Received: from hoemail2.alcatel.com ([172.22.12.28]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 02:48:10 -0500 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hoemail2.alcatel.com (8.13.8/IER-i) with SMTP id m7T7m9iP019173 for ; Fri, 29 Aug 2008 02:48:10 -0500 (CDT) Received: (qmail 17750 invoked by uid 0); 29 Aug 2008 07:48:09 -0000 Received: from 192.100.124.219 by www148.gmx.net with HTTP; Fri, 29 Aug 2008 09:48:08 +0200 (CEST) Content-class: urn:content-classes:message Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw Date: Fri, 29 Aug 2008 02:48:09 -0500 Message-ID: <20080829074809.28900@gmx.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: DISCUSS: draft-sun-dime-itu-t-rw Thread-Index: AckJq5c2TX70ffYARnmnaWg4wuFkWQ== From: "Hannes Tschofenig" To: "Romascanu, Dan \(Dan\)" , , Cc: "Sun, Dong \(Dong\)" , Hi Dan,=20 let me quickly respond to this issue:=20 > As expected the document was not approved by the IESG and is now in AD > Follow-up.=20 >=20 > Beyond the two DISCUSSes there were two ABSTAIN ballots.=20 >=20 > The principal concern that I heard was related to the fact that the > current process followed by the draft did not ensure a sufficient level > of review from the IETF to ensure that it really meets the IETF > consensus.=20 >=20 > In order to overcome this I suggest that we do the following:=20 >=20 > 1. Ask for at least one more review (two is better) from the AAA-Doctors > team or DIME WG making also sure that the reviewers also include reading > the relevant parts in the ITU-T document in their review (Hannes, can > you ask Bernard to be one of the reviewers?) I sent a mail to him.=20 >=20 > 2. Explain to the IESG why the DIME Working Group did not take this work > as a WG chartered item (hannes, please write a short explanation, also > include the discussions around 3588bis) draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using Diameter. In the DIME working group we also have a document that deals with QoS signaling, namely http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt. It does, however, not cover NAT and Firewall signaling aspects.=20 Other SDOs are, however, not required to use the work we do in the IETF on certain Diameter applications. Additionally, they may enhance or modify it. There are many reasons why this happens and I will not go into the details of those. Call it a matter of life that has todo with psychology rather than technical arguments.=20 For us in DIME it does not really matter why ITU-T works on this specific subject and it does not matter to us from a review point of view either.=20 The reason why the ITU-T (and previously OMA with http://tools.ietf.org/html/rfc5224) came to the DIME working group is actually related to a suggestion from our side (based on the Diameter extensibility discussions we had) to define new Command Codes whenever the ABNF of a command is modified by adding, removing or semantically changing required AVP (i.e, those marked as {}). By defining new Command Codes we believe to better avoid interoperability problems.=20 The OMA has followed that suggestion (and so did ITU-T, to some extend) but obviously ran into an issue with the requirements for the allocation of Command Codes (compared to the allocation of Application IDs) based on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to register applications without going through the IETF process but has different rules for the allocation of Command Codes. The DIME working group had a long discussion about this issue and decided to change the rules for allocating Command Codes with the revision of RFC 3588 (see http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt) and to align the procedure with the way how Application IDs are requested. The main reasons for this decision were the following:=20 * We did not want to encourage SDOs to misuse Diameter Command Codes when they don't want to come to the IETF (and thereby causing interoperability issues).=20 * We did not want to drag all the SDOs to the IETF when it comes to extending Diameter. Diameter is a very popular protocols among other SDOs and this approach would not scale very well nor are we the experts in all the applications areas people have in mind where Diameter could be used. * Some of us believe that the decision to have different rules for Application ID allocation and Command Code assignment was a mistake since it does not make a lot of sense from a logical point of view.=20 * We should not treat the 3GPP differently to other SDOs since the 3GPP was given a bunch of Command Codes without a corresponding specification (see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be consistent in our behavior.=20 As such, we came up with the idea to have an "interim" solution for dealing with requests regarding Diameter Command Codes before RFC 3588bis gets published as an RFC.=20 > 3. Propose text for an update to the document including reasoning for > ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will draft > such a text I will think about text. Maybe it is lack of imagination on how protocols could be used? Wouldn't be the first time that a protocol is used in a way not originally envisioned. Example: RSVP - RSVP-TE Funny enough, the idea about using Diameter for the purpose of NAT and firewall signaling actually came from the IETF MIDCOM working group, see http://www.ietf.org/rfc/rfc4097.txt Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite protocol and it turns out that this was the wrong decision. Hard to predict preferences... >=20 > Also in parallel the DIME WG should do the best to accelerate the > approval and submission of RFC3588 to the IESG so that we will need to > deal with as few such cases in the future as possible (ideally zero).=20 That's certainly a good idea. We are having a final round of reviews and I have asked the authors of the draft to also re-read the document to avoid problems in later stages (as they have happened with other Diameter documents already).=20 Ciao Hannes >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On=20 > > Behalf Of Chris Newman > > Sent: Thursday, August 28, 2008 7:29 PM > > To: iesg@ietf.org > > Cc: Hannes.Tschofenig@gmx.net;=20 > > draft-sun-dime-itu-t-rw@tools.ietf.org; dongsun@alcatel-lucent.com > > Subject: DISCUSS: draft-sun-dime-itu-t-rw=20 > >=20 > > Discuss: > > As this issue was raised during IETF review and appears to=20 > > concern a number of area directors, I'm holding an actionable=20 > > discuss position: > >=20 > > Based on GEN-ART review responses, it appears this statement=20 > > in the DIAMETER base spec: > >=20 > > "Diameter is not intended as a general purpose protocol, and > > allocations SHOULD NOT be made for purposes unrelated to > > authentication, authorization or accounting." > >=20 > > is spurious and not being followed. If we're not going to=20 > > follow this rule (which is fine if there's rough consensus=20 > > not to follow it), I believe it's important that it be=20 > > documented why we're not following the rule (a "SHOULD NOT"=20 > > requires justification). Various approaches I find acceptable are: > > 1. The document approval text includes reasoning for=20 > > ignoring SHOULD NOT 2. An update to the document text=20 > > includes reasoning for ignoring > > SHOULD NOT > > 3. Hold this until a small RFC is published that updates 3588 to > > change or remove the SHOULD NOT restriction. > >=20 > >=20 > >=20 ------_=_NextPart_001_01C93AD7.6EA58209 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://www.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C93AD7.6EA58209-- From dime-bounces@ietf.org Fri Oct 31 03:40:54 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6133A6BBB; Fri, 31 Oct 2008 03:40:54 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BBD3A6BBB for ; Fri, 31 Oct 2008 03:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.303 X-Spam-Level: X-Spam-Status: No, score=-5.303 tagged_above=-999 required=5 tests=[AWL=1.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIyecOa1JTDw for ; Fri, 31 Oct 2008 03:40:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 1FF693A67E1 for ; Fri, 31 Oct 2008 03:40:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9VAei08002977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 31 Oct 2008 11:40:44 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9VAeg2T011358 for ; Fri, 31 Oct 2008 11:40:44 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 11:40:40 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 11:40:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 31 Oct 2008 12:40:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: M-bit - draft-ietf-dime-rfc3588bis-12.txt Thread-Index: Ack7RRxgWwmIGdXNScqMMhODCtsVhQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 31 Oct 2008 10:40:39.0373 (UTC) FILETIME=[1DB197D0:01C93B45] Subject: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Section 4.1. http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt " The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. " I suggest to re-write this to: " The 'M' Bit, known as the Mandatory bit, indicates whether a receiver MUST understand the respective AVP. " Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 31 03:47:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D643A6B8A; Fri, 31 Oct 2008 03:47:01 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D293A6B75 for ; Fri, 31 Oct 2008 03:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUKO5dArgSYX for ; Fri, 31 Oct 2008 03:46:59 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id BB96B28C18D for ; Fri, 31 Oct 2008 03:45:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id D7DAA9000C; Fri, 31 Oct 2008 05:45:31 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12910-08; Fri, 31 Oct 2008 05:45:30 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Fri, 31 Oct 2008 05:45:30 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 06:45:30 -0400 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 16:15:25 +0530 From: Sarkar Biplab To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: References: Date: Fri, 31 Oct 2008 16:15:23 +0530 Message-Id: <1225449923.9693.2.camel@INDBNG1172.bng.ind.starentnetworks.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 31 Oct 2008 10:45:25.0160 (UTC) FILETIME=[C8093A80:01C93B45] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: dime@ietf.org Subject: Re: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1764180031==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1764180031== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9OTN3aUpiqw8q5GRVszV" --=-9OTN3aUpiqw8q5GRVszV Content-Type: multipart/alternative; boundary="=-WPtvFsNOD6+JRboVBUgt" --=-WPtvFsNOD6+JRboVBUgt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello Hannes, When you said "receiver MUST understand the respective AVP", do you mean the receiver must interpret the meaning of the AVP and not to parse and discard it? Thanks Biplab On Fri, 2008-10-31 at 12:40 +0200, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Section 4.1.=20 >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt >=20 > " > The 'M' Bit, known as the Mandatory bit, indicates whether support > of the AVP is required. > " >=20 > I suggest to re-write this to: >=20 > " > The 'M' Bit, known as the Mandatory bit, indicates whether a receiver > MUST understand the respective AVP. > " >=20 > Ciao > Hannes > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=-WPtvFsNOD6+JRboVBUgt Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Hannes,

When you said "receiver MUST understand the respective AVP", do y= ou mean the receiver must interpret the meaning of the AVP and not to parse= and discard it?

Thanks
Biplab

On Fri, 2008-10-31 at 12:40 +0200, Tschofenig, Hannes (NSN - FI/Espoo) wrot= e: 
Section 4.1.=20

http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.tx=
t

"
The 'M' Bit, known as the Mandatory bit, indicates whether support
      of the AVP is required.
"

I suggest to re-write this to:

"
The 'M' Bit, known as the Mandatory bit, indicates whether a receiver
MUST understand the respective AVP.
"

Ciao
Hannes
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org=
/mailman/listinfo/dime
--=-WPtvFsNOD6+JRboVBUgt-- --=-9OTN3aUpiqw8q5GRVszV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJCuHD3rQBTW1UPu4RAsCSAKCCBtb/r+uaTGKRvf8kI6QV9/Ks/gCg1TtK a2QSrxEs0CgAvhkCSvpm88o= =r/zT -----END PGP SIGNATURE----- --=-9OTN3aUpiqw8q5GRVszV-- --===============1764180031== 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://www.ietf.org/mailman/listinfo/dime --===============1764180031==-- From dime-bounces@ietf.org Fri Oct 31 04:11:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D45E28C37E; Fri, 31 Oct 2008 04:11:14 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64F428C0E7 for ; Fri, 31 Oct 2008 04:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JvSqJ2l41Iq for ; Fri, 31 Oct 2008 04:11:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id E29E43A6B75 for ; Fri, 31 Oct 2008 04:11:10 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9VBB7BH013895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 31 Oct 2008 12:11:07 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9VBB61j007140; Fri, 31 Oct 2008 12:11:07 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 12:11:06 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 12:11:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 31 Oct 2008 13:11:11 +0200 Message-ID: In-Reply-To: <1225449923.9693.2.camel@INDBNG1172.bng.ind.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.txt Thread-Index: Ack7RdgHRxrAjJfxSaODS9NG31RnEgAA1yiQ References: <1225449923.9693.2.camel@INDBNG1172.bng.ind.starentnetworks.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 31 Oct 2008 11:11:05.0291 (UTC) FILETIME=[5E0691B0:01C93B49] Cc: dime@ietf.org Subject: Re: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Biplab I should have been more precise: "... MUST parse and understand the semantic of the AVP including its content". Is that better? Ciao Hannes Hello Hannes, When you said "receiver MUST understand the respective AVP", do you mean the receiver must interpret the meaning of the AVP and not to parse and discard it? Thanks Biplab On Fri, 2008-10-31 at 12:40 +0200, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Section 4.1. http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt " The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. " I suggest to re-write this to: " The 'M' Bit, known as the Mandatory bit, indicates whether a receiver MUST understand the respective AVP. " Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 31 04:13:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A833A683A; Fri, 31 Oct 2008 04:13:46 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C4D3A683A for ; Fri, 31 Oct 2008 04:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.321 X-Spam-Level: X-Spam-Status: No, score=-5.321 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1asMZb4Nkob for ; Fri, 31 Oct 2008 04:13:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 34CE73A682B for ; Fri, 31 Oct 2008 04:13:44 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m9VBDfXc022585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 31 Oct 2008 12:13:41 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m9VBDbHh001317 for ; Fri, 31 Oct 2008 12:13:41 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 12:13:37 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 12:13:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 31 Oct 2008 13:13:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terms in draft-ietf-dime-rfc3588bis-12.txt Thread-Index: Ack7SbuA3KQjwSzARti6PTwYi6p0AQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 31 Oct 2008 11:13:36.0363 (UTC) FILETIME=[B81253B0:01C93B49] Subject: [Dime] Terms in draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I think we should add the terms "Mandatory AVP" and "Required AVP" to the terminology section of the document. Mandatory AVP: An AVP that has the M-bit set. Required AVP: An AVP that must be included into a Command according to the ABNF. We do state that in the document somewhere but we should also include it into an earlier section. Useful? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 31 04:30:15 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C4C3A6B75; Fri, 31 Oct 2008 04:30:15 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6563A6AC0 for ; Fri, 31 Oct 2008 04:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iAGpKJ2uqPY for ; Fri, 31 Oct 2008 04:30:13 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id BC3E73A6B75 for ; Fri, 31 Oct 2008 04:30:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 3B20190019; Fri, 31 Oct 2008 06:30:09 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14838-01; Fri, 31 Oct 2008 06:30:07 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Fri, 31 Oct 2008 06:30:07 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Oct 2008 07:30:07 -0400 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 17:00:02 +0530 From: Sarkar Biplab To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: References: <1225449923.9693.2.camel@INDBNG1172.bng.ind.starentnetworks.com> Date: Fri, 31 Oct 2008 17:00:01 +0530 Message-Id: <1225452601.9693.9.camel@INDBNG1172.bng.ind.starentnetworks.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-OriginalArrivalTime: 31 Oct 2008 11:30:02.0132 (UTC) FILETIME=[03A2BD40:01C93B4C] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: dime@ietf.org Subject: Re: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1713973909==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1713973909== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NXPRkKmdsx7hFv/XrekF" --=-NXPRkKmdsx7hFv/XrekF Content-Type: multipart/alternative; boundary="=-RuXRqkge8WVvFZxWlM/O" --=-RuXRqkge8WVvFZxWlM/O Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Hannes The modification sounds better indeed. Thanks Biplab On Fri, 2008-10-31 at 13:11 +0200, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Biplab=20 >=20 > I should have been more precise: "... MUST parse and understand the > semantic of the AVP including its content".=20 >=20 > Is that better?=20 >=20 > Ciao > Hannes >=20 >=20 > Hello Hannes, > =09 > When you said "receiver MUST understand the respective AVP", do > you mean the receiver must interpret the meaning of the AVP and not to > parse and discard it? > =09 > Thanks > Biplab > =09 > =09 > =09 >=20 > On Fri, 2008-10-31 at 12:40 +0200, Tschofenig, Hannes (NSN - > FI/Espoo) wrote:=20 >=20 > Section 4.1.=20 > =09 > =09 > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt > =09 > " > The 'M' Bit, known as the Mandatory bit, indicates > whether support > of the AVP is required. > " > =09 > I suggest to re-write this to: > =09 > " > The 'M' Bit, known as the Mandatory bit, indicates > whether a receiver > MUST understand the respective AVP. > " > =09 > Ciao > Hannes > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =09 >=20 --=-RuXRqkge8WVvFZxWlM/O Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Hannes

The modification sounds better indeed.

Thanks
Biplab

On Fri, 2008-10-31 at 13:11 +0200, Tschofenig, Hannes (NSN - FI/Espoo) wrot= e: 
Hi Biplab=20

I should have been more precise: "... MUST parse and understand the
semantic of the AVP including its content".=20

Is that better?=20

Ciao
Hannes


	Hello Hannes,
=09
	When you said "receiver MUST understand the respective AVP", do
you mean the receiver must interpret the meaning of the AVP and not to
parse and discard it?
=09
	Thanks
	Biplab
=09
=09
	=09

	On Fri, 2008-10-31 at 12:40 +0200, Tschofenig, Hannes (NSN -
FI/Espoo) wrote:=20

		Section 4.1.=20
	=09
=09
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.tx=
t
	=09
		"
		The 'M' Bit, known as the Mandatory bit, indicates
whether support
		      of the AVP is required.
		"
	=09
		I suggest to re-write this to:
	=09
		"
		The 'M' Bit, known as the Mandatory bit, indicates
whether a receiver
		MUST understand the respective AVP.
		"
	=09
		Ciao
		Hannes
		_______________________________________________
		DiME mailing list
		DiME@ietf.org
		https://www.ietf.o=
rg/mailman/listinfo/dime
	=09
--=-RuXRqkge8WVvFZxWlM/O-- --=-NXPRkKmdsx7hFv/XrekF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJCuw53rQBTW1UPu4RAlAQAKDKq4cH3EiNV+5blKAjkr1xr7GXCgCfcH35 VisscELF67QBZpZj30JTnX0= =0i8K -----END PGP SIGNATURE----- --=-NXPRkKmdsx7hFv/XrekF-- --===============1713973909== 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://www.ietf.org/mailman/listinfo/dime --===============1713973909==-- From dime-bounces@ietf.org Fri Oct 31 07:21:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CC13A6A20; Fri, 31 Oct 2008 07:21:18 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A3D3A6A20 for ; Fri, 31 Oct 2008 07:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvKcZ3OS-GIk for ; Fri, 31 Oct 2008 07:21:16 -0700 (PDT) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 4B6E23A6A15 for ; Fri, 31 Oct 2008 07:21:16 -0700 (PDT) Received: from [127.0.0.1] (ns.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m9VELCbe074459; Fri, 31 Oct 2008 09:21:12 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <490B149E.60600@tari.toshiba.com> Date: Fri, 31 Oct 2008 10:22:22 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: bsarkar@starentnetworks.com References: <1225449923.9693.2.camel@INDBNG1172.bng.ind.starentnetworks.com> <1225452601.9693.9.camel@INDBNG1172.bng.ind.starentnetworks.com> In-Reply-To: <1225452601.9693.9.camel@INDBNG1172.bng.ind.starentnetworks.com> Cc: dime@ietf.org Subject: Re: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Modifications will be added to *-13. Hopefully I generate new draft by this weekend. > Hi Hannes > > The modification sounds better indeed. > > Thanks > Biplab > > > On Fri, 2008-10-31 at 13:11 +0200, Tschofenig, Hannes (NSN - FI/Espoo) > wrote: > > >> Hi Biplab >> >> I should have been more precise: "... MUST parse and understand the >> semantic of the AVP including its content". >> >> Is that better? >> >> Ciao >> Hannes >> >> >> Hello Hannes, >> >> When you said "receiver MUST understand the respective AVP", do >> you mean the receiver must interpret the meaning of the AVP and not to >> parse and discard it? >> >> Thanks >> Biplab >> >> >> >> >> On Fri, 2008-10-31 at 12:40 +0200, Tschofenig, Hannes (NSN - >> FI/Espoo) wrote: >> >> Section 4.1. >> >> >> http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-12.txt >> >> " >> The 'M' Bit, known as the Mandatory bit, indicates >> whether support >> of the AVP is required. >> " >> >> I suggest to re-write this to: >> >> " >> The 'M' Bit, known as the Mandatory bit, indicates >> whether a receiver >> MUST understand the respective AVP. >> " >> >> Ciao >> Hannes >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 31 23:15:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446A53A6B8A; Fri, 31 Oct 2008 23:15:17 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED713A67A1 for ; Fri, 31 Oct 2008 21:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 871k1AVUsFKC for ; Fri, 31 Oct 2008 21:22:46 -0700 (PDT) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 1CA3B3A681A for ; Fri, 31 Oct 2008 21:22:45 -0700 (PDT) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 6A5941831CF15; Sat, 1 Nov 2008 05:22:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 5EDAC1C135F62; Sat, 1 Nov 2008 05:22:42 +0100 (CET) Date: Sat, 1 Nov 2008 05:22:42 +0100 (CET) From: Jan Engelhardt To: dave@frascone.com Message-ID: User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: [Dime] diameter-api draft comparison X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I have monitored this list before but I did not quite see a reason for taking part until I finished our implementation of Diameter and WebAuth. I see that my earlier disagreement mail about draft-ietf-dime-diameter-api-06 from July has not been forwarded here; but it probably suffices to say that I am at a disagreement with that draft, both from a technical standpoint, and not less from a cosmetical one. While camelcase is something one can debate infinitely, I have to condemn the silly use of typedefs and long names. Some specified functions like AAAValueFromAVPCode do not make any sense at all. Our API, which actually goes in line with an actual implementation around it, is described in its Developers Guide; a web copy is at http://circum.sf.net/circum_devguide.pdf . I especially encourage the draft's authors to compare. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 31 23:15:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7072F3A6C14; Fri, 31 Oct 2008 23:15:20 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77CE3A69A0 for ; Fri, 31 Oct 2008 21:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ylg8LWwfZbEn for ; Fri, 31 Oct 2008 21:23:13 -0700 (PDT) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by core3.amsl.com (Postfix) with ESMTP id 13E663A681A for ; Fri, 31 Oct 2008 21:23:13 -0700 (PDT) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id BABA91831CF15; Sat, 1 Nov 2008 05:23:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id B26AA1C135F62; Sat, 1 Nov 2008 05:23:10 +0100 (CET) Date: Sat, 1 Nov 2008 05:23:10 +0100 (CET) From: Jan Engelhardt To: "Tschofenig, Hannes (NSN - FI/Espoo)" Message-ID: User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Cc: dime@ietf.org Subject: Re: [Dime] M-bit - draft-ietf-dime-rfc3588bis-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org >I should have been more precise: "... MUST parse and understand the >semantic of the AVP including its content". I would not call it Mandatory AVP then, because mandatory is close to required, if you look that up in a thesaurus, but required-to-be-present is different from required-to-be-understood. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime