From gwz@net-zen.net Sat Jan 1 19:12:04 2011 Return-Path: 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 E9DEF3A697C for ; Sat, 1 Jan 2011 19:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.421 X-Spam-Level: X-Spam-Status: No, score=-97.421 tagged_above=-999 required=5 tests=[AWL=-5.178, BAYES_00=-2.599, FM_VIAGRA_SPAM1114=10.357, USER_IN_WHITELIST=-100] 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 582SyVBTv4cv for ; Sat, 1 Jan 2011 19:12:03 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 0CF4E3A6954 for ; Sat, 1 Jan 2011 19:11:57 -0800 (PST) Received: (qmail 22673 invoked from network); 2 Jan 2011 03:14:03 -0000 Received: from unknown (115.87.110.4) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 02 Jan 2011 03:14:02 -0000 From: "Glen Zorn" To: "'Jouni Korhonen'" , References: In-Reply-To: Date: Sun, 2 Jan 2011 10:13:35 +0700 Organization: Network Zen Message-ID: <000001cbaa2b$0d9eaed0$28dc0c70$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuVFXjadROIVMrsTx2uGYudTJLh5QNdAU8XAV68vCEAWG6mgA== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WGLC for https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/? 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: , X-List-Received-Date: Sun, 02 Jan 2011 03:12:05 -0000 Jouni Korhonen [mailto:jouni.korhonen@nsn.com] writes: > Hello, > > I did a "chairs'" review of draft-ietf-dime-rfc4005bis-02. What is that? I wasn't aware that the technical (or editorial) opinions of WG Chairs held any more (or less) weight than anyone else's, at least not by virtue of their position). > Here are my > comments that should be addressed. Most of them are purely editorial, > some > might need a bit more fiddling around the I-D. > > ---- > > Around introduction Section 1 > o I would appreciate a short section describing the major changes > between > RFC4005 to RFC4005bis, and what was the reason for such change. In a > similar fashion what RFC3588bis has done. I would appreciate it if that section of RFC3588bis were to be deleted, since it's pretty much useless to people already familiar with RFC 3588 and not detailed enough for those who aren't. > > Section 1.1 > o The terminology/agronym list is not complete. e.g. DNIS, LCP, MTU, > FQDN, PAC, LAC, DSCP, OLI, PRI, ISP, TLS are missing. DNIS is expanded on first usage and used only twice; much the same thing is true for PRI, ISP and OLI. MTU, and TLS are on the RFC Editor's list of "well-known abbreviations" (http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt). > > Section 1.3 > o RFC 3588 still mentioned and should be replaced with RFC3588bis > reference. Fine. > > Section 2.3 > o LCP is never expanded Fine. > > Section 4.1.1 > o You might consider lifting this section up one level as it is alone > under third level. Maybe just replacing Section 4.1 with Section > 4.1.1 > content? > o Similar note on Sections 4.4.10.6.1, 4.4.11.4.1 Why destroy the overall organization of the section for the sake of tidiness? > o DSCP is not expanded on the first use. It's been added to the list in Section 1.1 > > Sections 4.2.1, 4.5, 4.6 > o These sections describe flag rules and encryption requirements for > AVPs. > Since the rest of the I-D references to RFC3588bis, which changed the > use > of AVP flag rule presentations (due to lack of end-to-end security > specification), the RFC4005bis should follow that. This basically > means > removing MAY, SHLD NOT, Encr columns. OK > > Section 4.3.1 > o References missing for IPsec and TLS. OK. > o TLS is not expanded on the first use. See above. > > Section 4.3.2 > o Expand ARAP on the first use. ARAP is listed in Section 1.1 > > Section 4.4.10.5.7 > o IPv6 addresses here should follow the RFC5156 documentation prefix. OK > > Section 4.4.10.8.1 > o s/[ARAP]/(ARAP) [ARAP] Can't find the search string. > > Section 4.4.11.5.1 > o Is it useful still to mention Vax & Alpha clusters? Maybe not; OTOH, is it useful to have a set of AVPs dedicated to LAT? > > Section 4.5.8 > o PAC and LAC are never expanded OK > > Section 4.5.9 > o s/decidewitch/decide witch Fixed. > > Section 5 > o Could we just reference to RFC3588bis Section 10 on the definition > of occurrence symbols? Just to keep them in one place. ??? > > Section 6 > o Since no new IANA considerations are really added this should be > made clear in the introductory text.. just to make IANA folks life > easier. Actually, this section has many of the same problems that 3588 bis has; probably needs to be largely deleted. > > Section 6.5 > o This will cause a textual update in IANA registry policy, right? I don't know what you mean. > (semantically IETF review and older IETF consensus are equal). > > > Note that the I-D depends on the progress of the RFC3588bis due a > normative > reference to the RFC3588bis.. That depends upon what you mean by "depends" ;-). 4005bis probably can't be published as an RFC before 3588bis is, but I don't know why it couldn't be sent to the RFC Editor first. ... From Internet-Drafts@ietf.org Sun Jan 2 01:15:03 2011 Return-Path: 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 3D1713A6990; Sun, 2 Jan 2011 01:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 TFIGrh9reLWD; Sun, 2 Jan 2011 01:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A3A3A698E; Sun, 2 Jan 2011 01:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110102091501.7268.52246.idtracker@localhost> Date: Sun, 02 Jan 2011 01:15:01 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc4005bis-03.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: , X-List-Received-Date: Sun, 02 Jan 2011 09:15:03 -0000 --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 Network Access Server Application Author(s) : G. Zorn Filename : draft-ietf-dime-rfc4005bis-03.txt Pages : 65 Date : 2011-01-02 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-03.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-rfc4005bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-02010114.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Sun Jan 2 12:21:50 2011 Return-Path: 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 73B3E3A6920 for ; Sun, 2 Jan 2011 12:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, 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 h-pzpY2y1Hl7 for ; Sun, 2 Jan 2011 12:21:49 -0800 (PST) Received: from vs10.mail.saunalahti.fi (vs10.mail.saunalahti.fi [195.197.172.105]) by core3.amsl.com (Postfix) with ESMTP id C1EBA3A691D for ; Sun, 2 Jan 2011 12:21:48 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs10.mail.saunalahti.fi (Postfix) with SMTP id 9EA311A407D; Sun, 2 Jan 2011 22:23:54 +0200 (EET) Received: from vs10.mail.saunalahti.fi ([127.0.0.1]) by vs10.mail.saunalahti.fi ([195.197.172.105]) with SMTP (gateway) id A03D739B286; Sun, 02 Jan 2011 22:23:54 +0200 Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs10.mail.saunalahti.fi (Postfix) with ESMTP id 8E9701A407D; Sun, 2 Jan 2011 22:23:54 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id C0AE613968D; Sun, 2 Jan 2011 22:23:49 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <000001cbaa2b$0d9eaed0$28dc0c70$@net> Date: Sun, 2 Jan 2011 22:23:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000001cbaa2b$0d9eaed0$28dc0c70$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: 'Jouni Korhonen' , dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] WGLC for https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/? 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: , X-List-Received-Date: Sun, 02 Jan 2011 20:21:50 -0000 Hello, Thanks for a quick update! On Jan 2, 2011, at 5:13 AM, Glen Zorn wrote: > Jouni Korhonen [mailto:jouni.korhonen@nsn.com] writes: >=20 >> Hello, >>=20 >> I did a "chairs'" review of draft-ietf-dime-rfc4005bis-02.=20 >=20 > What is that? I wasn't aware that the technical (or editorial) = opinions of > WG Chairs held any more (or less) weight than anyone else's, at least = not by > virtue of their position). >=20 >> Here are my >> comments that should be addressed. Most of them are purely editorial, >> some >> might need a bit more fiddling around the I-D. >>=20 >> ---- >>=20 >> Around introduction Section 1 >> o I would appreciate a short section describing the major changes >> between >> RFC4005 to RFC4005bis, and what was the reason for such change. In = a >> similar fashion what RFC3588bis has done. >=20 > I would appreciate it if that section of RFC3588bis were to be = deleted, > since it's pretty much useless to people already familiar with RFC = 3588 and > not detailed enough for those who aren't. I still find such rundown useful and I consider myself rather familiar = with e.g. 3588. A quick list of what and why. That helps when you need = to revisit stuff that happened in past. >=20 >>=20 >> Section 1.1 >> o The terminology/agronym list is not complete. e.g. DNIS, LCP, MTU, >> FQDN, PAC, LAC, DSCP, OLI, PRI, ISP, TLS are missing. >=20 > DNIS is expanded on first usage and used only twice; much the same = thing is > true for PRI, ISP and OLI. MTU, and TLS are on the RFC Editor's list = of > "well-known abbreviations" > (http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt). Ok for MTU & TLS. >=20 >>=20 >> Section 1.3 >> o RFC 3588 still mentioned and should be replaced with RFC3588bis >> reference. >=20 > Fine. >=20 >>=20 >> Section 2.3 >> o LCP is never expanded >=20 > Fine. >=20 >>=20 >> Section 4.1.1 >> o You might consider lifting this section up one level as it is alone >> under third level. Maybe just replacing Section 4.1 with Section >> 4.1.1 >> content? >> o Similar note on Sections 4.4.10.6.1, 4.4.11.4.1 >=20 > Why destroy the overall organization of the section for the sake of > tidiness? "You might consider".. And I see you did not, which is fine. It is my personal opinion/matter of taste not having lonely sections at = a level deeper than 1. >=20 >=20 >> o DSCP is not expanded on the first use. >=20 > It's been added to the list in Section 1.1 >=20 >>=20 >> Sections 4.2.1, 4.5, 4.6 >> o These sections describe flag rules and encryption requirements for >> AVPs. >> Since the rest of the I-D references to RFC3588bis, which changed = the >> use >> of AVP flag rule presentations (due to lack of end-to-end security >> specification), the RFC4005bis should follow that. This basically >> means >> removing MAY, SHLD NOT, Encr columns. >=20 > OK >=20 >>=20 >> Section 4.3.1 >> o References missing for IPsec and TLS. >=20 > OK. >=20 >> o TLS is not expanded on the first use. >=20 > See above. >=20 >>=20 >> Section 4.3.2 >> o Expand ARAP on the first use. >=20 > ARAP is listed in Section 1.1 >=20 >>=20 >> Section 4.4.10.5.7 >> o IPv6 addresses here should follow the RFC5156 documentation prefix. >=20 > OK >=20 >>=20 >> Section 4.4.10.8.1 >> o s/[ARAP]/(ARAP) [ARAP] >=20 > Can't find the search string. My typo. Meant 4.4.10.8. There "..via the AppleTalk Remote Access = Protocol [ARAP] They.." could be replaced with "..via the AppleTalk = Remote Access Protocol (ARAP) [ARAP]. They.." Since both ARAP acronym = and [ARAP] reference has already been introduced in Section 1.1 those = may not be needed to done again here. Anyway, the full stop is missing = before "They". >=20 >>=20 >> Section 4.4.11.5.1 >> o Is it useful still to mention Vax & Alpha clusters? >=20 > Maybe not; OTOH, is it useful to have a set of AVPs dedicated to LAT? >=20 >>=20 >> Section 4.5.8 >> o PAC and LAC are never expanded >=20 > OK >=20 >>=20 >> Section 4.5.9 >> o s/decidewitch/decide witch >=20 > Fixed. >=20 >>=20 >> Section 5 >> o Could we just reference to RFC3588bis Section 10 on the definition >> of occurrence symbols? Just to keep them in one place. >=20 > ??? Basically I meant this: Old text: The following tables present the AVPs used by NAS applications in NAS messages and specify in which Diameter messages they may or may not be present. Messages and AVPs defined in the base Diameter protocol [I-D.ietf-dime-rfc3588bis] are not described in this document. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. The tables use the following symbols: 0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in the message. 0-1 Zero or one instance of the AVP MAY be present in the message. 1 Exactly one instance of the AVP MUST be present in the message.=20 New text: The following tables present the AVPs used by NAS applications in NAS messages and specify in which Diameter messages they may or may not be present. Messages and AVPs defined in the base Diameter protocol [I-D.ietf-dime-rfc3588bis] are not described in this document. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. The tables use the multiplicity symbols defined in Section 10 of [I-D.ietf-dime-rfc3588bis]. >=20 >>=20 >> Section 6 >> o Since no new IANA considerations are really added this should be >> made clear in the introductory text.. just to make IANA folks life >> easier. >=20 > Actually, this section has many of the same problems that 3588 bis = has; > probably needs to be largely deleted. The new IANA considerations section looks much better now ;) >=20 >>=20 >> Section 6.5 >> o This will cause a textual update in IANA registry policy, right? >=20 > I don't know what you mean. Does not matter anymore with the new polished IANA considerations = section. >=20 >> (semantically IETF review and older IETF consensus are equal). >>=20 >>=20 >> Note that the I-D depends on the progress of the RFC3588bis due a >> normative >> reference to the RFC3588bis.. >=20 > That depends upon what you mean by "depends" ;-). 4005bis probably = can't be I was just reminding folks that 4005bis depends on 3588bis and won't get = published before 3588bis gets through the pipe. Also non-regular IETFers = read the mailing list are not always clear on these dependencies. - Jouni > published as an RFC before 3588bis is, but I don't know why it = couldn't be > sent to the RFC Editor first. >=20 > ... >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Mon Jan 3 01:00:30 2011 Return-Path: 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 7B4883A69C6 for ; Mon, 3 Jan 2011 01:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 m6PPEzSTpGq6 for ; Mon, 3 Jan 2011 01:00:29 -0800 (PST) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id 5F8D33A69C2 for ; Mon, 3 Jan 2011 01:00:29 -0800 (PST) Received: (qmail 16780 invoked from network); 3 Jan 2011 09:02:35 -0000 Received: from unknown (124.122.114.51) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 03 Jan 2011 09:02:34 -0000 From: "Glen Zorn" To: "'Jouni'" References: <000001cbaa2b$0d9eaed0$28dc0c70$@net> In-Reply-To: Date: Mon, 3 Jan 2011 16:02:01 +0700 Organization: Network Zen Message-ID: <001201cbab24$e4d6dd10$ae849730$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuquv52s1mF8c2hRG6RNUjTVC9MHQAZ7MgQ Content-Language: en-us Cc: 'Jouni Korhonen' , dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] WGLC for https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/? 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: , X-List-Received-Date: Mon, 03 Jan 2011 09:00:30 -0000 Jouni [mailto:jouni.nospam@gmail.com] writes: ... > >> Around introduction Section 1 > >> o I would appreciate a short section describing the major changes > >> between > >> RFC4005 to RFC4005bis, and what was the reason for such change. In > a > >> similar fashion what RFC3588bis has done. > > > > I would appreciate it if that section of RFC3588bis were to be > deleted, > > since it's pretty much useless to people already familiar with RFC > 3588 and > > not detailed enough for those who aren't. > > I still find such rundown useful and I consider myself rather familiar > with e.g. 3588. A quick list of what and why. That helps when you need > to revisit stuff that happened in past. I thought that's what diff, list archives & meeting minutes were for... ... > >> Section 4.1.1 > >> o You might consider lifting this section up one level as it is alone > >> under third level. Maybe just replacing Section 4.1 with Section > >> 4.1.1 > >> content? > >> o Similar note on Sections 4.4.10.6.1, 4.4.11.4.1 > > > > Why destroy the overall organization of the section for the sake of > > tidiness? > > "You might consider".. And I see you did not, which is fine. Oh no, I _considered_ it; I just didn't _do_ it ;-) ... > >> Section 4.4.10.8.1 > >> o s/[ARAP]/(ARAP) [ARAP] > > > > Can't find the search string. > > My typo. Meant 4.4.10.8. There "..via the AppleTalk Remote Access > Protocol [ARAP] They.." could be replaced with "..via the AppleTalk > Remote Access Protocol (ARAP) [ARAP]. They.." Since both ARAP acronym > and [ARAP] reference has already been introduced in Section 1.1 those > may not be needed to done again here. Anyway, the full stop is missing > before "They". Fixed, thanks. ... > >> > >> Section 5 > >> o Could we just reference to RFC3588bis Section 10 on the definition > >> of occurrence symbols? Just to keep them in one place. > > > > ??? > > Basically I meant this: > > Old text: > > The following tables present the AVPs used by NAS applications in NAS > messages and specify in which Diameter messages they may or may not > be present. Messages and AVPs defined in the base Diameter protocol > [I-D.ietf-dime-rfc3588bis] are not described in this document. Note > that AVPs that can only be present within a Grouped AVP are not > represented in this table. > > The tables use the following symbols: > > 0 The AVP MUST NOT be present in the message. > 0+ Zero or more instances of the AVP MAY be present in the > message. > 0-1 Zero or one instance of the AVP MAY be present in the > message. > 1 Exactly one instance of the AVP MUST be present in the > message. > > New text: > > The following tables present the AVPs used by NAS applications in NAS > messages and specify in which Diameter messages they may or may not > be present. Messages and AVPs defined in the base Diameter protocol > [I-D.ietf-dime-rfc3588bis] are not described in this document. Note > that AVPs that can only be present within a Grouped AVP are not > represented in this table. > > The tables use the multiplicity symbols defined in Section 10 of > [I-D.ietf-dime-rfc3588bis]. Well OK, but it seems a little late for that since essentially the same text occurs in RFC 4072, RFC 5778, RFC 4004...well, almost any document that defines new Diameter AVPs... > > > > >> > >> Section 6 > >> o Since no new IANA considerations are really added this should be > >> made clear in the introductory text.. just to make IANA folks life > >> easier. > > > > Actually, this section has many of the same problems that 3588 bis > has; > > probably needs to be largely deleted. > > The new IANA considerations section looks much better now ;) Thank you ;-) > > > > >> > >> Section 6.5 > >> o This will cause a textual update in IANA registry policy, right? > > > > I don't know what you mean. > > Does not matter anymore with the new polished IANA considerations > section. OK. ... > >> Note that the I-D depends on the progress of the RFC3588bis due a > >> normative > >> reference to the RFC3588bis.. > > > > That depends upon what you mean by "depends" ;-). 4005bis probably > can't be > > I was just reminding folks that 4005bis depends on 3588bis and won't get > published before 3588bis gets through the pipe. Also non-regular IETFers > read the mailing list are not always clear on these dependencies. I see. > > - Jouni > > > > > published as an RFC before 3588bis is, but I don't know why it > couldn't be > > sent to the RFC Editor first. ... From Internet-Drafts@ietf.org Thu Jan 6 11:15:04 2011 Return-Path: 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 07C5F3A6F30; Thu, 6 Jan 2011 11:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 72ZNOB6BoPne; Thu, 6 Jan 2011 11:15:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17EEE3A6F64; Thu, 6 Jan 2011 11:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110106191502.10151.87573.idtracker@localhost> Date: Thu, 06 Jan 2011 11:15:02 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-04.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: , X-List-Received-Date: Thu, 06 Jan 2011 19:15:04 -0000 --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 Extended NAPTR Author(s) : M. Jones, et al. Filename : draft-ietf-dime-extended-naptr-04.txt Pages : 12 Date : 2011-01-06 The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanism do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document describes an improvement using an extended format for the Straightfoward-NAPTR (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-04.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-extended-naptr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-06110952.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Fri Jan 7 01:30:03 2011 Return-Path: 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 08ADA3A67F6; Fri, 7 Jan 2011 01:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CymTornTxbqy; Fri, 7 Jan 2011 01:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37C03A67EE; Fri, 7 Jan 2011 01:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110107093001.8897.17998.idtracker@localhost> Date: Fri, 07 Jan 2011 01:30:01 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc4005bis-04.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: , X-List-Received-Date: Fri, 07 Jan 2011 09:30:03 -0000 --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 Network Access Server Application Author(s) : G. Zorn Filename : draft-ietf-dime-rfc4005bis-04.txt Pages : 65 Date : 2011-01-07 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-04.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-rfc4005bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07011840.I-D@ietf.org> --NextPart-- From mark@azu.ca Fri Jan 7 12:47:51 2011 Return-Path: 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 B68753A698A for ; Fri, 7 Jan 2011 12:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 z5f92K4+fFIw for ; Fri, 7 Jan 2011 12:47:50 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id CE33E3A68C5 for ; Fri, 7 Jan 2011 12:47:17 -0800 (PST) Received: by qwi2 with SMTP id 2so2437815qwi.31 for ; Fri, 07 Jan 2011 12:49:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.84.203 with SMTP id k11mr22233068qcl.281.1294433363832; Fri, 07 Jan 2011 12:49:23 -0800 (PST) Received: by 10.229.219.197 with HTTP; Fri, 7 Jan 2011 12:49:23 -0800 (PST) In-Reply-To: <20110106191502.10151.87573.idtracker@localhost> References: <20110106191502.10151.87573.idtracker@localhost> Date: Fri, 7 Jan 2011 15:49:23 -0500 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: multipart/alternative; boundary=0016364ef322d62fc5049947c05e Subject: Re: [Dime] I-D Action:draft-ietf-dime-extended-naptr-04.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: , X-List-Received-Date: Fri, 07 Jan 2011 20:47:51 -0000 --0016364ef322d62fc5049947c05e Content-Type: text/plain; charset=ISO-8859-1 This revision addresses the comments received from Itsuma Tanaka (issue #13), Avi Lior (issue #14) and Lionel Morand (issue #15) during WGLC. As the comments received were mainly editorial, I understood from the chairs at IETF#79 that they now would request a "mini-WGLC" asking if someone has concerns due to the changes. DIME chairs, Please can you do the necessary to kick off a "mini-WGLC" on this draft. Thanks Mark On Thu, Jan 6, 2011 at 2:15 PM, wrote: > 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 Extended NAPTR > Author(s) : M. Jones, et al. > Filename : draft-ietf-dime-extended-naptr-04.txt > Pages : 12 > Date : 2011-01-06 > > The Diameter base protocol specifies mechanisms whereby a given realm > may advertise Diameter nodes and the supported transport protocol. > However, these mechanism do not reveal the Diameter applications that > each node supports. A peer outside the realm would have to perform a > Diameter capability exchange with every node until it discovers one > that supports the required application. This document describes an > improvement using an extended format for the Straightfoward-NAPTR > (S-NAPTR) Application Service Tag that allows for discovery of the > supported applications without doing Diameter capability exchange > beforehand. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-04.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. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > --0016364ef322d62fc5049947c05e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This revision addresses the comments received from Itsuma Tanaka (issue #13= ), Avi Lior (issue #14) and Lionel Morand (issue #15) during WGLC. As the c= omments received were mainly editorial, I understood from the chairs at IET= F#79 that they now would request a "mini-WGLC" asking if someone = has concerns due to the changes.

DIME chairs, Please can you do the necessary to kick off a "mini-W= GLC" on this draft.

Thanks
Mark

On Thu, Jan 6, 2011 at 2:15 PM, <Internet-Drafts@ietf.org> wrote= :
A New Internet-Dr= aft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance and Extensions Workin= g Group of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Diameter Extended NAPTR
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Jones, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dime-extended-naptr-04= .txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-01-06

The Diameter base protocol specifies mechanisms whereby a given realm
may advertise Diameter nodes and the supported transport protocol.
However, these mechanism do not reveal the Diameter applications that
each node supports. =A0A peer outside the realm would have to perform a
Diameter capability exchange with every node until it discovers one
that supports the required application. =A0This document describes an
improvement using an extended format for the Straightfoward-NAPTR
(S-NAPTR) Application Service Tag that allows for discovery of the
supported applications without doing Diameter capability exchange
beforehand.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf= -dime-extended-naptr-04.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.


_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime


--0016364ef322d62fc5049947c05e-- From jouni.nospam@gmail.com Fri Jan 7 14:49:02 2011 Return-Path: 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 085573A6985 for ; Fri, 7 Jan 2011 14:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, 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 JONjUcRJB1+B for ; Fri, 7 Jan 2011 14:49:01 -0800 (PST) Received: from vs14.mail.saunalahti.fi (vs14.mail.saunalahti.fi [195.197.172.102]) by core3.amsl.com (Postfix) with ESMTP id 33F633A68C5 for ; Fri, 7 Jan 2011 14:49:01 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs14.mail.saunalahti.fi (Postfix) with SMTP id A8F0EA604A; Sat, 8 Jan 2011 00:51:06 +0200 (EET) Received: from vs14.mail.saunalahti.fi ([127.0.0.1]) by vs14.mail.saunalahti.fi ([195.197.172.102]) with SMTP (gateway) id A05E6FA6281; Sat, 08 Jan 2011 00:51:06 +0200 Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs14.mail.saunalahti.fi (Postfix) with ESMTP id 9CA99A604A; Sat, 8 Jan 2011 00:51:06 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 2EF901397CF; Sat, 8 Jan 2011 00:51:04 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Sat, 8 Jan 2011 00:51:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110106191502.10151.87573.idtracker@localhost> To: dime@ietf.org X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: dime-chairs@tools.ietf.org Subject: [Dime] WGLC for draft-ietf-dime-extended-naptr 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: , X-List-Received-Date: Fri, 07 Jan 2011 22:49:02 -0000 Folks, We will rerun a short WGLC for draft-ietf-dime-extended-naptr-04 since = there were some bigger restructuring on the document. The WGLC starts as = of today 8th Jan 2011 and ends 14th Jan 2011 23:59 CET+1. If you have = substantial technical comments, please post them to the list. Purely = editorial comments can be mailed directly to the authors. Silence will = be taken as acceptance. - Jouni (as a Dime co-chair) From gwz@net-zen.net Sat Jan 8 00:44:27 2011 Return-Path: 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 DCE9D3A698E for ; Sat, 8 Jan 2011 00:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cFrzNf-l7qok for ; Sat, 8 Jan 2011 00:44:27 -0800 (PST) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id 0BA993A6405 for ; Sat, 8 Jan 2011 00:44:26 -0800 (PST) Received: (qmail 13689 invoked from network); 8 Jan 2011 08:46:33 -0000 Received: from unknown (124.120.147.24) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 08 Jan 2011 08:46:32 -0000 From: "Glen Zorn" To: References: <20110106191502.10151.87573.idtracker@localhost> In-Reply-To: Date: Sat, 8 Jan 2011 15:46:10 +0700 Organization: Network Zen Message-ID: <002301cbaf10$81bee520$853caf60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuuvWEF9C7T0F+KTmSI6TPQoZTb2AAUXLpA Content-Language: en-us Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] WGLC for draft-ietf-dime-extended-naptr 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: , X-List-Received-Date: Sat, 08 Jan 2011 08:44:28 -0000 Would somebody tell me again why we're issuing an update for a document that will be obsolete very soon? This draft appears to be in some conflict w/rfc3588bis; in particular, both request that IANA register the same set of S-NAPTR Application Protocol Tags. This draft updates RFC 3588 but says nothing about 3588bis; 3588bis says nothing about this document. This seems to lead to a dead-end. This draft is considerably more detailed WRT S-NAPTR than 3588bis. Why? Hope this helps. ~gwz > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Jouni > Sent: Saturday, January 08, 2011 5:51 AM > To: dime@ietf.org > Cc: dime-chairs@tools.ietf.org > Subject: [Dime] WGLC for draft-ietf-dime-extended-naptr > > Folks, > > We will rerun a short WGLC for draft-ietf-dime-extended-naptr-04 since > there were some bigger restructuring on the document. The WGLC starts as > of today 8th Jan 2011 and ends 14th Jan 2011 23:59 CET+1. If you have > substantial technical comments, please post them to the list. Purely > editorial comments can be mailed directly to the authors. Silence will > be taken as acceptance. > > - Jouni (as a Dime co-chair) > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Sat Jan 8 00:57:02 2011 Return-Path: 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 A6AC03A69B4 for ; Sat, 8 Jan 2011 00:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uF1hxz3jQdPI for ; Sat, 8 Jan 2011 00:57:02 -0800 (PST) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by core3.amsl.com (Postfix) with SMTP id D04243A69B0 for ; Sat, 8 Jan 2011 00:57:01 -0800 (PST) Received: (qmail 31593 invoked from network); 8 Jan 2011 08:59:08 -0000 Received: from unknown (124.120.147.24) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 08 Jan 2011 08:59:08 -0000 From: "Glen Zorn" To: References: <20110106191502.10151.87573.idtracker@localhost> In-Reply-To: Date: Sat, 8 Jan 2011 15:58:45 +0700 Organization: Network Zen Message-ID: <002701cbaf12$43eabb00$cbc03100$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuuvWEF9C7T0F+KTmSI6TPQoZTb2AAU2wKg Content-Language: en-us Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] WGLC for draft-ietf-dime-extended-naptr 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: , X-List-Received-Date: Sat, 08 Jan 2011 08:57:02 -0000 Shouldn't the title actually be something like "Diameter S-NAPTR Usage"? Change the first page header to read Network Working Group M. Jones Internet-Draft Bridgewater Systems instead of Diameter Maintenance and M. Jones Extensions (DIME) Bridgewater Systems The abbreviated title ("dime-extended-naptr") is just silly (and not anything like an abbreviation). There is no Application Service Tag define for the Diameter Base Protocol in this draft (although there is in rfc388bis). Since The Diameter Base protocol includes rudimentary accounting functionality it doesn't seem completely unreasonable that Diameter Base might be used as a stand-alone app. Hope this helps. ~gwz > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Jouni > Sent: Saturday, January 08, 2011 5:51 AM > To: dime@ietf.org > Cc: dime-chairs@tools.ietf.org > Subject: [Dime] WGLC for draft-ietf-dime-extended-naptr > > Folks, > > We will rerun a short WGLC for draft-ietf-dime-extended-naptr-04 since > there were some bigger restructuring on the document. The WGLC starts as > of today 8th Jan 2011 and ends 14th Jan 2011 23:59 CET+1. If you have > substantial technical comments, please post them to the list. Purely > editorial comments can be mailed directly to the authors. Silence will > be taken as acceptance. > > - Jouni (as a Dime co-chair) > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Internet-Drafts@ietf.org Mon Jan 10 04:00:07 2011 Return-Path: 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 04D7928C10E; Mon, 10 Jan 2011 04:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 knZXnF1nXjnC; Mon, 10 Jan 2011 04:00:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262D73A696F; Mon, 10 Jan 2011 04:00:05 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110120005.3411.64119.idtracker@localhost> Date: Mon, 10 Jan 2011 04:00:05 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-nat-control-06.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: , X-List-Received-Date: Mon, 10 Jan 2011 12:00:07 -0000 --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 Network Address and Port Translation Control Application Author(s) : F. Brockners, et al. Filename : draft-ietf-dime-nat-control-06.txt Pages : 42 Date : 2011-01-10 This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to cope with IPv4-address space completion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-06.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-nat-control-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10035408.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Mon Jan 10 09:52:54 2011 Return-Path: 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 B56F43A67AB for ; Mon, 10 Jan 2011 09:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, 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 WsvQe0MMTAC5 for ; Mon, 10 Jan 2011 09:52:53 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 702723A6821 for ; Mon, 10 Jan 2011 09:52:53 -0800 (PST) Received: by bwz12 with SMTP id 12so19292089bwz.31 for ; Mon, 10 Jan 2011 09:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=eK6YCNqiRnQO8qOrE58NksmJinhYCGmMJO8XikxPXBM=; b=hqwHcXcQ8MXxbWEjCT9QIO9zR40Dc8avvxQv9fYcUN+464LLNe79Msg9eVovQCv7kY 5trV2S4d8iRgdC3r4dYHHnJ/UChzDts0gVTcUU7PqRu2L/fSJepMnFLgQWC8uiBRdCEJ SwDOghrE8KLkxVahntyX5AOszMtzIeJv9iAvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=B4Ov18NqM0QsIjRBUg6iZvcaFo3XvCox10B+Ro/FOlJ3PPVDO9t2xeY8XO6x+mVJsx gL1IxC4b21GVHwhXwSa8tkdJ71+4WacGF4+zdvmwNSz9GqktZ6lzggyWRXpCTRey5Hs1 uvdfLrxU8aRQcVmdd041AjNl7PMAqKXZpsFFM= Received: by 10.204.33.73 with SMTP id g9mr5550bkd.157.1294681889370; Mon, 10 Jan 2011 09:51:29 -0800 (PST) Received: from a88-114-69-119.elisa-laajakaista.fi (a88-114-69-119.elisa-laajakaista.fi [88.114.69.119]) by mx.google.com with ESMTPS id v1sm15828284bkt.5.2011.01.10.09.51.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 09:51:28 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 19:51:25 +0200 Message-Id: <15FD18E5-8D25-49CF-86E9-77669324F430@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] WGLC for draft-ietf-dime-rfc4005-bis 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: , X-List-Received-Date: Mon, 10 Jan 2011 17:52:54 -0000 Folks, This email starts two weeks WGLC for draft-ietf-dime-rfc4005-bis-04. The = WGLC starts as of today 10th Jan 2011 and ends 24th Jan 2011 23:59 = CET+1. If you have technical or editorial comments, please post them to the = list. Also enter your comments into the issue tracker (or ask a wg chair = to add them on your behalf). The one who entered the issue is also = responsible for eventually clearing it, once the issue is handled. Remember that a document to move forward, we require at least three = reviews (oneliners do not count..). - Jouni (as a Dime co-chair)= From mark@azu.ca Mon Jan 10 12:10:53 2011 Return-Path: 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 12B2128C0E5 for ; Mon, 10 Jan 2011 12:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 79m5WuVzagmI for ; Mon, 10 Jan 2011 12:10:48 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 096EF28C0F9 for ; Mon, 10 Jan 2011 12:10:46 -0800 (PST) Received: by qwi2 with SMTP id 2so4472163qwi.31 for ; Mon, 10 Jan 2011 12:13:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.85.207 with SMTP id p15mr2863516qcl.167.1294690380785; Mon, 10 Jan 2011 12:13:00 -0800 (PST) Received: by 10.229.219.197 with HTTP; Mon, 10 Jan 2011 12:13:00 -0800 (PST) In-Reply-To: <002301cbaf10$81bee520$853caf60$@net> References: <20110106191502.10151.87573.idtracker@localhost> <002301cbaf10$81bee520$853caf60$@net> Date: Mon, 10 Jan 2011 15:13:00 -0500 Message-ID: From: Mark Jones To: Glen Zorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] WGLC for draft-ietf-dime-extended-naptr 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: , X-List-Received-Date: Mon, 10 Jan 2011 20:10:53 -0000 Hi Glen, Thanks for the review. On Sat, Jan 8, 2011 at 3:46 AM, Glen Zorn wrote: > > Would somebody tell me again why we're issuing an update for a document t= hat > will be obsolete very soon? > I direct your attention to the "can of worms" presentation from IETF#76. :) http://www.ietf.org/proceedings/77/slides/dime-5.pdf At the time we started this draft, it was uncertain whether 3588bis would beat it to publication. So we decided to proceed optimistically assuming the SNAPTR draft would get published first with the understanding that we'd have some updates to do if we were wrong. The application-neutral aspects of SNAPTR (e.g "aaa:diameter.sctp") were also contributed to 3588bis to ensure that 3588bis would be functionally complete if it got published first and this draft would come along later to add the application-specific SNAPTR entries (e.g. "aaa+ap5:diameter.sctp"). > > This draft appears to be in some conflict w/rfc3588bis; in particular, bo= th > request that IANA register the same set of S-NAPTR Application Protocol > Tags. > > This draft updates RFC 3588 but says nothing about 3588bis; 3588bis says > nothing about this document. =A0This seems to lead to a dead-end. > If 3588bis is published first, we will need to change this draft to state that it updates 3588bis instead of 3588 and remove the duplicate SNAPTR protocol tag entries. > This draft is considerably more detailed WRT S-NAPTR than 3588bis. =A0Why= ? > This draft includes the level of detail required to satisfy the reviewers. The extra detail may be explained by the application-specific S-NAPTR grammar/usage being slightly more complicated than the application-neutral one in 3588bis. Do you think some essential details are missing from the 3588bis procedures? Regards Mark > Hope this helps. > > =A0~gwz > > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > > Jouni > > Sent: Saturday, January 08, 2011 5:51 AM > > To: dime@ietf.org > > Cc: dime-chairs@tools.ietf.org > > Subject: [Dime] WGLC for draft-ietf-dime-extended-naptr > > > > Folks, > > > > We will rerun a short WGLC for draft-ietf-dime-extended-naptr-04 since > > there were some bigger restructuring on the document. The WGLC starts a= s > > of today 8th Jan 2011 and ends 14th Jan 2011 23:59 CET+1. If you have > > substantial technical comments, please post them to the list. Purely > > editorial comments can be mailed directly to the authors. Silence will > > be taken as acceptance. > > > > - Jouni (as a Dime co-chair) > > > > > > _______________________________________________ > > 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 mark@azu.ca Mon Jan 10 12:44:30 2011 Return-Path: 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 DAF593A63D2 for ; Mon, 10 Jan 2011 12:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 IwyUhKyGOlLo for ; Mon, 10 Jan 2011 12:44:29 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 081E93A63CB for ; Mon, 10 Jan 2011 12:44:28 -0800 (PST) Received: by qwi2 with SMTP id 2so4504975qwi.31 for ; Mon, 10 Jan 2011 12:46:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.85.207 with SMTP id p15mr2889001qcl.167.1294692403073; Mon, 10 Jan 2011 12:46:43 -0800 (PST) Received: by 10.229.219.197 with HTTP; Mon, 10 Jan 2011 12:46:43 -0800 (PST) In-Reply-To: <002701cbaf12$43eabb00$cbc03100$@net> References: <20110106191502.10151.87573.idtracker@localhost> <002701cbaf12$43eabb00$cbc03100$@net> Date: Mon, 10 Jan 2011 15:46:43 -0500 Message-ID: From: Mark Jones To: Glen Zorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] WGLC for draft-ietf-dime-extended-naptr 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: , X-List-Received-Date: Mon, 10 Jan 2011 20:44:31 -0000 Hi Glen, (Typo in my previous email: s/IETF#76/IETF#77/. The URL was correct though.= ) On Sat, Jan 8, 2011 at 3:58 AM, Glen Zorn wrote: > Shouldn't the title actually be something like "Diameter S-NAPTR Usage"? > I like that. Unless I hear objections, I'll pick it up in the next revision= . > Change the first page header to read > > Network Working Group =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 M. Jones > Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Bridgewater > Systems > > instead of > > Diameter Maintenance and =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0M. Jones > Extensions (DIME) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bridgewater > Systems > Agreed. > The abbreviated title ("dime-extended-naptr") is just silly (and not > anything like an abbreviation). > It originally got that title because we were extending NAPTR until we realized it was obsoleted by DDDS and SNAPTR should be used instead. I'd prefer to keep the 'silly' title now since it will disappear when it gets an RFC number and a rename at this stage might make it more difficult to track the draft evolution. > > There is no Application Service Tag define for the Diameter Base Protocol= in > this draft (although there is in rfc388bis). AFAIK, rfc3588bis only reserves a tag for "aaa" which means ANY Diameter application. > Since The Diameter Base > protocol includes rudimentary accounting functionality it doesn't seem > completely unreasonable that Diameter Base might be used as a stand-alone > app. > Ok, I hadn't appreciated that stand-alone usage of Base. Looking at section 7.1, it appears to be missing two entries: one for "aaa" and one for "aaa+ap0". The "aaa" entry could be deleted if rfc3588bis is published first. Thanks Mark > Hope this helps. > > =A0~gwz > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >> Jouni >> Sent: Saturday, January 08, 2011 5:51 AM >> To: dime@ietf.org >> Cc: dime-chairs@tools.ietf.org >> Subject: [Dime] WGLC for draft-ietf-dime-extended-naptr >> >> Folks, >> >> We will rerun a short WGLC for draft-ietf-dime-extended-naptr-04 since >> there were some bigger restructuring on the document. The WGLC starts as >> of today 8th Jan 2011 and ends 14th Jan 2011 23:59 CET+1. If you have >> substantial technical comments, please post them to the list. Purely >> editorial comments can be mailed directly to the authors. Silence will >> be taken as acceptance. >> >> - Jouni (as a Dime co-chair) >> >> >> _______________________________________________ >> 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 sdecugis@nict.go.jp Mon Jan 10 17:42:28 2011 Return-Path: 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 21F583A68F7 for ; Mon, 10 Jan 2011 17:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_FR=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 PCkwb8n20RZN for ; Mon, 10 Jan 2011 17:42:26 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 2B3D43A68F5 for ; Mon, 10 Jan 2011 17:42:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 3C64C948EC for ; Tue, 11 Jan 2011 02:44:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvQ1wYC-+IUd for ; Tue, 11 Jan 2011 02:44:16 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 7362C9421E for ; Tue, 11 Jan 2011 02:44:15 +0100 (CET) Message-ID: <4D2BB5F1.8030009@nict.go.jp> Date: Tue, 11 Jan 2011 10:44:17 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dime@ietf.org References: <20110106191502.10151.87573.idtracker@localhost> <002701cbaf12$43eabb00$cbc03100$@net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] WGLC for draft-ietf-dime-extended-naptr 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: , X-List-Received-Date: Tue, 11 Jan 2011 01:42:28 -0000 Hi, >> Since The Diameter Base >> protocol includes rudimentary accounting functionality it doesn't seem >> completely unreasonable that Diameter Base might be used as a stand-alone >> app. > Ok, I hadn't appreciated that stand-alone usage of Base. Looking at > section 7.1, it appears to be missing two entries: one for "aaa" and > one for "aaa+ap0". The "aaa" entry could be deleted if rfc3588bis is > published first. If I understand correctly the discussion, I think you mean here "aaa+ap3". Application 0 is used for the "one hop only" messages (CER/CEA, DWR/DWA...) and is supported by ALL peers (so there is no point in having it defined here). Application 3 is the "rudimentary accounting functionality" defined in rfc3588(bis). I apologize if my remark is irrelevant... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Mon Jan 10 18:05:09 2011 Return-Path: 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 C1B6828C150 for ; Mon, 10 Jan 2011 18:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Pgv7njgwt6iP for ; Mon, 10 Jan 2011 18:05:09 -0800 (PST) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id E63CA28C142 for ; Mon, 10 Jan 2011 18:05:08 -0800 (PST) Received: (qmail 14610 invoked from network); 11 Jan 2011 02:07:22 -0000 Received: from unknown (124.120.78.177) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 11 Jan 2011 02:07:22 -0000 From: "Glen Zorn" To: "'jouni korhonen'" , References: <15FD18E5-8D25-49CF-86E9-77669324F430@gmail.com> In-Reply-To: <15FD18E5-8D25-49CF-86E9-77669324F430@gmail.com> Date: Tue, 11 Jan 2011 09:06:55 +0700 Organization: Network Zen Message-ID: <017101cbb134$3b05c240$b11146c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acuw74Z5+VmRCSBFQbyJLRsWfTQ4ZAARC6bg Content-Language: en-us Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] WGLC for draft-ietf-dime-rfc4005-bis 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: , X-List-Received-Date: Tue, 11 Jan 2011 02:05:09 -0000 jouni korhonen [mailto://jouni.nospam@gmail.com] writes: ... > Remember that a document to move forward, we require at least three > reviews (oneliners do not count..). So if someone carefully reviews a dime WG draft and honestly can find nothing wrong, they've either wasted their time or must compose a lengthy missive when one line would do? Great incentive to review! ... From mark@azu.ca Tue Jan 11 06:57:12 2011 Return-Path: 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 DE14C28C2C5 for ; Tue, 11 Jan 2011 06:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rr83YeQzI65c for ; Tue, 11 Jan 2011 06:57:11 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0AC2528C17D for ; Tue, 11 Jan 2011 06:57:10 -0800 (PST) Received: by qwi2 with SMTP id 2so5369734qwi.31 for ; Tue, 11 Jan 2011 06:59:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.235.205 with SMTP id kh13mr25744710qcb.243.1294757967345; Tue, 11 Jan 2011 06:59:27 -0800 (PST) Received: by 10.229.219.197 with HTTP; Tue, 11 Jan 2011 06:59:27 -0800 (PST) In-Reply-To: <017101cbb134$3b05c240$b11146c0$@net> References: <15FD18E5-8D25-49CF-86E9-77669324F430@gmail.com> <017101cbb134$3b05c240$b11146c0$@net> Date: Tue, 11 Jan 2011 09:59:27 -0500 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Dime] WGLC for draft-ietf-dime-rfc4005-bis 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: , X-List-Received-Date: Tue, 11 Jan 2011 14:57:12 -0000 >> Remember that a document to move forward, we require at least three >> reviews (oneliners do not count..). > > So if someone carefully reviews a dime WG draft and honestly can find > nothing wrong, they've either wasted their time or must compose a lengthy > missive when one line would do? =A0Great incentive to review! > I understood that "one liners" carry equal weight in the review count (as in "I have reviewed this draft and found no issues"). I remember this being explicitly mentioned by DIME chairs at past IETF meetings to get reviewers engaged without them thinking they're committing to delivering a lengthy dissertation. I don't think we have a problem with frivolous reviews in this working group. At least, I've always received quality feedback. Mark From jouni.nospam@gmail.com Tue Jan 11 13:03:43 2011 Return-Path: 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 98FB328C13B for ; Tue, 11 Jan 2011 13:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, 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 g16r8VUNlRSm for ; Tue, 11 Jan 2011 13:03:42 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7ADBE28C12F for ; Tue, 11 Jan 2011 13:03:42 -0800 (PST) Received: by fxm9 with SMTP id 9so20781615fxm.31 for ; Tue, 11 Jan 2011 13:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=EjZM3yeCw2oSGbDKczN8xIJgzWpOakbJY87Md3c26DI=; b=mHQ3YNaBhtPegKkqDsQRRc96oG6TBVs7/GogeScqnONvnHC87pdib0SGYK3F5CmVKx WcmYzexo00tTvsbR6bSFjQx6yRu9+jSQgB3xkqp5fGlvxLhtGPRnx1VbhxTURQvrnB8X 2fbn/tkHMV7vMFl5IFm4dKn7yxO3JQ7S6Abgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=DofDTc4gMh/gfpO0tgl7hGzraqvTOv2y5sYPnxq2k2rK+nGMSCX7Ljwtpfgr3Lj2CD 1L+ynM8IDTsMxR+3RTuuXM8CDQGrub4Esl11bP2Z1CTwFSnshX0vaHT5kS8tYqf13qux 0ofyCbY7qqJk8M4WGCiQ3p8Q13rWlgw+ncYjg= Received: by 10.223.71.197 with SMTP id i5mr80498faj.127.1294779959559; Tue, 11 Jan 2011 13:05:59 -0800 (PST) Received: from a88-114-64-180.elisa-laajakaista.fi (a88-114-64-180.elisa-laajakaista.fi [88.114.64.180]) by mx.google.com with ESMTPS id a25sm7584311fak.20.2011.01.11.13.05.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 13:05:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: jouni korhonen In-Reply-To: Date: Tue, 11 Jan 2011 23:05:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8929680A-B880-471E-9C26-F79675B2D083@gmail.com> References: <15FD18E5-8D25-49CF-86E9-77669324F430@gmail.com> <017101cbb134$3b05c240$b11146c0$@net> To: dime@ietf.org X-Mailer: Apple Mail (2.1078) Subject: Re: [Dime] WGLC for draft-ietf-dime-rfc4005-bis 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: , X-List-Received-Date: Tue, 11 Jan 2011 21:03:43 -0000 I find it hard to believe that a document length of 65 pages would end = up to a oneliner review comment. Anyway as the topic seems to interest = folks, lets scope it a bit better. If I were to see a oneliner saying "I = have reviewed this draft and found no issues." from a person using = his/her mighty identity hiding gmail address and who never showed up in = a meeting or never spoke in the list before or with whom I have no never = dealt with/heard of.. serves no purpose. If a oneliner like "I = implemented the spec and found no issues." would come e.g. from = Sebastien I would take that as an excellent review result. So yes, = oneliners are still not encouraged.. but of course it always depends on = the context. - Jouni On Jan 11, 2011, at 4:59 PM, Mark Jones wrote: >>> Remember that a document to move forward, we require at least three >>> reviews (oneliners do not count..). >>=20 >> So if someone carefully reviews a dime WG draft and honestly can find >> nothing wrong, they've either wasted their time or must compose a = lengthy >> missive when one line would do? Great incentive to review! >>=20 >=20 > I understood that "one liners" carry equal weight in the review count > (as in "I have reviewed this draft and found no issues"). I remember > this being explicitly mentioned by DIME chairs at past IETF meetings > to get reviewers engaged without them thinking they're committing to > delivering a lengthy dissertation. I don't think we have a problem > with frivolous reviews in this working group. At least, I've always > received quality feedback. >=20 > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From mark@azu.ca Wed Jan 12 07:57:53 2011 Return-Path: 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 7BB7D3A6A43 for ; Wed, 12 Jan 2011 07:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JEKVcEQAjlhf for ; Wed, 12 Jan 2011 07:57:52 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 937693A67D8 for ; Wed, 12 Jan 2011 07:57:52 -0800 (PST) Received: by qwi2 with SMTP id 2so758045qwi.31 for ; Wed, 12 Jan 2011 08:00:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.84.203 with SMTP id k11mr942170qcl.281.1294848011405; Wed, 12 Jan 2011 08:00:11 -0800 (PST) Received: by 10.229.219.197 with HTTP; Wed, 12 Jan 2011 08:00:11 -0800 (PST) Date: Wed, 12 Jan 2011 11:00:11 -0500 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Dime] Review of draft-ietf-dime-rfc4005-bis 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: , X-List-Received-Date: Wed, 12 Jan 2011 15:57:53 -0000 (The issue tracker tool doesn't want seem to create account for me so I'm posting here.) >From the diff with rfc4005, I realize my comments relate to the original text rather than Glen's changes but I think they're valid candidates for the bis. --- Section 3.9. Accounting-Request (ACR) Command "Either the Acct-Application-Id AVP or the Vendor-Specific- Application-Id AVP MUST be present." mj> I understand that the Acct-Application-Id is required for backwards compatibility (it is still redundant since the same app id is in the command header) but don't see why Vendor-Specific-Application-Id would ever need be present. The same comment applies to Section 3.10. --- Section 4.1.1. QoSFilterRule "The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset." mj> RFC5777 defines Diameter AVPs that represent QoS and IP filter rules and even includes a NASREQ example. I'd like to see the ASCII-based variants deprecated but even if that idea doesn't fly, I think it would be useful to mention RFC5777 here as offering an alternative. --- Section 4.2.5. Called-Station-Id AVP "It SHOULD only be present in authentication and/or authorization requests." mj> Why is this recommendation here? This AVP is commonly used in RADIUS accounting requests. Same comment for Calling-Station-Id AVP in Section 4.2.6. --- Section 4.5.8. Tunnel-Assignment-Id AVP mj> s/should/SHOULD/g mj> Last paragraph appears to be missing normative statements in the first two sentences. Was this intentional? Regards Mark From jouni.nospam@gmail.com Thu Jan 13 01:08:38 2011 Return-Path: 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 9AA4F3A6AC9; Thu, 13 Jan 2011 01:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, 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 chKVD40NqRzC; Thu, 13 Jan 2011 01:08:37 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B72C73A69EF; Thu, 13 Jan 2011 01:08:36 -0800 (PST) Received: by fxm9 with SMTP id 9so1541495fxm.31 for ; Thu, 13 Jan 2011 01:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:subject:date:message-id:cc:to :mime-version:x-mailer; bh=TxcCEFo1o9nqoos9Q/wgi4YhJAdfEAUofjmCJ70gly0=; b=gHUjpWlUZYhVwl1uyMb4FXprLtFZ0RdBN32hx3OHnrwjHzNX0cAVlTC+IdhbnDQu0K qHSau4ccCfHKZbe/DD0/C2fAKYRSHm/gdnphvj+OURJchYyC5KOzXuCJfkAkoquhvUD4 tZjj5rjbZpHW394j7YoSEg/fqXqLL0t94f6YQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; b=HnhIm7u44aFJY+YBpHcPOS0Hr6hBB/mFjaF41akQnCJ8MbN0zv0MozeIQMF6SQd7o1 xHccEGVjGh2Uvh/04czsx6EncSg6aGMKlO8vVcseY6s+j2fNagFy3YFAqV6hk7FM0A24 nT06WwoIcDu81Fw9PpjVyJyzcwJ1Sh3B7X3XQ= Received: by 10.223.86.16 with SMTP id q16mr2096067fal.58.1294909858090; Thu, 13 Jan 2011 01:10:58 -0800 (PST) Received: from a88-114-64-180.elisa-laajakaista.fi (a88-114-64-180.elisa-laajakaista.fi [88.114.64.180]) by mx.google.com with ESMTPS id n1sm536305fam.16.2011.01.13.01.10.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 01:10:57 -0800 (PST) From: jouni korhonen Content-Type: multipart/mixed; boundary=Apple-Mail-5-922558302 Date: Thu, 13 Jan 2011 11:10:54 +0200 Message-Id: <02FB5214-8EA5-4FC0-9757-219C231E5FAD@gmail.com> To: iesg-secretary@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: [Dime] Publication request for Diameter Network Address and Port Translation Control Application - draft-ietf-dime-nat-control-06 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: , X-List-Received-Date: Thu, 13 Jan 2011 09:08:38 -0000 --Apple-Mail-5-922558302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Secretary, This is a request for publication of draft-ietf-dime-nat-control-06 as a = standards track RFC. I am attaching the document shepherd proto = write-up. - Jouni --Apple-Mail-5-922558302 Content-Disposition: attachment; filename=natcontrol_proto.txt Content-Type: text/plain; name="natcontrol_proto.txt" Content-Transfer-Encoding: quoted-printable (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 -- Jouni Korhonen (jouni.korhonen@nsn.com, jouni.nospam@gmail.com) is the Document Shepherd, Dime co-chair. He has done a review on the document and believes it is ready to be forwarded to IESG for publication. (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 -- The document has had an extensive review by the DIME WG. = The document should still be reviewed by the PCP WG and BEHAVE = WG for NAT considerations. These reviews can be done during = the IETF LC. =20 The shepherd has reviewed the document himself and has no issue with it. Nor the shepherd has issues with the reviews done by others. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 -- No. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20= has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 -- No. (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 -- There is Dime WG consensus behind the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20= discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 -- No. (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts = Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20= not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 -- The shepherd has checked the document with the idnits tool and found no issues. The document does not need MIB doctor review. The document does not contain any media and URI types. (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 -- References are split accordingly and there are no references to documents with unclear status or are in progress. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 -- Yes. extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 -- Yes, however, this document does not define new IANA registries. the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 -- This document does not define new IANA registries. (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 -- Yes. Note that the ABNF used in this document follows the modified ABNF syntax defined in RFC3588. =20 =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 -- This document defines a Diameter NA(P)T Control Application = (DNCA). The use of the DNCA allows a simple integration of the NAT = device management into the existing AAA environment of Internet = Service Provider. =20 The Diameter application runs between a DNCA Agent on the NAT device and the DNCA Manager (either collocated in a NAS device or in a AAA server). The DNCA is used to provide = advanced management of NAT devices, NAT bindings and NAT related = accounting. =20 Working Group Summary=20 --- The document spent well over a year in the WG. However, the = authors actively kept the document progressing and improving. The = document is a result of collaborative WG work. Document Quality=20 --- There is currently no publicly announced implementations of the protocol. The document itself is solid, well written and in = places goes into level of details not often seen in Diameter = Application describing documents. =20 =20= --Apple-Mail-5-922558302-- From trac@tools.ietf.org Sat Jan 15 12:55:03 2011 Return-Path: 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 E908D3A6E3A for ; Sat, 15 Jan 2011 12:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Waddu5gfeJXj for ; Sat, 15 Jan 2011 12:55:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4F3013A6D82 for ; Sat, 15 Jan 2011 12:55:02 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PeDBd-0005Ar-Nw; Sat, 15 Jan 2011 12:57:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dime@ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Sat, 15 Jan 2011 20:57:25 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/dime/trac/ticket/16 Message-ID: <064.0512efebff43593dc4038989266f0cc0@tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, jouni.nospam@gmail.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime-chairs@tools.ietf.org Subject: [Dime] [dime] rfc4005bis #16 (new): Accounting-Request (ACR) Command X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 20:55:04 -0000 #16: Accounting-Request (ACR) Command Section 3.9. Accounting-Request (ACR) Command "Either the Acct-Application-Id AVP or the Vendor-Specific- Application-Id AVP MUST be present." Mark Jones> I understand that the Acct-Application-Id is required for backwards compatibility (it is still redundant since the same app id is in the command header) but don't see why Vendor-Specific-Application-Id would ever need be present. The same comment applies to Section 3.10. -- ------------------------------------+--------------------------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: defect | Status: new Priority: major | Milestone: Component: rfc4005bis | Version: Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dime From trac@tools.ietf.org Sat Jan 15 12:56:36 2011 Return-Path: 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 B596A3A6E3B for ; Sat, 15 Jan 2011 12:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 DDwb7YWJZLT8 for ; Sat, 15 Jan 2011 12:56:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0607E3A6D82 for ; Sat, 15 Jan 2011 12:56:36 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PeDDC-0005CR-Nr; Sat, 15 Jan 2011 12:59:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dime@ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Sat, 15 Jan 2011 20:59:02 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/dime/trac/ticket/17 Message-ID: <064.68d0444852392e4d5c5c35d7b3b08c48@tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, jouni.nospam@gmail.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime-chairs@tools.ietf.org Subject: [Dime] [dime] rfc4005bis #17 (new): QoSFilterRule X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 20:56:36 -0000 #17: QoSFilterRule Section 4.1.1. QoSFilterRule "The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset." Mark Jones> RFC5777 defines Diameter AVPs that represent QoS and IP filter rules and even includes a NASREQ example. I'd like to see the ASCII-based variants deprecated but even if that idea doesn't fly, I think it would be useful to mention RFC5777 here as offering an alternative. -- ------------------------------------+--------------------------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: defect | Status: new Priority: major | Milestone: Component: rfc4005bis | Version: Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dime From trac@tools.ietf.org Sat Jan 15 12:57:20 2011 Return-Path: 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 650CB3A6E3A for ; Sat, 15 Jan 2011 12:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 h4hBLi0+a0cg for ; Sat, 15 Jan 2011 12:57:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0C5453A6D82 for ; Sat, 15 Jan 2011 12:57:19 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PeDDu-0005DN-Ct; Sat, 15 Jan 2011 12:59:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dime@ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Sat, 15 Jan 2011 20:59:46 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/dime/trac/ticket/18 Message-ID: <064.56d439c7d20332f7ef87b62b012e4829@tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, jouni.nospam@gmail.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime-chairs@tools.ietf.org Subject: [Dime] [dime] rfc4005bis #18 (new): Called-Station-Id AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 20:57:20 -0000 #18: Called-Station-Id AVP Section 4.2.5. Called-Station-Id AVP "It SHOULD only be present in authentication and/or authorization requests." Mark Jones> Why is this recommendation here? This AVP is commonly used in RADIUS accounting requests. Same comment for Calling-Station-Id AVP in Section 4.2.6. -- ------------------------------------+--------------------------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: defect | Status: new Priority: major | Milestone: Component: rfc4005bis | Version: Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dime From trac@tools.ietf.org Sat Jan 15 12:58:06 2011 Return-Path: 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 3D0CF3A6E3C for ; Sat, 15 Jan 2011 12:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 duyeezHwJO87 for ; Sat, 15 Jan 2011 12:58:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 905E43A6E3B for ; Sat, 15 Jan 2011 12:58:05 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PeDEf-0003k7-CW; Sat, 15 Jan 2011 13:00:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dime@ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Sat, 15 Jan 2011 21:00:33 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/dime/trac/ticket/19 Message-ID: <064.7acde6a2bdf9a7529b6f9f784b27fa78@tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, jouni.nospam@gmail.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime-chairs@tools.ietf.org Subject: [Dime] [dime] rfc4005bis #19 (new): Tunnel-Assignment-Id AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 20:58:06 -0000 #19: Tunnel-Assignment-Id AVP Section 4.5.8. Tunnel-Assignment-Id AVP Mark Jones> s/should/SHOULD/g Mark Jones> Last paragraph appears to be missing normative statements in the first two sentences. Was this intentional? -- ------------------------------------+--------------------------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: defect | Status: new Priority: major | Milestone: Component: rfc4005bis | Version: Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dime From isj-dime@i1.dk Mon Jan 17 16:07:25 2011 Return-Path: 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 8501B28C1D9 for ; Mon, 17 Jan 2011 16:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=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 xsDWL5WEnVWk for ; Mon, 17 Jan 2011 16:07:24 -0800 (PST) Received: from i1.dk (port80.ds1-hk.adsl.cybercity.dk [212.242.60.147]) by core3.amsl.com (Postfix) with ESMTP id AB8FD28C1CB for ; Mon, 17 Jan 2011 16:07:24 -0800 (PST) Received: from isjsys5.int.i1.dk (isjsys5 [127.0.0.1]) by isjsys5.int.i1.dk (Postfix) with ESMTP id A4A035C006E for ; Tue, 18 Jan 2011 01:02:15 +0100 (CET) Received: from isjsys (isjsys [10.0.0.2]) by isjsys5.int.i1.dk (Postfix) with ESMTP for ; Tue, 18 Jan 2011 01:02:15 +0100 (CET) From: Ivan Skytte =?iso-8859-1?q?J=F8rgensen?= To: dime@ietf.org Date: Tue, 18 Jan 2011 01:01:55 +0100 User-Agent: KMail/1.9.10 X-Accept-Language: da, en, de MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201101180101.55463.isj-dime@i1.dk> Subject: [Dime] Retransmit behaviour 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: , X-List-Received-Date: Tue, 18 Jan 2011 00:07:25 -0000 Hi list, I recently encountered a retransmit behaviour I hadn't seen before. In a simple setup with a client directly connected to a server I saw: 1: The client had an internal timer that triggered retransmit of message if it had not received a response within a (configurable) time limit. The retransmit did not take into account if there had been a link failure and retransmitted no matter what. 2: The client did properly set the T-bit in the header and retained the end-to-end-identifier as it should, but it also retained the hop-by-hop-identifier. Q1: Can a client set the T-bit even if there has been no link failure? Q2: If yes, must the hop-by-hop-identifier be retained or must a new one be used? Q3: What is the correct behaviour of an agent or server if it detects that the hop-by-hop-identifier is not unique? Regards, Ivan From sdecugis@nict.go.jp Mon Jan 17 16:57:36 2011 Return-Path: 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 58F3B3A6F77 for ; Mon, 17 Jan 2011 16:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_FR=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 wuvXefkllDSM for ; Mon, 17 Jan 2011 16:57:35 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 3011D3A6B9B for ; Mon, 17 Jan 2011 16:57:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 2F8339421E for ; Tue, 18 Jan 2011 01:59:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iU9oJqO19p5N for ; Tue, 18 Jan 2011 01:59:50 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id D93219421B for ; Tue, 18 Jan 2011 01:59:49 +0100 (CET) Message-ID: <4D34E604.70307@nict.go.jp> Date: Tue, 18 Jan 2011 09:59:48 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dime@ietf.org References: <201101180101.55463.isj-dime@i1.dk> In-Reply-To: <201101180101.55463.isj-dime@i1.dk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] Retransmit behaviour 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: , X-List-Received-Date: Tue, 18 Jan 2011 00:57:36 -0000 Hello, Just a clarifying question: is the client retransmission timer shorter than TwTimer (watchdog frequency) ? It looks to me that the client retransmitting the message is useless in any case, and can only lead to overloading the server. I would like to hear in which situation this retransmission can be useful, if any. Best regards, Sebastien. Le 18/01/2011 09:01, Ivan Skytte Jørgensen a écrit : > Hi list, > > I recently encountered a retransmit behaviour I hadn't seen before. In > a simple setup with a client directly connected to a server I saw: > > 1: The client had an internal timer that triggered retransmit of > message if it had not received a response within a (configurable) > time limit. The retransmit did not take into account if there had > been a link failure and retransmitted no matter what. > > 2: The client did properly set the T-bit in the header and retained > the end-to-end-identifier as it should, but it also retained the > hop-by-hop-identifier. > > Q1: Can a client set the T-bit even if there has been no link failure? > > Q2: If yes, must the hop-by-hop-identifier be retained or must a new > one be used? > > Q3: What is the correct behaviour of an agent or server if it detects > that the hop-by-hop-identifier is not unique? > > Regards, > Ivan > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From isj-dime@i1.dk Mon Jan 17 17:34:16 2011 Return-Path: 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 956CB3A6DC0 for ; Mon, 17 Jan 2011 17:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.017 X-Spam-Level: X-Spam-Status: No, score=0.017 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=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 SDrwpbtUDGGG for ; Mon, 17 Jan 2011 17:34:15 -0800 (PST) Received: from i1.dk (port80.ds1-hk.adsl.cybercity.dk [212.242.60.147]) by core3.amsl.com (Postfix) with ESMTP id DC95A3A6DB3 for ; Mon, 17 Jan 2011 17:34:14 -0800 (PST) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id 4916D5C006E for ; Tue, 18 Jan 2011 02:36:49 +0100 (CET) Received: from isjsys (isjsys [10.0.0.2]) by i1.dk (Postfix) with ESMTP for ; Tue, 18 Jan 2011 02:36:49 +0100 (CET) From: Ivan Skytte =?iso-8859-1?q?J=F8rgensen?= To: dime@ietf.org Date: Tue, 18 Jan 2011 02:36:28 +0100 User-Agent: KMail/1.9.10 References: <201101180101.55463.isj-dime@i1.dk> <4D34E604.70307@nict.go.jp> In-Reply-To: <4D34E604.70307@nict.go.jp> X-Accept-Language: da, en, de MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201101180236.29005.isj-dime@i1.dk> Subject: Re: [Dime] Retransmit behaviour 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: , X-List-Received-Date: Tue, 18 Jan 2011 01:34:16 -0000 The client retransmit timer was 1 second by default. The watchdog=20 interval was 30 seconds. On Tuesday 18 January 2011 01:59:48 Sebastien Decugis wrote: > Hello, > > Just a clarifying question: is the client retransmission timer > shorter than TwTimer (watchdog frequency) ? > > It looks to me that the client retransmitting the message is > useless in any case, and can only lead to overloading the server. I > would like to hear in which situation this retransmission can be > useful, if any. > > Best regards, > Sebastien. > > Le 18/01/2011 09:01, Ivan Skytte J=F8rgensen a =E9crit : > > Hi list, > > > > I recently encountered a retransmit behaviour I hadn't seen > > before. In a simple setup with a client directly connected to a > > server I saw: > > > > 1: The client had an internal timer that triggered retransmit of > > message if it had not received a response within a (configurable) > > time limit. The retransmit did not take into account if there had > > been a link failure and retransmitted no matter what. > > > > 2: The client did properly set the T-bit in the header and > > retained the end-to-end-identifier as it should, but it also > > retained the hop-by-hop-identifier. > > > > Q1: Can a client set the T-bit even if there has been no link > > failure? > > > > Q2: If yes, must the hop-by-hop-identifier be retained or must a > > new one be used? > > > > Q3: What is the correct behaviour of an agent or server if it > > detects that the hop-by-hop-identifier is not unique? > > > > Regards, > > Ivan > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Mon Jan 17 17:43:07 2011 Return-Path: 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 3A6603A6DA7 for ; Mon, 17 Jan 2011 17:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_FR=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 LyVSVwPkPTgZ for ; Mon, 17 Jan 2011 17:43:06 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 15F503A6D1E for ; Mon, 17 Jan 2011 17:43:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 17DC394477 for ; Tue, 18 Jan 2011 02:45:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPpyFVRdTcDM for ; Tue, 18 Jan 2011 02:45:22 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 24E6C94240 for ; Tue, 18 Jan 2011 02:45:20 +0100 (CET) Message-ID: <4D34F0AE.2040009@nict.go.jp> Date: Tue, 18 Jan 2011 10:45:18 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dime@ietf.org References: <201101180101.55463.isj-dime@i1.dk> <4D34E604.70307@nict.go.jp> <201101180236.29005.isj-dime@i1.dk> In-Reply-To: <201101180236.29005.isj-dime@i1.dk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] Retransmit behaviour 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: , X-List-Received-Date: Tue, 18 Jan 2011 01:43:07 -0000 Thank you for your answer. I still fail to see the value of this retransmission behavior, since the transport layer already cares for transmission loss. At the Diameter layer, if the server is taking more than 1 second to answer, it probably means it is busy, there is no value in adding to its load. If the query was dropped without answer for some reason, the retransmitted message will very likely have the same treatment. I would just remove this retransmission mechanism, or if not possible set the timer to several times TwTimer... This is only my opinion, other people from the group probably have a different one :) Sebastien. Le 18/01/2011 10:36, Ivan Skytte Jørgensen a écrit : > The client retransmit timer was 1 second by default. The watchdog > interval was 30 seconds. > > On Tuesday 18 January 2011 01:59:48 Sebastien Decugis wrote: >> Hello, >> >> Just a clarifying question: is the client retransmission timer >> shorter than TwTimer (watchdog frequency) ? >> >> It looks to me that the client retransmitting the message is >> useless in any case, and can only lead to overloading the server. I >> would like to hear in which situation this retransmission can be >> useful, if any. >> >> Best regards, >> Sebastien. >> >> Le 18/01/2011 09:01, Ivan Skytte Jørgensen a écrit : >>> Hi list, >>> >>> I recently encountered a retransmit behaviour I hadn't seen >>> before. In a simple setup with a client directly connected to a >>> server I saw: >>> >>> 1: The client had an internal timer that triggered retransmit of >>> message if it had not received a response within a (configurable) >>> time limit. The retransmit did not take into account if there had >>> been a link failure and retransmitted no matter what. >>> >>> 2: The client did properly set the T-bit in the header and >>> retained the end-to-end-identifier as it should, but it also >>> retained the hop-by-hop-identifier. >>> >>> Q1: Can a client set the T-bit even if there has been no link >>> failure? >>> >>> Q2: If yes, must the hop-by-hop-identifier be retained or must a >>> new one be used? >>> >>> Q3: What is the correct behaviour of an agent or server if it >>> detects that the hop-by-hop-identifier is not unique? >>> >>> Regards, >>> Ivan >>> _______________________________________________ >>> 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 -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From isj-dime@i1.dk Tue Jan 18 15:29:33 2011 Return-Path: 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 269EE28C13C for ; Tue, 18 Jan 2011 15:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HELO_EQ_DK=1.009, J_CHICKENPOX_75=0.6, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=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 GJTym1AWnPRU for ; Tue, 18 Jan 2011 15:29:32 -0800 (PST) Received: from i1.dk (port80.ds1-hk.adsl.cybercity.dk [212.242.60.147]) by core3.amsl.com (Postfix) with ESMTP id E18BF28C132 for ; Tue, 18 Jan 2011 15:29:31 -0800 (PST) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id 941835C006E for ; Wed, 19 Jan 2011 00:32:08 +0100 (CET) Received: from isjsys (isjsys [10.0.0.2]) by i1.dk (Postfix) with ESMTP for ; Wed, 19 Jan 2011 00:32:08 +0100 (CET) From: Ivan Skytte =?iso-8859-1?q?J=F8rgensen?= To: dime@ietf.org Date: Wed, 19 Jan 2011 00:31:47 +0100 User-Agent: KMail/1.9.10 References: <201101180101.55463.isj-dime@i1.dk> <201101180236.29005.isj-dime@i1.dk> <4D34F0AE.2040009@nict.go.jp> In-Reply-To: <4D34F0AE.2040009@nict.go.jp> X-Accept-Language: da, en, de MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201101190031.47728.isj-dime@i1.dk> Subject: Re: [Dime] Retransmit behaviour 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: , X-List-Received-Date: Tue, 18 Jan 2011 23:29:33 -0000 I agree that the blind retransmits have little value and can even be=20 harmful. I was also trying to guess why the client had implemented it=20 because it had always been obvious to me that server/proxy/relay must=20 respond to all requests so there is no point in retransmitting a=20 request unless there has been a transport connection failure. But=20 when I re-read through rfc3588 again to find chapter&verse to quote I=20 realized that it isn't clearly written in section 5.5.4 "Failover and=20 =46ailback Procedures", so I guess that there could exist=20 proxies/relays that discard pending requests if the upward transport=20 connection breaks, and servers that discard requests for unknown=20 reason. Is it too late to get such clarifications into rfc3588bis ? Regards, Ivan On Tuesday 18 January 2011 02:45:18 Sebastien Decugis wrote: > Thank you for your answer. > > I still fail to see the value of this retransmission behavior, > since the transport layer already cares for transmission loss. At > the Diameter layer, if the server is taking more than 1 second to > answer, it probably means it is busy, there is no value in adding > to its load. If the query was dropped without answer for some > reason, the retransmitted message will very likely have the same > treatment. > > I would just remove this retransmission mechanism, or if not > possible set the timer to several times TwTimer... > > This is only my opinion, other people from the group probably have > a different one :) > Sebastien. > > Le 18/01/2011 10:36, Ivan Skytte J=F8rgensen a =E9crit : > > The client retransmit timer was 1 second by default. The watchdog > > interval was 30 seconds. > > > > On Tuesday 18 January 2011 01:59:48 Sebastien Decugis wrote: > >> Hello, > >> > >> Just a clarifying question: is the client retransmission timer > >> shorter than TwTimer (watchdog frequency) ? > >> > >> It looks to me that the client retransmitting the message is > >> useless in any case, and can only lead to overloading the > >> server. I would like to hear in which situation this > >> retransmission can be useful, if any. > >> > >> Best regards, > >> Sebastien. > >> > >> Le 18/01/2011 09:01, Ivan Skytte J=F8rgensen a =E9crit : > >>> Hi list, > >>> > >>> I recently encountered a retransmit behaviour I hadn't seen > >>> before. In a simple setup with a client directly connected to a > >>> server I saw: > >>> > >>> 1: The client had an internal timer that triggered retransmit > >>> of message if it had not received a response within a > >>> (configurable) time limit. The retransmit did not take into > >>> account if there had been a link failure and retransmitted no > >>> matter what. > >>> > >>> 2: The client did properly set the T-bit in the header and > >>> retained the end-to-end-identifier as it should, but it also > >>> retained the hop-by-hop-identifier. > >>> > >>> Q1: Can a client set the T-bit even if there has been no link > >>> failure? > >>> > >>> Q2: If yes, must the hop-by-hop-identifier be retained or must > >>> a new one be used? > >>> > >>> Q3: What is the correct behaviour of an agent or server if it > >>> detects that the hop-by-hop-identifier is not unique? > >>> > >>> Regards, > >>> Ivan > >>> _______________________________________________ > >>> 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 Internet-Drafts@ietf.org Fri Jan 21 06:00:04 2011 Return-Path: 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 A13DA3A6996; Fri, 21 Jan 2011 06:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aAobQ0a0aBz6; Fri, 21 Jan 2011 06:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BECA33A697A; Fri, 21 Jan 2011 06:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110121140001.12204.62418.idtracker@localhost> Date: Fri, 21 Jan 2011 06:00:01 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-26.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: , X-List-Received-Date: Fri, 21 Jan 2011 14:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-26.txt Pages : 155 Date : 2011-01-21 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-26.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-rfc3588bis-26.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-21054512.I-D@ietf.org> --NextPart-- From mark@azu.ca Fri Jan 21 07:24:30 2011 Return-Path: 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 274B23A6A08 for ; Fri, 21 Jan 2011 07:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 EwCUlob5LZwz for ; Fri, 21 Jan 2011 07:24:29 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 472BF3A6A04 for ; Fri, 21 Jan 2011 07:24:29 -0800 (PST) Received: by qwi2 with SMTP id 2so2014705qwi.31 for ; Fri, 21 Jan 2011 07:27:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.84.203 with SMTP id k11mr649003qcl.281.1295623635091; Fri, 21 Jan 2011 07:27:15 -0800 (PST) Received: by 10.229.219.197 with HTTP; Fri, 21 Jan 2011 07:27:15 -0800 (PST) In-Reply-To: <4D2BB5F1.8030009@nict.go.jp> References: <20110106191502.10151.87573.idtracker@localhost> <002701cbaf12$43eabb00$cbc03100$@net> <4D2BB5F1.8030009@nict.go.jp> Date: Fri, 21 Jan 2011 10:27:15 -0500 Message-ID: From: Mark Jones To: Sebastien Decugis Content-Type: text/plain; charset=ISO-8859-1 Cc: dime@ietf.org Subject: Re: [Dime] WGLC for draft-ietf-dime-extended-naptr 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: , X-List-Received-Date: Fri, 21 Jan 2011 15:24:30 -0000 Hi Sebastian, On Mon, Jan 10, 2011 at 8:44 PM, Sebastien Decugis wrote: > Hi, > >>> Since The Diameter Base >>> protocol includes rudimentary accounting functionality it doesn't seem >>> completely unreasonable that Diameter Base might be used as a stand-alone >>> app. >> Ok, I hadn't appreciated that stand-alone usage of Base. Looking at >> section 7.1, it appears to be missing two entries: one for "aaa" and >> one for "aaa+ap0". The "aaa" entry could be deleted if rfc3588bis is >> published first. > If I understand correctly the discussion, I think you mean here > "aaa+ap3". Application 0 is used for the "one hop only" messages > (CER/CEA, DWR/DWA...) and is supported by ALL peers (so there is no > point in having it defined here). Application 3 is the "rudimentary > accounting functionality" defined in rfc3588(bis). > Good catch. I mistakenly thought base accounting used app id 0. As you point out, an app id of 0 is only used for CER/CEA, DWR/DWA, DPR/DPA so it does not appear useful as a stand-alone app. Unless someone has an example where "aaa+ap0" would be useful, I won't add it to the next rev. > I apologize if my remark is irrelevant... > Highly relevant. Thank you. Regards Mark From erez.nassimi@amdocs.com Mon Jan 24 05:48:49 2011 Return-Path: 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 7D0593A63D3 for ; Mon, 24 Jan 2011 05:48:49 -0800 (PST) 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 pFtqQmiaWU-3 for ; Mon, 24 Jan 2011 05:48:45 -0800 (PST) Received: from isomail1.amdocs.com (isomail1.amdocs.com [193.43.244.88]) by core3.amsl.com (Postfix) with ESMTP id 63BBB3A6AC4 for ; Mon, 24 Jan 2011 05:48:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by isomail1.amdocs.com (Postfix) with SMTP id EC99F7039A; Mon, 24 Jan 2011 15:51:37 +0200 (IST) Received: from ilhodmailfe2.corp.amdocs.com (unknown [10.236.20.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by isomail1.amdocs.com (Postfix) with ESMTPS id 63E8D7011D for ; Mon, 24 Jan 2011 15:51:29 +0200 (IST) Received: from ILHODMAIL1.corp.amdocs.com ([10.236.20.104]) by ilhodmailfe2.corp.amdocs.com ([10.236.20.101]) with mapi; Mon, 24 Jan 2011 15:51:29 +0200 From: Erez Nassimi To: "dime@ietf.org" Date: Mon, 24 Jan 2011 15:51:27 +0200 Thread-Topic: Diameter Group: Type? Thread-Index: Acu7zcw3QXkiybOzQuybqghTUo6vYg== Message-ID: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3EB9A6A055A0A74D816B7BA703D4054101A889BD37ILHODMAIL1cor_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 24 Jan 2011 08:06:50 -0800 Subject: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Mon, 24 Jan 2011 13:50:09 -0000 --_000_3EB9A6A055A0A74D816B7BA703D4054101A889BD37ILHODMAIL1cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To=20whom=20it=20may=20concern: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dealing=20with=20the=20Diameter=20standard=20for=20more=20than=202=20year= s,=20I=20always=20had=20the=20following=20question,=20I=20never=20dared= =20to=20ask.=20But=20even=20after=202=20years,=20I=20do=20not=20seem=20to= =20have=20a=20good=20answer=20for=20it: In=20RFC=203588,=20section=204.2=20-=20AVP=20Data=20Formats,=20"Grouped"= =20is=20defined=20as=20a=20"basic=20type".=20Doesn't=20it=20make=20more= =20sense=20to=20set=20a=20flag=20for=20Grouped=20AVP=20in=20flags=20secti= on?=20Group=20may=20be=20basic=20but=20it=20is=20not=20a=20real=20type.= =20It's=20just=20an=20indication=20of=20a=20complex=20data=20structure. If=20"Grouped"=20is=20defined=20as=20a=20flag,=20it=20will=20simplify=20a= ny=20parser's=20work=20-=20and=20performance=20is=20such=20a=20rare=20res= ource. Thanks=20in=20advance, Erez=20Nassimi erezna@amdocs.com Desk=20:=20+972-9-77-86073 Cell=20:=20+972-54-7296230 Fax=20=20:=20+972-9-77-61783 Did=20you=20know...? With=20Amdocs'=20innovative=20new=20"Turbo=20Charging"=20com= plex=20event=20processing=20technology,=20service=20providers=20can=20pro= cess=20thousands=20of=20charging=20events=20per=20CPU=20in=20real-time=20= over=20low-cost=20hardware=20(like=20blade=20servers),=20all=20with=20the= =20comprehensive=20functionality=20of=20Amdocs=20CES=20-=20Billing=207.5. This=20message=20and=20the=20information=20contained=20herein=20is=20prop= rietary=20and=20confidential=20and=20subject=20to=20the=20Amdocs=20policy= =20statement, you=20may=20review=20at=20http://www.amdocs.com/email_disclaimer.asp --_000_3EB9A6A055A0A74D816B7BA703D4054101A889BD37ILHODMAIL1cor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable To=20whom=20it=20may=20concern:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

Dealing=20with=20the=20Diameter=20standard=20for= =20more=20than=202=20years,=20I=20always had=20the=20following=20question,=20I=20never=20dared=20to=20ask.=20But= =20even=20after=202=20years,=20I=20do not=20seem=20to=20have=20a=20good=20answer=20for=20it:

 

In=20RFC=203588,=20section=204.2=20–=20AVP= =20Data=20Formats,=20“Grouped” is=20defined=20as=20a=20“basic=20type”.=20Doesn’t=20it= =20make=20more=20sense=20to=20set a=20flag=20for=20Grouped=20AVP=20in=20flags=20section?=20Group=20may=20be= =20basic=20but=20it=20is=20not=20a real=20type.=20It’s=20just=20an=20indication=20of=20a=20complex=20d= ata=20structure.

 

If=20“Grouped”=20is=20defined=20as=20a= =20flag,=20it=20will simplify=20any=20parser’s=20work=20–=20and=20performance=20is= =20such=20a=20rare resource.

 

Thanks=20in=20advance,

Erez Nassimi

erezna@amd= ocs.com<= /b>

Desk :=20+972-9-77-86073

Cell :=20+972-54-7296230

Fax  :=20+972-9-77-61783

 

Did=20you= =20know…?

With=20Amdocs&#= 8217;=20innovative new=20“Turbo=20Charging”=20<= span style=3D'font-size:10.0pt'>complex=20event=20processing=20technology,=20service=20providers=20can=20proc= ess=20thousands=20of=20charging=20events=20per=20CPU= =20in=20real-time=20over low-cost=20hardware=20(like=20blade=20servers),=20all=20with=20the=20comp= rehensive functionality=20of=20Amdocs=20CES=20–=20Billing=207.5.

 

This=20me=
ssage=20and=20the=20information=20contained=20herein=20is=20proprietary=
=20and=20confidential=20and=20subject=20to=20the=20Amdocs=20policy=20stat=
ement,
you=20may=20review=20at=20http://www.amdocs.com/email_disclaimer.asp
--_000_3EB9A6A055A0A74D816B7BA703D4054101A889BD37ILHODMAIL1cor_-- From dlehmann@ulticom.com Mon Jan 24 13:10:05 2011 Return-Path: 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 CA17E3A696D for ; Mon, 24 Jan 2011 13:10:05 -0800 (PST) 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=[AWL=-0.000, 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 jwI1+JyyCBCk for ; Mon, 24 Jan 2011 13:10:04 -0800 (PST) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id B7E9F3A6A7F for ; Mon, 24 Jan 2011 13:10:02 -0800 (PST) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id F9A0924F45E24389; Mon, 24 Jan 2011 16:12:56 -0500 (EST) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p0OLCdWh002779; Mon, 24 Jan 2011 16:12:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBC0B.6EB6A05A" Date: Mon, 24 Jan 2011 16:12:39 -0500 Message-ID: In-Reply-To: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Group: Type? Thread-Index: Acu7zcw3QXkiybOzQuybqghTUo6vYgAOXkgA References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> From: "David Lehmann" To: "Erez Nassimi" , Received-SPF: pass Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Mon, 24 Jan 2011 21:10:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBC0B.6EB6A05A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJleiwNCg0KIA0KDQpJIGFncmVlIHRoZXJlIHNob3VsZCBiZSBhIGJpdCBpZGVudGlmeWluZyB0 aGUgZ3JvdXBlZCBBVlBzLg0KDQogDQoNCi0tDQoNCkRhdmlkIExlaG1hbm4NCg0KVWx0aWNvbSwg SW5jLg0KDQo4NTYtNzg3LTI5NTINCg0KIA0KDQpGcm9tOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmV6IE5hc3NpbWkN ClNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNCwgMjAxMSA4OjUxIEFNDQpUbzogZGltZUBpZXRmLm9y Zw0KU3ViamVjdDogW0RpbWVdIERpYW1ldGVyIEdyb3VwOiBUeXBlPw0KDQogDQoNClRvIHdob20g aXQgbWF5IGNvbmNlcm46DQoNCj09PT09PT09PT09PT09PT09PT09PT0NCg0KIA0KDQpEZWFsaW5n IHdpdGggdGhlIERpYW1ldGVyIHN0YW5kYXJkIGZvciBtb3JlIHRoYW4gMiB5ZWFycywgSSBhbHdh eXMgaGFkIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24sIEkgbmV2ZXIgZGFyZWQgdG8gYXNrLiBCdXQg ZXZlbiBhZnRlciAyIHllYXJzLCBJIGRvIG5vdCBzZWVtIHRvIGhhdmUgYSBnb29kIGFuc3dlciBm b3IgaXQ6DQoNCiANCg0KSW4gUkZDIDM1ODgsIHNlY3Rpb24gNC4yIOKAkyBBVlAgRGF0YSBGb3Jt YXRzLCDigJxHcm91cGVk4oCdIGlzIGRlZmluZWQgYXMgYSDigJxiYXNpYyB0eXBl4oCdLiBEb2Vz buKAmXQgaXQgbWFrZSBtb3JlIHNlbnNlIHRvIHNldCBhIGZsYWcgZm9yIEdyb3VwZWQgQVZQIGlu IGZsYWdzIHNlY3Rpb24/IEdyb3VwIG1heSBiZSBiYXNpYyBidXQgaXQgaXMgbm90IGEgcmVhbCB0 eXBlLiBJdOKAmXMganVzdCBhbiBpbmRpY2F0aW9uIG9mIGEgY29tcGxleCBkYXRhIHN0cnVjdHVy ZS4NCg0KIA0KDQpJZiDigJxHcm91cGVk4oCdIGlzIGRlZmluZWQgYXMgYSBmbGFnLCBpdCB3aWxs IHNpbXBsaWZ5IGFueSBwYXJzZXLigJlzIHdvcmsg4oCTIGFuZCBwZXJmb3JtYW5jZSBpcyBzdWNo IGEgcmFyZSByZXNvdXJjZS4NCg0KIA0KDQpUaGFua3MgaW4gYWR2YW5jZSwNCg0KRXJleiBOYXNz aW1pDQoNCmVyZXpuYUBhbWRvY3MuY29tIDxtYWlsdG86ZXJlem5AaG90bWFpbC5jb20+IA0KDQpE ZXNrIDogKzk3Mi05LTc3LTg2MDczDQoNCkNlbGwgOiArOTcyLTU0LTcyOTYyMzANCg0KRmF4ICA6 ICs5NzItOS03Ny02MTc4Mw0KDQogDQoNCkRpZCB5b3Uga25vd+KApj8NCg0KV2l0aCBBbWRvY3Pi gJkgaW5ub3ZhdGl2ZSBuZXcg4oCcVHVyYm8gQ2hhcmdpbmfigJ0gPGh0dHA6Ly93d3cuYW1kb2Nz LmNvbS9TaXRlL05ld3MvTmV3cytBcnRpY2xlcy8yMDA4L1ByZXNzK1JlbGVhc2VzL1R1cmJvK0No YXJnaW5nLmh0bT4gIGNvbXBsZXggZXZlbnQgcHJvY2Vzc2luZyB0ZWNobm9sb2d5LCBzZXJ2aWNl IHByb3ZpZGVycyBjYW4gcHJvY2VzcyB0aG91c2FuZHMgb2YgY2hhcmdpbmcgZXZlbnRzIHBlciBD UFUgaW4gcmVhbC10aW1lIG92ZXIgbG93LWNvc3QgaGFyZHdhcmUgKGxpa2UgYmxhZGUgc2VydmVy cyksIGFsbCB3aXRoIHRoZSBjb21wcmVoZW5zaXZlIGZ1bmN0aW9uYWxpdHkgb2YgQW1kb2NzIENF UyDigJMgQmlsbGluZyA3LjUuDQoNCiANCg0KVGhpcyBtZXNzYWdlIGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm9wcmlldGFyeSBhbmQgY29uZmlkZW50aWFsIGFuZCBz dWJqZWN0IHRvIHRoZSBBbWRvY3MgcG9saWN5IHN0YXRlbWVudCwNCnlvdSBtYXkgcmV2aWV3IGF0 IGh0dHA6Ly93d3cuYW1kb2NzLmNvbS9lbWFpbF9kaXNjbGFpbWVyLmFzcA0KDQogDQoNCg== ------_=_NextPart_001_01CBBC0B.6EB6A05A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToy IDExIDYgOSAyIDIgNCAzIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNs YXNzPVdvcmRTZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5FcmV6LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SSBh Z3JlZSB0aGVyZSBzaG91bGQgYmUgYSBiaXQgaWRlbnRpZnlpbmcNCnRoZSBncm91cGVkIEFWUHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTQuMHB0O2NvbG9yOiMx RjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6IzFGNDk3RCc+RGF2aWQNCkxlaG1h bm48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6IzFGNDk3RCc+VWx0aWNvbSwgSW5jLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QnPjg1Ni03ODctMjk1MjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206 PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz4NCmRpbWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5FcmV6DQpOYXNzaW1pPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgSmFudWFyeSAyNCwgMjAxMSA4OjUxIEFNPGJyPg0KPGI+VG86 PC9iPiBkaW1lQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtEaW1lXSBEaWFtZXRlciBH cm91cDogVHlwZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+VG8gd2hvbSBpdCBtYXkgY29uY2Vybjo8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPj09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ RGVhbGluZyB3aXRoIHRoZSBEaWFtZXRlciBzdGFuZGFyZCBmb3IgbW9yZSB0aGFuIDIgeWVhcnMs IEkNCmFsd2F5cyBoYWQgdGhlIGZvbGxvd2luZyBxdWVzdGlvbiwgSSBuZXZlciBkYXJlZCB0byBh c2suIEJ1dCBldmVuIGFmdGVyIDINCnllYXJzLCBJIGRvIG5vdCBzZWVtIHRvIGhhdmUgYSBnb29k IGFuc3dlciBmb3IgaXQ6PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkluIFJGQyAzNTg4LCBzZWN0 aW9uIDQuMiDigJMgQVZQIERhdGEgRm9ybWF0cywg4oCcR3JvdXBlZOKAnSBpcw0KZGVmaW5lZCBh cyBhIOKAnGJhc2ljIHR5cGXigJ0uIERvZXNu4oCZdCBpdCBtYWtlIG1vcmUgc2Vuc2UgdG8gc2V0 IGEgZmxhZyBmb3IgR3JvdXBlZA0KQVZQIGluIGZsYWdzIHNlY3Rpb24/IEdyb3VwIG1heSBiZSBi YXNpYyBidXQgaXQgaXMgbm90IGEgcmVhbCB0eXBlLiBJdOKAmXMganVzdA0KYW4gaW5kaWNhdGlv biBvZiBhIGNvbXBsZXggZGF0YSBzdHJ1Y3R1cmUuPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPklm IOKAnEdyb3VwZWTigJ0gaXMgZGVmaW5lZCBhcyBhIGZsYWcsIGl0IHdpbGwgc2ltcGxpZnkgYW55 DQpwYXJzZXLigJlzIHdvcmsg4oCTIGFuZCBwZXJmb3JtYW5jZSBpcyBzdWNoIGEgcmFyZSByZXNv dXJjZS48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtzIGluIGFkdmFuY2UsPG86cD48L286 cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkVyZXoNCk5hc3NpbWk8L3NwYW4+PC9iPjxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YQ0KaHJlZj0ibWFpbHRvOmVy ZXpuQGhvdG1haWwuY29tIj5lcmV6bmFAYW1kb2NzLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5EZXNrDQo6ICs5NzItOS03Ny04NjA3Mzwv c3Bhbj48L2I+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkNlbGwNCjog Kzk3Mi01NC03Mjk2MjMwPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+RmF4Jm5ic3A7DQo6ICs5NzItOS03Ny02MTc4Mzwvc3Bhbj48L2I+PG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5EaWQg eW91IGtub3figKY/PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+V2l0aCBBbWRvY3PigJkgaW5u b3ZhdGl2ZSBuZXcgPGENCmhyZWY9Imh0dHA6Ly93d3cuYW1kb2NzLmNvbS9TaXRlL05ld3MvTmV3 cytBcnRpY2xlcy8yMDA4L1ByZXNzK1JlbGVhc2VzL1R1cmJvK0NoYXJnaW5nLmh0bSI+4oCcVHVy Ym8NCkNoYXJnaW5n4oCdPC9hPiBjb21wbGV4IGV2ZW50IHByb2Nlc3NpbmcgdGVjaG5vbG9neSwg c2VydmljZSBwcm92aWRlcnMgY2FuDQpwcm9jZXNzIHRob3VzYW5kcyBvZiBjaGFyZ2luZyBldmVu dHMgcGVyIENQVSBpbiByZWFsLXRpbWUgb3ZlciBsb3ctY29zdA0KaGFyZHdhcmUgKGxpa2UgYmxh ZGUgc2VydmVycyksIGFsbCB3aXRoIHRoZSBjb21wcmVoZW5zaXZlIGZ1bmN0aW9uYWxpdHkgb2YN CkFtZG9jcyBDRVMg4oCTIEJpbGxpbmcgNy41LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9k aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHRhYmxl IGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTA+DQogPHRyPg0KICA8 dGQgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVw dCc+PHByZT48c3Bhbg0KICBzdHlsZT0nY29sb3I6YmxhY2snPlRoaXMgbWVzc2FnZSBhbmQgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvcHJpZXRhcnkgYW5kIGNvbmZpZGVu dGlhbCBhbmQgc3ViamVjdCB0byB0aGUgQW1kb2NzIHBvbGljeSBzdGF0ZW1lbnQsPG86cD48L286 cD48L3NwYW4+PC9wcmU+PHByZT48c3Bhbg0KICBzdHlsZT0nY29sb3I6YmxhY2snPnlvdSBtYXkg cmV2aWV3IGF0IGh0dHA6Ly93d3cuYW1kb2NzLmNvbS9lbWFpbF9kaXNjbGFpbWVyLmFzcDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjwvdGQ+DQogPC90cj4NCjwvdGFibGU+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01CBBC0B.6EB6A05A-- From avi@bridgewatersystems.com Mon Jan 24 14:45:22 2011 Return-Path: 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 B33513A69B6 for ; Mon, 24 Jan 2011 14:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 PAWaTC7ye50D for ; Mon, 24 Jan 2011 14:45:21 -0800 (PST) Received: from mail51.messagelabs.com (mail51.messagelabs.com [216.82.241.99]) by core3.amsl.com (Postfix) with ESMTP id 00D2A28C0CF for ; Mon, 24 Jan 2011 14:45:20 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-11.tower-51.messagelabs.com!1295909295!69398603!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 2609 invoked from network); 24 Jan 2011 22:48:16 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-11.tower-51.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jan 2011 22:48:16 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Mon, 24 Jan 2011 17:48:15 -0500 From: Avi Lior To: Erez Nassimi , "dime@ietf.org" Date: Mon, 24 Jan 2011 17:48:13 -0500 Thread-Topic: [Dime] Diameter Group: Type? Thread-Index: Acu8GMkrJgV0YrX9Rmiu6CI/9T5QHg== Message-ID: In-Reply-To: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: multipart/alternative; boundary="_000_C9636A72C0C0avibridgewatersystemscom_" MIME-Version: 1.0 Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Mon, 24 Jan 2011 22:45:22 -0000 --_000_C9636A72C0C0avibridgewatersystemscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Well, Lets say you are right. Don't you think that this is a bit late? But I don't agree with you that a Group is not a kind of type and hence it = could be a basic type (if you get my meaning) Could you explain why do you think that a flag will simplify parsing? -- Avi Lior --Bridgewater Systems From: Erez Nassimi = > Date: Mon, 24 Jan 2011 08:51:27 -0500 To: "dime@ietf.org" > Subject: [Dime] Diameter Group: Type? To whom it may concern: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dealing with the Diameter standard for more than 2 years, I always had the = following question, I never dared to ask. But even after 2 years, I do not = seem to have a good answer for it: In RFC 3588, section 4.2 =96 AVP Data Formats, =93Grouped=94 is defined as = a =93basic type=94. Doesn=92t it make more sense to set a flag for Grouped = AVP in flags section? Group may be basic but it is not areal type. It=92s j= ust an indication of a complex data structure. If =93Grouped=94 is defined as a flag, it will simplify any parser=92s work= =96 and performance is such a rare resource. Thanks in advance, Erez Nassimi erezna@amdocs.com Desk : +972-9-77-86073 Cell : +972-54-7296230 Fax : +972-9-77-61783 Did you know=85? With Amdocs=92 innovative new =93Turbo Charging=94 complex event= processing technology, service providers can process thousands of charging= events per CPU in real-time over low-cost hardware (like blade servers), a= ll with the comprehensive functionality of Amdocs CES =96 Billing 7.5. This message and the information contained herein is proprietary and confid= ential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp --_000_C9636A72C0C0avibridgewatersystemscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Well, Lets say y= ou are right.  Don't you think that this is a bit late?

=
But I don't agree with you that a Group is not a kind of type an= d hence it could be a basic type (if you get my meaning)

Could you explain why do you think that a flag will simplify parsing= ?

-- Avi Lior
--Bridgewater Sy= stems


From: Erez Nassimi <erez.nassimi@amdocs.com>
Date: Mon, 24 Jan 2011 08:51:27 -0500
To: "dime@ietf.org" <dime@ietf= .org>
Subject: [Dime] Di= ameter Group: Type?

To whom it m= ay concern:

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Dealing with the Diameter = standard for more than 2 years, I always had the following question, I never dared to ask. But even after 2 years, I= do not seem to have a good answer for it:

 

In RFC 3588, section 4.2 =96 A= VP Data Formats, =93Grouped=94 is defined as a =93basic type=94. Doesn=92t it make more sense to set a flag for Grouped AVP in flags section? Group may be basic but it is not a= real type. It=92s just an indication of a complex data structure.

 

If = =93Grouped=94 is defined as a flag, it will simplify any parser=92s work =96 and performance is such a rare resource.

 

Thanks in advance,

Erez Nassimi

erezna@amdocs.com<= /o:p>

Desk : +972-9-77-86073

Cell : +972-54-7296230

Fax  : +972-9-77-61783

=  

Did you know=85?

With Amdocs=92 innovative new =93Turbo C= harging=94 complex event= processing technology, service pro= viders can process thousands of cha= rging events per CPU in real-time over low-cost hardware (like blade servers), all with the comprehensive functionality of Amdocs CES =96 Billing 7.5.

 

= 
This message and the information contained herein is pro=
prietary and confidential and subject to the Amdocs policy statement,
you may review at ht=
tp://www.amdocs.com/email_disclaimer.asp
 --_000_C9636A72C0C0avibridgewatersystemscom_-- From sdecugis@nict.go.jp Mon Jan 24 17:17:35 2011 Return-Path: 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 D12883A699F for ; Mon, 24 Jan 2011 17:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_FR=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 eWHJ9nK9Ul-4 for ; Mon, 24 Jan 2011 17:17:34 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 3A6EB3A6973 for ; Mon, 24 Jan 2011 17:17:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id CC46528064 for ; Tue, 25 Jan 2011 02:20:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdW0+cFiJz+R for ; Tue, 25 Jan 2011 02:20:06 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id EC43394119 for ; Tue, 25 Jan 2011 02:20:05 +0100 (CET) Message-ID: <4D3E2541.4000704@nict.go.jp> Date: Tue, 25 Jan 2011 10:20:01 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Tue, 25 Jan 2011 01:17:35 -0000 I agree with Avi, I think having the "grouped" information as a type makes more sense than as a flag. If the AVP code/vendor combination is unknown in the local dictionary, there is no point in being able to "parse" the inside AVPs -- and I think doing so (which would be possible with a "G"rouped flag in AVP header) would actually do more harm than good. As you wrote, parser's performance is a resource not to be wasted. Therefore, what is the point of parsing the "inside" level of AVPs when you don't understand the semantics of the grouped AVP that surrond them ? Best regards, Sebastien. Le 25/01/2011 07:48, Avi Lior a écrit : > Well, Lets say you are right. Don't you think that this is a bit late? > > But I don't agree with you that a Group is not a kind of type and > hence it could be a basic type (if you get my meaning) > > Could you explain why do you think that a flag will simplify parsing? > > -- Avi Lior > --Bridgewater Systems > > > From: Erez Nassimi > > Date: Mon, 24 Jan 2011 08:51:27 -0500 > To: "dime@ietf.org " > > Subject: [Dime] Diameter Group: Type? > > To whom it may concern: > > ====================== > > > > Dealing with the Diameter standard for more than 2 years, I always had > the following question, I never dared to ask. But even after 2 years, > I do not seem to have a good answer for it: > > > > In RFC 3588, section 4.2 – AVP Data Formats, “Grouped” is defined as a > “basic type”. Doesn’t it make more sense to set a flag for Grouped AVP > in flags section? Group may be basic but it is not areal type. It’s > just an indication of a complex data structure. > > > > If “Grouped” is defined as a flag, it will simplify any parser’s work > – and performance is such a rare resource. > > > > Thanks in advance, > > *Erez Nassimi* > > *erezna@amdocs.com *** > > *Desk : +972-9-77-86073* > > *Cell : +972-54-7296230*** > > *Fax : +972-9-77-61783* > > > > */Did you know…?/* > > With Amdocs’ innovative new “Turbo Charging” > > complex event processing technology, service providers can process > thousands of charging events per CPU in real-time over low-cost > hardware (like blade servers), all with the comprehensive > functionality of Amdocs CES – Billing 7.5. > > > > This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, > you may review at http://www.amdocs.com/email_disclaimer.asp > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From isj-dime@i1.dk Tue Jan 25 03:38:29 2011 Return-Path: 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 A55063A63C9 for ; Tue, 25 Jan 2011 03:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=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 9LT953z1FSZY for ; Tue, 25 Jan 2011 03:38:28 -0800 (PST) Received: from i1.dk (port80.ds1-hk.adsl.cybercity.dk [212.242.60.147]) by core3.amsl.com (Postfix) with ESMTP id AB1C13A6A70 for ; Tue, 25 Jan 2011 03:38:28 -0800 (PST) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id 3AB175C0095 for ; Tue, 25 Jan 2011 12:41:24 +0100 (CET) Received: from isjsys (isjsys [10.0.0.2]) by i1.dk (Postfix) with ESMTP for ; Tue, 25 Jan 2011 12:41:24 +0100 (CET) From: Ivan Skytte =?iso-8859-1?q?J=F8rgensen?= To: dime@ietf.org Date: Tue, 25 Jan 2011 12:41:03 +0100 User-Agent: KMail/1.9.10 References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> In-Reply-To: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> X-Accept-Language: da, en, de MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201101251241.04033.isj-dime@i1.dk> Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Tue, 25 Jan 2011 11:38:29 -0000 On Monday 24 January 2011 14:51:27 Erez Nassimi wrote: > Dealing with the Diameter standard for more than 2 years, I always > had the following question, I never dared to ask. But even after 2 > years, I do not seem to have a good answer for it: > > In RFC 3588, section 4.2 - AVP Data Formats, "Grouped" is defined > as a "basic type". Doesn't it make more sense to set a flag for > Grouped AVP in flags section? Group may be basic but it is not a > real type. It's just an indication of a complex data structure. > > If "Grouped" is defined as a flag, it will simplify any parser's > work - and performance is such a rare resource. The payload format of an AVP is uniquely identified by the AVP code. This means that if you receive an unknown AVP then the only thing you can do is to check the M-bit. If the M-bit is unset then you must skip it. If the M-bit is set then the message must be failed. Knowing if the unknown AVP is actually a grouped AVP does not help you. If the hypothetical "G-bit" existed and was set on an unknown AVP why would the parser try to parse it? The only area I can think of where the hypothetical G-bit would help is when trying to parse raw TCP streams without knowing the vendor/application/specification (eg. wireshark) and the G-bit could help to parse the grouped AVPs for human inspection. /isj From erez.nassimi@amdocs.com Tue Jan 25 03:59:57 2011 Return-Path: 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 61E5A3A6B80 for ; Tue, 25 Jan 2011 03:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, 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 XOHLOL6HDEoB for ; Tue, 25 Jan 2011 03:59:56 -0800 (PST) Received: from isomail1.amdocs.com (isomail1.amdocs.com [193.43.244.88]) by core3.amsl.com (Postfix) with ESMTP id 89E123A6836 for ; Tue, 25 Jan 2011 03:59:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by isomail1.amdocs.com (Postfix) with SMTP id 1199170652; Tue, 25 Jan 2011 14:02:52 +0200 (IST) Received: from ilhodmailfe1.corp.amdocs.com (unknown [10.236.20.100]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by isomail1.amdocs.com (Postfix) with ESMTPS id D4227701C3 for ; Tue, 25 Jan 2011 14:02:42 +0200 (IST) Received: from ILHODMAIL1.corp.amdocs.com ([10.236.20.104]) by ilhodmailfe1.corp.amdocs.com ([10.236.20.100]) with mapi; Tue, 25 Jan 2011 14:02:42 +0200 From: Erez Nassimi To: "dime@ietf.org" Date: Tue, 25 Jan 2011 14:02:40 +0200 Thread-Topic: [Dime] Diameter Group: Type? Thread-Index: Acu8GMkrJgV0YrX9Rmiu6CI/9T5QHgAbnq8g Message-ID: <3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com> References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3EB9A6A055A0A74D816B7BA703D4054101A889C37FILHODMAIL1cor_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 25 Jan 2011 04:17:41 -0800 Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Tue, 25 Jan 2011 11:59:57 -0000 --_000_3EB9A6A055A0A74D816B7BA703D4054101A889C37FILHODMAIL1cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20Avi=20&=20Sebastian=20-=20and=20thank=20you=20David=20for=20the=20su= pport=20:-) A=20few=20comments=20and=20clarifications: 1.=20=20=20=20=20=20=20I=20don't=20think=20it's=20too=20late=20to=20add= =20a=20"G"rouped=20bit=20in=20flags.=20Adding=20a=20"G"=20bit,=20should= =20not=20revoke=20/=20replace=20Groups=20as=20type.=20It=20could=20be=20a= n=20additional=20feature. 2.=20=20=20=20=20=20=20By=20saying=20"Group=20may=20be=20basic",=20I=20me= an=20it=20may=20be=20a=20basic=20concept,=20but=20not=20a=20basic=20type. 3.=20=20=20=20=20=20=20Syntax=20parsing=20the=20inside=20level=20of=20AVP= 's=20might=20be=20very=20useful,=20when=20there=20is=20a=20need=20to=20fi= lter=20out=20irrelevant=20/=20incorrect=20messages=20as=20quick=20as=20po= ssible. 4.=20=20=20=20=20=20=20I=20think=20you=20would=20agree=20with=20me,=20tha= t=20when=20syntax=20parsing=20a=20Diameter=20message=20(for=20example=20t= o=20verify=20validity=20of=20the=20message),=20it=20would=20be=20faster= =20to=20identify=20a=20Group,=20without=20accessing=20any=20other=20data= =20structure.=20That's=20what=20I=20mean=20by=20performance=20improvement= . 5.=20=20=20=20=20=20=20It's=20clear=20that=20when=20reaching=20a=20semant= ic=20analysis=20phase=20of=20the=20Diameter=20message,=20one=20needs=20AL= L=20necessary=20info.=20Group=20or=20not=20Group,=20this=20is=20just=20a= =20small=20part=20of=20the=20info=20in=20that=20phase. 6.=20=20=20=20=20=20=20In=20any=20case,=20an=20additional=20"G"=20bit=20c= annot=20harm=20anything;=20since=20in=20the=20worst=20case=20the=20Group= =20type=20info=20still=20exists.=20So=20the=20"G"=20bit=20can=20be=20igno= red. 7.=20=20=20=20=20=20=20Also=20"calculating"=20the=20"G"=20bit=20when=20cr= eating=20a=20message=20should=20not=20be=20a=20burden,=20since=20the=20in= fo=20has=20to=20be=20there=20anyway. I=20hope=20I'm=20more=20clear=20now. Regards, Erez=20Nassimi This=20message=20and=20the=20information=20contained=20herein=20is=20prop= rietary=20and=20confidential=20and=20subject=20to=20the=20Amdocs=20policy= =20statement, you=20may=20review=20at=20http://www.amdocs.com/email_disclaimer.asp --_000_3EB9A6A055A0A74D816B7BA703D4054101A889C37FILHODMAIL1cor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi=20Avi=20&=20Se= bastian=20-=20and=20thank you=20David=20for=20the=20support=20:-)

 

A=20few=20comments=20= and=20clarifications:

 

1.       I don't=20think=20it's=20too=20late=20to=20add=20a=20"G"rouped=20= bit=20in=20flags.=20Adding=20a "G"=20bit,=20should=20not=20revoke=20/=20replace=20Groups=20as= =20type.=20It=20could=20be=20an additional=20feature.

2.       By saying=20"Group=20may=20be=20basic",=20I=20mean=20it=20may=20be= =20a=20basic=20concept,=20but not=20a=20basic=20type.

3.       Syntax parsing=20the=20inside=20level=20of=20AVP's=20might=20be=20very=20useful,= =20when=20there=20is=20a=20need=20to filter=20out=20irrelevant=20/=20incorrect=20messages=20as=20quick=20as=20= possible.

4.       I think=20you=20would=20agree=20with=20me,=20that=20when=20syntax=20parsing= =20a=20Diameter=20message=20(for example=20to=20verify=20validity=20of=20the=20message),=20it=20would=20be= =20faster=20to=20identify=20a Group,=20without=20accessing=20any=20other=20data=20structure.=20That's= =20what=20I=20mean=20by performance=20improvement.

5.       It's clear=20that=20when=20reaching=20a=20semantic=20analysis=20phase=20of=20t= he=20Diameter=20message,=20one needs=20ALL=20necessary=20info.=20Group=20or=20not=20Group,=20this=20is= =20just=20a=20small=20part=20of=20the info=20in=20that=20phase.

6.       In any=20case,=20an=20additional=20"G"=20bit=20cannot=20harm=20any= thing;=20since=20in=20the worst=20case=20the=20Group=20type=20info=20still=20exists.=20So=20the=20&= quot;G"=20bit=20can=20be ignored.

7.       Also "calculating"=20the=20"G"=20bit=20when=20creating=20a= =20message=20should not=20be=20a=20burden,=20since=20the=20info=20has=20to=20be=20there=20any= way.

 

I=20hope=20I'm=20more= =20clear=20now.

 

Regards,

Erez Nassimi

This=20me=
ssage=20and=20the=20information=20contained=20herein=20is=20proprietary=
=20and=20confidential=20and=20subject=20to=20the=20Amdocs=20policy=20stat=
ement,
you=20may=20review=20at=20http://www.amdocs.com/email_disclaimer.asp
--_000_3EB9A6A055A0A74D816B7BA703D4054101A889C37FILHODMAIL1cor_-- From jouni.nospam@gmail.com Tue Jan 25 05:05:00 2011 Return-Path: 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 E2F123A6BB9 for ; Tue, 25 Jan 2011 05:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 10Vtd8pMCERj for ; Tue, 25 Jan 2011 05:04:59 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6903D3A6BB8 for ; Tue, 25 Jan 2011 05:04:59 -0800 (PST) Received: by wwa36 with SMTP id 36so5720754wwa.13 for ; Tue, 25 Jan 2011 05:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=FdeZODXuQvJapmI2+qTEfLrcKGBiBjcnxPOrXV1TdJc=; b=hGfrNbr+7TZZHdQ1RdX7DXITXRy4RUrG1GVOYhYyW6Tv/3BHZ3VszhI+6o6eRO8NT6 m1ZUFa46lYQ/gUo+/1k4QW5kG8yvb5cJZaULd85raShjoBSN07q9Ph1aAgieiOaA5Avy wHa1b0BCT/DVH905Hug7+I6VHF45Vp/OO2CDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=dRCCvKbYXq1Wf6qI1pIx7UjBF1QtrL+/IbZlhTeJ21/S4rkYCUcCqR+VpWURxT3B9n 6Otz8eZJZOzoDowoCbzl1GBh7bi+4ACzHg8uTaebjZ+K4d/zZvNBX7b/BlXfCI26Kn7L N3FCkSRuNunfM9wdhMaGSHAx8y0Qs461Oq3S8= Received: by 10.216.10.208 with SMTP id 58mr4947989wev.14.1295960876252; Tue, 25 Jan 2011 05:07:56 -0800 (PST) Received: from [10.255.138.11] ([192.100.123.77]) by mx.google.com with ESMTPS id h39sm3128781wes.29.2011.01.25.05.07.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 05:07:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com> Date: Tue, 25 Jan 2011 15:07:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60F795B1-8600-4228-8D1B-1C2F0ACA8337@gmail.com> References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> <3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com> To: Erez Nassimi X-Mailer: Apple Mail (2.1078) Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Tue, 25 Jan 2011 13:05:01 -0000 Hi, On Jan 25, 2011, at 2:02 PM, Erez Nassimi wrote: > Hi Avi & Sebastian - and thank you David for the support :-) > =20 > A few comments and clarifications: > =20 > 1. I don't think it's too late to add a "G"rouped bit in flags. = Adding a "G" bit, should not revoke / replace Groups as type. It could = be an additional feature. If it is not broken or severely confusing, then adding a new optional = feature would just add new code and for no proper reason. > 2. By saying "Group may be basic", I mean it may be a basic = concept, but not a basic type. > 3. Syntax parsing the inside level of AVP's might be very = useful, when there is a need to filter out irrelevant / incorrect = messages as quick as possible. If you do not understand the grouped AVP, then depending on the M bit, I = either do not care the whole grouped AVP or return an error pointing to = the grouped APV, not the contents of it. > 4. I think you would agree with me, that when syntax parsing a = Diameter message (for example to verify validity of the message), it = would be faster to identify a Group, without accessing any other data = structure. That's what I mean by performance improvement. I agree that it could be a performance enhancement. However, you would = need to access the dictionary for the AVPs inside the group anyway. = Depending how your per application dictionaries are handled, the = performance gain might be subtle. > 5. It's clear that when reaching a semantic analysis phase of = the Diameter message, one needs ALL necessary info. Group or not Group, = this is just a small part of the info in that phase. > 6. In any case, an additional "G" bit cannot harm anything; = since in the worst case the Group type info still exists. So the "G" bit = can be ignored. It can make stupid parsers to break who expect to receive a 0 in place = of G bit.. > 7. Also "calculating" the "G" bit when creating a message should = not be a burden, since the info has to be there anyway. Right. - Jouni > =20 > I hope I'm more clear now. > =20 > Regards, > Erez Nassimi > This message and the information contained herein is proprietary and = confidential and subject to the Amdocs policy statement, > you may review at=20 > http://www.amdocs.com/email_disclaimer.asp > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From mark@azu.ca Tue Jan 25 05:30:01 2011 Return-Path: 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 E8A423A6858 for ; Tue, 25 Jan 2011 05:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 rhuejFkv4bKq for ; Tue, 25 Jan 2011 05:30:00 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A4EFA3A686D for ; Tue, 25 Jan 2011 05:30:00 -0800 (PST) Received: by qyk34 with SMTP id 34so4150580qyk.10 for ; Tue, 25 Jan 2011 05:32:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.85.207 with SMTP id p15mr4780832qcl.167.1295962377959; Tue, 25 Jan 2011 05:32:57 -0800 (PST) Received: by 10.229.219.197 with HTTP; Tue, 25 Jan 2011 05:32:57 -0800 (PST) In-Reply-To: <3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com> References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> <3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com> Date: Tue, 25 Jan 2011 14:32:57 +0100 Message-ID: From: Mark Jones To: Erez Nassimi Content-Type: multipart/alternative; boundary=00163683206c2e3934049aabc1a9 Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Tue, 25 Jan 2011 13:30:02 -0000 --00163683206c2e3934049aabc1a9 Content-Type: text/plain; charset=ISO-8859-1 Hi Erez, The G-bit addition would not be backwards compatible with implementations of existing Diameter applications. Looking at section 4.1 in RFC3588: The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. This text appears to allow the definition of your G-bit in some future Diameter applications (though I wonder if this is a bug in the RFC which should read "subsequent Diameter versions"). However implementations of existing Diameter applications SHOULD reject the AVPs with your G-bit set and return a permanent failure of DIAMETER_INVALID_AVP_BITS. How do you propose to make the G-bit addition harmless to existing implementations? Regards Mark --00163683206c2e3934049aabc1a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Erez,

The G-bit addition would not be backwards compatible with i= mplementations of existing Diameter applications. Looking at section 4.1 in= RFC3588:

=A0=A0=A0=A0=A0 The 'r' (reserved) bits are unused= and SHOULD be set
=A0=A0=A0=A0=A0 to 0.=A0 Note that subsequent Diameter applications MAY def= ine
=A0=A0=A0=A0=A0 additional bits within the AVP Header, and an unreco= gnized bit
=A0=A0=A0=A0=A0 SHOULD be considered an error.

This te= xt appears to allow the definition of your G-bit in some future Diameter ap= plications (though I wonder if this is a bug in the RFC which should read &= quot;subsequent Diameter versions"). However implementations of existi= ng Diameter applications SHOULD reject the AVPs with your G-bit set and ret= urn a permanent failure of DIAMETER_INVALID_AVP_BITS.

How do you propose to make the G-bit addition harmless to existing impl= ementations?

Regards
Mark

--00163683206c2e3934049aabc1a9-- From dromasca@avaya.com Tue Jan 25 05:36:17 2011 Return-Path: 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 8645B3A6BBB for ; Tue, 25 Jan 2011 05:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 j2mn5LTwCPml for ; Tue, 25 Jan 2011 05:36:16 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 717743A6874 for ; Tue, 25 Jan 2011 05:36:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAMpgPk3GmAcF/2dsb2JhbACWUY4ec6NBApkagniCVwSQCQ X-IronPort-AV: E=Sophos;i="4.60,374,1291611600"; d="scan'208";a="229172311" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jan 2011 08:39:12 -0500 X-IronPort-AV: E=Sophos;i="4.60,374,1291611600"; d="scan'208";a="574552339" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jan 2011 08:39:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jan 2011 14:39:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review for draft-ietf-dime-nat-control-06 Thread-Index: Acu8lT3ibifh6lU0Tpy5/flLeDHB8g== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review for draft-ietf-dime-nat-control-06 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: , X-List-Received-Date: Tue, 25 Jan 2011 13:36:17 -0000 Please find below the AD review of draft-ietf-dime-nat-control-06. While the document is well written and in pretty good shape, there are a number of issues that need to be clarified and editorial nits that need to be cleaned up before the document can be sent to IETF Last Call.=20 The comments below are divided into T (Technical) and E (Editorial).=20 T1. Section 4.3 - Please explain what happens with the bindings existing prior to the reception of the Session Re-Authorization request in case of a BINDING_FAILEURE. Are these left in place?=20 T2. Section 4.6 > The DNCA relies on DNCA Manager and DNCA Agent to have builtin redundancy support to recover state in case of failure. It looks like this requirement needs to be expressed in stronger terms, maybe as a 2119 MUST.=20 T3. What does the following mean in section 5.5?=20 > Diameter applications conforming to this specification MUST advertise support by including the value of TBD in: T4. The way [RFC4005] is referenced in section 8.3 implies that a Normative Reference is required.=20 T5. The security requirements in sections 5.1 and 12 seem to be contradictory. While in section 12 it is stipulated that=20 > Securing the information exchange between the authorizing entity (the DNCA Manager) and the NAT device requires bilateral authentication of the involved parties, authorization of the involved parties to perform the required procedures and functions, and procedures to ensure integrity and confidentiality of the information exchange In section 5.1 identity verification and authorization of procedures are only MAY.=20 E1. idnits complains about the following:=20 tmp/draft-ietf-dime-nat-control-06.txt(1298): Line has weird spacing: '...ly with wit...' tmp/draft-ietf-dime-nat-control-06.txt(1828): Unexpected reference format: '...ocol,[RFC3588] to r...' E2. Section 1:=20 > The query functionality complements alternative information query mechanisms, such as Simple Network Management Protocol (SNMP) based mechanisms, if available. What does exactly 'complements' mean here?=20 E3. Expand LSN or include the abbreviation in the Conventions section E4. Chose one formulation - either 'The DNCA' or 'DNCA' E5. Section 3.3 - s/Diameter NAT Control Manager/DNCA Manager/ E6. Write in a consistent manner DNCA Agent (and not DNCA agent as in section 4.1) E7. Section 4.2: s/Figure 5 shows the protocol interaction/Figure 5 shows the initial protocol interaction/ E8. Section 4.3 s/perfborm/perform/ E9. RFC 3588 is sometimes mentioned as 3588, other times as [RFC3588] - the latest seems to be better =20 Thanks and Regards, Dan From dlehmann@ulticom.com Tue Jan 25 07:02:04 2011 Return-Path: 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 A38863A67EA for ; Tue, 25 Jan 2011 07:02:04 -0800 (PST) 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=[AWL=-0.000, 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 6H9EeLQ+Q3uL for ; Tue, 25 Jan 2011 07:02:03 -0800 (PST) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 8FB4D3A67E9 for ; Tue, 25 Jan 2011 07:02:03 -0800 (PST) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id FCD8B04D05E22413; Tue, 25 Jan 2011 10:04:52 -0500 (EST) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p0PF4Tv2002610; Tue, 25 Jan 2011 10:04:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBCA1.2A309F0E" Date: Tue, 25 Jan 2011 10:04:29 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Group: Type? Thread-Index: Acu8lGahSFqXuhBqSgmjeTPnxzsbYQADCv1A References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com><3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com> From: "David Lehmann" To: "Mark Jones" , "Erez Nassimi" Received-SPF: pass Cc: dime@ietf.org Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Tue, 25 Jan 2011 15:02:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBCA1.2A309F0E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree the RFC text should read "subsequent Diameter versions". Applications should not be defining new flags. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Mark Jones Sent: Tuesday, January 25, 2011 8:33 AM To: Erez Nassimi Cc: dime@ietf.org Subject: Re: [Dime] Diameter Group: Type? =20 Hi Erez, The G-bit addition would not be backwards compatible with implementations of existing Diameter applications. Looking at section 4.1 in RFC3588: The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. This text appears to allow the definition of your G-bit in some future Diameter applications (though I wonder if this is a bug in the RFC which should read "subsequent Diameter versions"). However implementations of existing Diameter applications SHOULD reject the AVPs with your G-bit set and return a permanent failure of DIAMETER_INVALID_AVP_BITS.=20 How do you propose to make the G-bit addition harmless to existing implementations? Regards Mark ------_=_NextPart_001_01CBBCA1.2A309F0E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree the RFC text should read "subsequent= Diameter versions".  Applications should not be defining new = flags.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Mark Jones
Sent: Tuesday, January 25, 2011 8:33 AM
To: Erez Nassimi
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Group: Type?

 

Hi Erez,

The G-bit addition would not be backwards compatible with = implementations of existing Diameter applications. Looking at section 4.1 in RFC3588:

      The 'r' (reserved) bits are unused and = SHOULD be set
      to 0.  Note that subsequent Diameter applications MAY define
      additional bits within the AVP Header, = and an unrecognized bit
      SHOULD be considered an error.

This text appears to allow the definition of your G-bit in some future = Diameter applications (though I wonder if this is a bug in the RFC which should = read "subsequent Diameter versions"). However implementations of = existing Diameter applications SHOULD reject the AVPs with your G-bit set and = return a permanent failure of DIAMETER_INVALID_AVP_BITS.

How do you propose to make the G-bit addition harmless to existing implementations?

Regards
Mark

------_=_NextPart_001_01CBBCA1.2A309F0E-- From dlehmann@ulticom.com Tue Jan 25 07:13:05 2011 Return-Path: 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 B1FE53A6800 for ; Tue, 25 Jan 2011 07:13:05 -0800 (PST) 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=[AWL=-0.000, 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 FQtVjMwJxjjA for ; Tue, 25 Jan 2011 07:13:01 -0800 (PST) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id BA79D3A67FD for ; Tue, 25 Jan 2011 07:13:00 -0800 (PST) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 3695815D01C2847D; Tue, 25 Jan 2011 10:15:57 -0500 (EST) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p0PFFrk2002841; Tue, 25 Jan 2011 10:15:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBCA2.C1C776BE" Date: Tue, 25 Jan 2011 10:13:16 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Group: Type? Thread-Index: Acu8lGahSFqXuhBqSgmjeTPnxzsbYQADCv1AAAA/ydA= References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com><3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com> From: "David Lehmann" To: "Mark Jones" , "Erez Nassimi" Received-SPF: pass Cc: dime@ietf.org Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Tue, 25 Jan 2011 15:13:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBCA2.C1C776BE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition, I don't know if it is wise to consider it an error if received reserved bits are nonzero. It limits future expansion, like the one suggested. =20 The IETF mantra is "Be strict when sending, but liberal on receiving." Notice SCTP's spec on chunk flags: RFC 4960, section 3.2: Chunk Flags: 8 bits =20 The usage of these bits depends on the Chunk type as given by the Chunk Type field. Unless otherwise specified, they are set to 0 on transmit and are ignored on receipt. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of David Lehmann Sent: Tuesday, January 25, 2011 10:04 AM To: Mark Jones; Erez Nassimi Cc: dime@ietf.org Subject: Re: [Dime] Diameter Group: Type? =20 I agree the RFC text should read "subsequent Diameter versions". Applications should not be defining new flags. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Mark Jones Sent: Tuesday, January 25, 2011 8:33 AM To: Erez Nassimi Cc: dime@ietf.org Subject: Re: [Dime] Diameter Group: Type? =20 Hi Erez, The G-bit addition would not be backwards compatible with implementations of existing Diameter applications. Looking at section 4.1 in RFC3588: The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. This text appears to allow the definition of your G-bit in some future Diameter applications (though I wonder if this is a bug in the RFC which should read "subsequent Diameter versions"). However implementations of existing Diameter applications SHOULD reject the AVPs with your G-bit set and return a permanent failure of DIAMETER_INVALID_AVP_BITS.=20 How do you propose to make the G-bit addition harmless to existing implementations? Regards Mark ------_=_NextPart_001_01CBBCA2.C1C776BE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In addition, I don’t know if it is wise to consider = it an error if received reserved bits are nonzero.  It limits future = expansion, like the one suggested.

 

The IETF mantra is “Be strict when sending, but = liberal on receiving.”  Notice SCTP’s spec on chunk = flags:

RFC 4960, section 3.2:

  Chunk Flags: 8 bits

 

      The usage of these bits depends on the Chunk type as given by = the

      Chunk Type field.  Unless otherwise specified, they are set to = 0

      on transmit and are ignored on receipt.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = David Lehmann
Sent: Tuesday, January 25, 2011 10:04 AM
To: Mark Jones; Erez Nassimi
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Group: Type?

 

I agree the RFC text should read "subsequent = Diameter versions".  Applications should not be defining new = flags.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Mark Jones
Sent: Tuesday, January 25, 2011 8:33 AM
To: Erez Nassimi
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Group: Type?

 

Hi Erez,

The G-bit addition would not be backwards compatible with = implementations of existing Diameter applications. Looking at section 4.1 in RFC3588:

      The 'r' (reserved) bits are unused and = SHOULD be set
      to 0.  Note that subsequent Diameter applications MAY define
      additional bits within the AVP Header, = and an unrecognized bit
      SHOULD be considered an error.

This text appears to allow the definition of your G-bit in some future = Diameter applications (though I wonder if this is a bug in the RFC which should = read "subsequent Diameter versions"). However implementations of = existing Diameter applications SHOULD reject the AVPs with your G-bit set and = return a permanent failure of DIAMETER_INVALID_AVP_BITS.

How do you propose to make the G-bit addition harmless to existing implementations?

Regards
Mark

------_=_NextPart_001_01CBBCA2.C1C776BE-- From sdecugis@nict.go.jp Tue Jan 25 18:29:19 2011 Return-Path: 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 3BB323A6900 for ; Tue, 25 Jan 2011 18:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=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 fUttycjC0b4S for ; Tue, 25 Jan 2011 18:29:18 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 2E0A43A68D5 for ; Tue, 25 Jan 2011 18:29:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 59670948E8 for ; Wed, 26 Jan 2011 03:31:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9xWXNGkdI61 for ; Wed, 26 Jan 2011 03:31:56 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 15D8A940BA for ; Wed, 26 Jan 2011 03:31:55 +0100 (CET) Message-ID: <4D3F8796.1090100@nict.go.jp> Date: Wed, 26 Jan 2011 11:31:50 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] draft-ietf-dime-rfc3588bis-26 Result-Code values 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: , X-List-Received-Date: Wed, 26 Jan 2011 02:29:19 -0000 Hello, I just compared the Result-Code values described in rfc3588bis-26 section 7.1.x with existing IANA registry, and found several differences, which are currently not reflected in the IANA Considerations section -- I believe someone is already working on this section (although I lost track of whom) so I thought I would write down the differences I found to help in this work -- I hope this is not redundant. DIAMETER_COMMAND_UNSUPPORTED: - value 3001 in IANA registry, - value 5019 in 3588bis. DIAMETER_INVALID_HDR_BITS: - value 3008 in IANA, - value 5020 in 3588bis - also, DIAMETER_INVALID_AVP_BITS: - value 3009 in IANA, - value 5021 in rfc3588bis DIAMETER_UNKNOWN_PEER: - value 3010 in IANA, - value 5018 in rfc3588bis (conflicts with IANA) DIAMETER_INVALID_BIT_IN_HEADER: - 5013 in IANA, - 3011 in rfc3588bis - seems redundant with DIAMETER_INVALID_HDR_BITS. DIAMETER_INVALID_MESSAGE_LENGTH: - value 5015 in IANA, - value 3012 in rfc3588bis DIAMETER_INVALID_AVP_BIT_COMBO: - value 5016 in IANA - not defined in rfc3588bis - is it deprecated? it seems redundant with DIAMETER_INVALID_AVP_BITS anyway... Hope this helps, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Tue Jan 25 21:31:56 2011 Return-Path: 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 6EF553A6925 for ; Tue, 25 Jan 2011 21:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 MZ9XeQ5vNQGW for ; Tue, 25 Jan 2011 21:31:54 -0800 (PST) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id 948223A6924 for ; Tue, 25 Jan 2011 21:31:53 -0800 (PST) Received: (qmail 25579 invoked from network); 26 Jan 2011 05:34:53 -0000 Received: from unknown (110.168.105.250) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 26 Jan 2011 05:34:52 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4D3F8796.1090100@nict.go.jp> In-Reply-To: <4D3F8796.1090100@nict.go.jp> Date: Wed, 26 Jan 2011 12:34:43 +0700 Organization: Network Zen Message-ID: <019f01cbbd1a$be861a10$3b924e30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu9AUH+IYaVfQViQ7ODCRnVVboP8gAGP47g Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis-26 Result-Code values 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: , X-List-Received-Date: Wed, 26 Jan 2011 05:31:56 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > Hello, > > I just compared the Result-Code values described in rfc3588bis-26 > section 7.1.x with existing IANA registry, and found several > differences, which are currently not reflected in the IANA > Considerations section -- I believe someone is already working on this > section (although I lost track of whom) so I thought I would write down > the differences I found to help in this work -- I hope this is not > redundant. Actually, I think that the redundant things are the lists of values themselves. They made sense in 3588, since that doc was actually requesting allocation of the values but should be replaced with references to the relevant IANA registry in bis. ... From sdecugis@nict.go.jp Tue Jan 25 22:27:56 2011 Return-Path: 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 029AC3A6932 for ; Tue, 25 Jan 2011 22:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_FR=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 zdjbHtrxkU2Z for ; Tue, 25 Jan 2011 22:27:54 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 3A0723A6843 for ; Tue, 25 Jan 2011 22:27:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 226FD948E8; Wed, 26 Jan 2011 07:30:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIRfWDp30DKd; Wed, 26 Jan 2011 07:30:33 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 5334794119; Wed, 26 Jan 2011 07:30:31 +0100 (CET) Message-ID: <4D3FBF82.4030506@nict.go.jp> Date: Wed, 26 Jan 2011 15:30:26 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Glen Zorn References: <4D3F8796.1090100@nict.go.jp> <019f01cbbd1a$be861a10$3b924e30$@net> In-Reply-To: <019f01cbbd1a$be861a10$3b924e30$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis-26 Result-Code values 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: , X-List-Received-Date: Wed, 26 Jan 2011 06:27:56 -0000 Hi Glen, > Actually, I think that the redundant things are the lists of values > themselves. They made sense in 3588, since that doc was actually requesting > allocation of the values but should be replaced with references to the > relevant IANA registry in bis. I agree with regard to the values that are unchanged between 3588 & bis. However, what about for example DIAMETER_COMMAND_UNSUPPORTED which was defined as 3xxx (protocol error) in 3588, but is now in range 5xxx (permanent failure) in bis ? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From erez.nassimi@amdocs.com Thu Jan 27 16:17:32 2011 Return-Path: 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 2513C3A6B0D for ; Thu, 27 Jan 2011 16:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, 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 9GNQpYJ2KLts for ; Thu, 27 Jan 2011 16:17:30 -0800 (PST) Received: from isomail1.amdocs.com (isomail1.amdocs.com [193.43.244.88]) by core3.amsl.com (Postfix) with ESMTP id 652773A6AFD for ; Thu, 27 Jan 2011 16:17:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by isomail1.amdocs.com (Postfix) with SMTP id B2A9D706B8; Fri, 28 Jan 2011 02:20:32 +0200 (IST) Received: from ilhodmailfe2.corp.amdocs.com (unknown [10.236.20.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by isomail1.amdocs.com (Postfix) with ESMTPS id 9E7D9706B8; Fri, 28 Jan 2011 02:20:29 +0200 (IST) Received: from ILHODMAIL1.corp.amdocs.com ([10.236.20.104]) by ilhodmailfe2.corp.amdocs.com ([10.236.20.101]) with mapi; Fri, 28 Jan 2011 02:20:29 +0200 From: Erez Nassimi To: "dime@ietf.org" Date: Fri, 28 Jan 2011 02:20:27 +0200 Thread-Topic: RE: [Dime] Diameter Group: Type? Thread-Index: Acu+gSnJJHP84QzsSm6O3Ho9MgQSZg== Message-ID: <3EB9A6A055A0A74D816B7BA703D4054101A8963DCF@ILHODMAIL1.corp.amdocs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3EB9A6A055A0A74D816B7BA703D4054101A8963DCFILHODMAIL1cor_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 28 Jan 2011 00:01:38 -0800 Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Fri, 28 Jan 2011 00:17:32 -0000 --_000_3EB9A6A055A0A74D816B7BA703D4054101A8963DCFILHODMAIL1cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, Thank=20you=20for=20the=20comments.=20I=20think=20everyone=20agrees=20the= re=20is=20a=20bug=20in=20RFC.=20But=20this=20can=20lead=20us=20to=202=20d= ifferent=20interpretations: 1.=20=20Based=20on=20"an=20unrecognized=20bit=20SHOULD=20be=20considered= =20an=20error",=20we=20could=20assume=20that=20"subsequent=20Diameter=20a= pplications=20MAY=20define=20additional=20bits=20within=20the=20AVP=20Hea= der",=20should=20have=20read=20"subsequent=20Diameter=20versions". 2.=20=20But=20the=20words=20are=20very=20clear=20and=20as=20of=20now=20it= =20says=20"subsequent=20Diameter=20applications". In=20any=20case,=20my=20point=20was=20rather=20conceptual=20than=20techni= cal.=20Defining=20a=20Grouped=20AVP=20as=20a=20type,=20is=20similar=20to= =20classifying=20C++=20classes=20in=20the=20same=20category=20as=20simple= =20types=20as=20int,=20char,=20etc.=20There=20is=20a=20difference=20after= =20all.=20I=20found=20it=20important=20enough=20to=20differentiate=20betw= een=20them=20with=20a=20"G"=20bit. Regards, Erez=20Nassimi This=20message=20and=20the=20information=20contained=20herein=20is=20prop= rietary=20and=20confidential=20and=20subject=20to=20the=20Amdocs=20policy= =20statement, you=20may=20review=20at=20http://www.amdocs.com/email_disclaimer.asp --_000_3EB9A6A055A0A74D816B7BA703D4054101A8963DCFILHODMAIL1cor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Guys= ,

 

Thank=20you=20for=20the=20comment=
s.=20I=20think=20everyone=20agrees=20there=20is=20a=20bug=20in=20RFC.=20B=
ut=20this=20can=20lead=20us=20to=202=20different=20interpretations:<=
/o:p>
1. =20Based=20on=20“a=
n=20unrecognized=20bit=20SHOULD=20be=20considered=20an=20error”,=20=
we=20could=20assume=20that=20“subsequent=20Diameter=20applications=
=20MAY=20define=20additional=20bits=20within=20the=20AVP=20Header”,=
=20should=20have=20read=20“subsequent=20Diameter=20versions”.=

2. =20But=20the=20words=20a=
re=20very=20clear=20and=20as=20of=20now=20it=20says=20“subsequent=
=20Diameter=20applications”.
In= =20any=20case,=20my point=20was=20rather=20conceptual=20than=20technical.=20Defining=20a=20Gr= ouped=20AVP=20as=20a=20type, is=20similar=20to=20classifying=20C++=20classes=20in=20the=20same=20categ= ory=20as=20simple=20types=20as=20int, char,=20etc.=20There=20is=20a=20difference=20after=20all.=20I=20found=20i= t=20important=20enough=20to=20differentiate between=20them=20with=20a=20“G”=20bit.

 

Rega= rds,

Erez Nassimi

This=20me=
ssage=20and=20the=20information=20contained=20herein=20is=20proprietary=
=20and=20confidential=20and=20subject=20to=20the=20Amdocs=20policy=20stat=
ement,
you=20may=20review=20at=20http://www.amdocs.com/email_disclaimer.asp
--_000_3EB9A6A055A0A74D816B7BA703D4054101A8963DCFILHODMAIL1cor_-- From mark@azu.ca Fri Jan 28 04:10:35 2011 Return-Path: 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 E286B3A6804 for ; Fri, 28 Jan 2011 04:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gPRsv5-y6sO2 for ; Fri, 28 Jan 2011 04:10:33 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id AFC303A67EC for ; Fri, 28 Jan 2011 04:10:33 -0800 (PST) Received: by qyk34 with SMTP id 34so739158qyk.10 for ; Fri, 28 Jan 2011 04:13:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.84.203 with SMTP id k11mr874123qcl.281.1296216819040; Fri, 28 Jan 2011 04:13:39 -0800 (PST) Received: by 10.229.219.197 with HTTP; Fri, 28 Jan 2011 04:13:37 -0800 (PST) In-Reply-To: <3EB9A6A055A0A74D816B7BA703D4054101A8963DCF@ILHODMAIL1.corp.amdocs.com> References: <3EB9A6A055A0A74D816B7BA703D4054101A8963DCF@ILHODMAIL1.corp.amdocs.com> Date: Fri, 28 Jan 2011 13:13:37 +0100 Message-ID: From: Mark Jones To: Erez Nassimi Content-Type: multipart/alternative; boundary=0016364ef3220d12ea049ae6ff8a Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Fri, 28 Jan 2011 12:10:35 -0000 --0016364ef3220d12ea049ae6ff8a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Erez, Will you be raising an issue on 3588bis so the authors can fix this bug? Thanks Mark On Fri, Jan 28, 2011 at 1:20 AM, Erez Nassimi wrot= e: > Guys, > > > > Thank you for the comments. I think everyone agrees there is a bug in RFC= . But this can lead us to 2 different interpretations: > > 1. Based on =93an unrecognized bit SHOULD be considered an error=94, we = could assume that =93subsequent Diameter applications MAY define additional= bits within the AVP Header=94, should have read =93subsequent Diameter ver= sions=94. > > 2. But the words are very clear and as of now it says =93subsequent Diam= eter applications=94. > > In any case, my point was rather conceptual than technical. Defining a > Grouped AVP as a type, is similar to classifying C++ classes in the same > category as simple types as int, char, etc. There is a difference after a= ll. > I found it important enough to differentiate between them with a =93G=94 = bit. > > > > Regards, > > *Erez Nassimi* > > This message and the information contained herein is proprietary and conf= idential and subject to the Amdocs policy statement, > you may review at http://www.amdocs.com/email_disclaimer.asp > > --0016364ef3220d12ea049ae6ff8a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Erez,

Will you be raising an issue on 3588bis so the authors can= fix this bug?

Thanks
Mark

On F= ri, Jan 28, 2011 at 1:20 AM, Erez Nassimi <erez.nassimi@amdocs.com> wrot= e:

Thank you for the comments. I think e= veryone agrees there is a bug in RFC. But this can lead us to 2 different i= nterpretations:

1.=A0 Based on =93an unrecognized bit SHOULD be considered an e=
rror=94, we could assume that =93subsequent Diameter applications MAY defin=
e additional bits within the AVP Header=94, should have read =93subsequent =
Diameter versions=94.
2=
.=A0 <=
/span>But the wor=
ds are very clear and as of now it says =93subsequent Diameter applications=
=94.

Erez Nassimi

This=
 message and the information contained herein is proprietary and confidenti=
al and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
=

--0016364ef3220d12ea049ae6ff8a-- From jouni.nospam@gmail.com Fri Jan 28 05:23:27 2011 Return-Path: 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 2AFD13A688B for ; Fri, 28 Jan 2011 05:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 V7528jBiOPwN for ; Fri, 28 Jan 2011 05:23:26 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B2B213A67AD for ; Fri, 28 Jan 2011 05:23:25 -0800 (PST) Received: by wyf23 with SMTP id 23so3294895wyf.31 for ; Fri, 28 Jan 2011 05:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=1O2Aln5C8daAMtWFXzlHzQ5FbNa/g0NGdmwFU86jPDE=; b=Yb1zwzN9iaPJkAziP6ciKZ9mmfY40neIc32xBrRS7NAqrTr/9/mRkWb83cE63Mp4VM PH8GYweOEM4gUCh4JHA4ptTb+2XVCaxmtFpGexY9lzULi7g/J+xuufbgrbhUQ0uEK5qV Qutsxk9Mk48OePQaHucl2iyk/D5agqirto17E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=HA1mmAmMJcACDmmqfsrEXZR2SP5Y8xkQI0ek6MgjtzOoV+Yv5Du0O4wAaMl1z34wPv AHbsuTXuvxAiLYMy5oS9fDH/TTSf7THbgCaoj5LGApVRKAjz7fnuzH3C6nF26BKkzexQ pKjZO3SU4wXMiVKK30HObz7kS6AnFIjuUKHR0= Received: by 10.216.143.17 with SMTP id k17mr7548783wej.74.1296221191310; Fri, 28 Jan 2011 05:26:31 -0800 (PST) Received: from [10.255.136.113] ([192.100.123.77]) by mx.google.com with ESMTPS id u2sm6424036weh.12.2011.01.28.05.26.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 05:26:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: Date: Fri, 28 Jan 2011 15:26:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56FEA2B3-8A50-4606-B0F1-108A79C0A8DA@gmail.com> References: <3EB9A6A055A0A74D816B7BA703D4054101A8963DCF@ILHODMAIL1.corp.amdocs.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1078) Cc: Erez Nassimi Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Fri, 28 Jan 2011 13:23:27 -0000 I would encourage 3588bis authors to look into this specific place. I = also think it is an error that needs to be fixed. - Jouni On Jan 28, 2011, at 2:13 PM, Mark Jones wrote: > Hi Erez,=20 >=20 > Will you be raising an issue on 3588bis so the authors can fix this = bug? >=20 > Thanks > Mark >=20 > On Fri, Jan 28, 2011 at 1:20 AM, Erez Nassimi = wrote: > Guys, >=20 > =20 > Thank you for the comments. I think everyone agrees there is a bug in = RFC. But this can lead us to 2 different interpretations: > 1. Based on =93an unrecognized bit SHOULD be considered an error=94, = we could assume that =93subsequent Diameter applications MAY define = additional bits within the AVP Header=94, should have read =93subsequent = Diameter versions=94. > 2. But the words are very clear and as of now it says =93subsequent = Diameter applications=94. > In any case, my point was rather conceptual than technical. Defining a = Grouped AVP as a type, is similar to classifying C++ classes in the same = category as simple types as int, char, etc. There is a difference after = all. I found it important enough to differentiate between them with a = =93G=94 bit. >=20 > =20 > Regards, >=20 > Erez Nassimi >=20 > This message and the information contained herein is proprietary and = confidential and subject to the Amdocs policy statement, > you may review at=20 > http://www.amdocs.com/email_disclaimer.asp >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Fri Jan 28 21:58:38 2011 Return-Path: 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 B71513A696F for ; Fri, 28 Jan 2011 21:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 58phfH8QRkf6 for ; Fri, 28 Jan 2011 21:58:33 -0800 (PST) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id E6D913A6895 for ; Fri, 28 Jan 2011 21:58:32 -0800 (PST) Received: (qmail 4767 invoked from network); 29 Jan 2011 06:01:40 -0000 Received: from unknown (110.168.98.197) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 29 Jan 2011 06:01:39 -0000 From: "Glen Zorn" To: "'Mark Jones'" , "'Erez Nassimi'" References: <3EB9A6A055A0A74D816B7BA703D4054101A8963DCF@ILHODMAIL1.corp.amdocs.com> In-Reply-To: Date: Sat, 29 Jan 2011 13:01:23 +0700 Organization: Network Zen Message-ID: <015c01cbbf79$f7338d50$e59aa7f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_015D_01CBBFB4.A3926550" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu+5M/mNZrQwCZ/TnOZgI2vokQTrwAktllg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Diameter Group: Type? 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: , X-List-Received-Date: Sat, 29 Jan 2011 05:58:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_015D_01CBBFB4.A3926550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark Jones [mailto://mark@azu.ca] writes: Hi Erez, Will you be raising an issue on 3588bis so the authors can fix this bug? Maybe it's just me, but I'm having a hard time finding a bug here (certainly not in the same category as the IANA mess): Diameter applications can define AVPs, so why not the flags for those AVPs, as well? As for subsequent versions of Diameter, those future versions (if any) don't need the permission of 3588bis to change anything at all... Thanks Mark On Fri, Jan 28, 2011 at 1:20 AM, Erez Nassimi wrote: Guys, Thank you for the comments. I think everyone agrees there is a bug in RFC. But this can lead us to 2 different interpretations: 1. Based on "an unrecognized bit SHOULD be considered an error", we could assume that "subsequent Diameter applications MAY define additional bits within the AVP Header", should have read "subsequent Diameter versions". 2. But the words are very clear and as of now it says "subsequent Diameter applications". In any case, my point was rather conceptual than technical. Defining a Grouped AVP as a type, is similar to classifying C++ classes in the same category as simple types as int, char, etc. There is a difference after all. A different (& more accurate IMHO) example would be the difference between an int & a float. ------=_NextPart_000_015D_01CBBFB4.A3926550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark Jones [mailto://mark@azu.ca] = writes:

 

Hi Erez, =

Will you be raising an issue on 3588bis so the authors can fix = this bug?

Maybe it’s just me, but = I’m having a hard time finding a bug here (certainly not in the = same category as the IANA mess): Diameter applications can define AVPs, = so why not the flags for those AVPs, as well?  As for subsequent = versions of Diameter, those future versions (if any) don’t need = the permission of 3588bis to change anything at = all...



Thanks
Mark

=

On Fri, Jan 28, 2011 at 1:20 AM, Erez Nassimi = <erez.nassimi@amdocs.com> = wrote:

Guys,

 

Thank you for the comments. I think everyone =
agrees there is a bug in RFC. But this can lead us to 2 different =
interpretations:
1.  =
Based on “an unrecognized =
bit SHOULD be considered an error”, we could assume that =
“subsequent Diameter applications MAY define additional bits =
within the AVP Header”, should have read “subsequent =
Diameter versions”.
2.  =
But the words are very clear and =
as of now it says “subsequent Diameter =
applications”.

In any case, my point was rather = conceptual than technical. Defining a Grouped AVP as a type, is similar = to classifying C++ classes in the same category as simple types as int, = char, etc. There is a difference after all.

A different (& more accurate = IMHO) example would be the difference between an int & a = float.

------=_NextPart_000_015D_01CBBFB4.A3926550-- From gwz@net-zen.net Fri Jan 28 22:04:44 2011 Return-Path: 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 BBF463A696D for ; Fri, 28 Jan 2011 22:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 vvsqcDe2k0oH for ; Fri, 28 Jan 2011 22:04:43 -0800 (PST) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id CAC4F3A6925 for ; Fri, 28 Jan 2011 22:04:42 -0800 (PST) Received: (qmail 31829 invoked from network); 29 Jan 2011 06:07:49 -0000 Received: from unknown (110.168.98.197) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 29 Jan 2011 06:07:49 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4D3F8796.1090100@nict.go.jp> <019f01cbbd1a$be861a10$3b924e30$@net> <4D3FBF82.4030506@nict.go.jp> In-Reply-To: <4D3FBF82.4030506@nict.go.jp> Date: Sat, 29 Jan 2011 13:07:32 +0700 Organization: Network Zen Message-ID: <016101cbbf7a$d3b30030$7b190090$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu9IpXNwuO63fiDRJ+u7FS2uX9YPwCV4jkQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis-26 Result-Code values 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: , X-List-Received-Date: Sat, 29 Jan 2011 06:04:45 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] > Hi Glen, > > > Actually, I think that the redundant things are the lists of values > > themselves. They made sense in 3588, since that doc was actually > requesting > > allocation of the values but should be replaced with references to the > > relevant IANA registry in bis. > I agree with regard to the values that are unchanged between 3588 & bis. > > However, what about for example DIAMETER_COMMAND_UNSUPPORTED which was > defined as 3xxx (protocol error) in 3588, but is now in range 5xxx > (permanent failure) in bis ? Good question. I don't even remember discussing this, but it seems inappropriate since it would change peer behavior...