From cristian.constantin@iptel.org Wed Dec 1 01:34:34 2010 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 62DBB28C0EC for ; Wed, 1 Dec 2010 01:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBn9WTS9U3Ez for ; Wed, 1 Dec 2010 01:34:33 -0800 (PST) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by core3.amsl.com (Postfix) with ESMTP id 49D7A28C0E8 for ; Wed, 1 Dec 2010 01:34:33 -0800 (PST) Received: by mail.iptel.org (Postfix, from userid 103) id 52F58370543; Wed, 1 Dec 2010 10:35:45 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.iptel.org with ESMTPSA id 9B31F37050F Date: Wed, 1 Dec 2010 10:35:43 +0100 From: Cristian Constantin To: dime@ietf.org Message-ID: <20101201093543.GG19193@galador.office.iptelorg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Dime] sctp abort on broken diameter packet 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, 01 Dec 2010 09:34:34 -0000 hi! the latest draft http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-25 says in "2.1. Transport" "[...] If Diameter receives data from the lower layer that cannot be parsed or identified as a Diameter error made by the peer, the stream is compromised and cannot be recovered. The transport connection MUST be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT message (graceful closure is compromised)." now, the big difference between sctp and tcp here is that when using sctp as an transport protocol, a diameter application could try to recover from such an error (messages are _delimited_ in one sctp data chunk belonging to that association); tcp cannot since the message is part of the tcp stream itself and there is no delimiter. so, why does an sctp based diameter application _have to_ abort the association? thanks! bye now! cristian From gwz@net-zen.net Sun Dec 5 23:15:33 2010 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 2D03C3A69C6 for ; Sun, 5 Dec 2010 23:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 19pwmqj1pqQW for ; Sun, 5 Dec 2010 23:15:32 -0800 (PST) Received: from p3plsmtpa01-01.prod.phx3.secureserver.net (p3plsmtpa01-01.prod.phx3.secureserver.net [72.167.82.81]) by core3.amsl.com (Postfix) with SMTP id 6BDAA3A6870 for ; Sun, 5 Dec 2010 23:15:32 -0800 (PST) Received: (qmail 9590 invoked from network); 6 Dec 2010 07:16:55 -0000 Received: from unknown (110.168.104.15) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 06 Dec 2010 07:16:54 -0000 From: "Glen Zorn" To: Date: Mon, 6 Dec 2010 14:16:21 +0700 Organization: Network Zen Message-ID: <001301cb9515$7e1a3650$7a4ea2f0$@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: AcuVFXjadROIVMrsTx2uGYudTJLh5Q== Content-Language: en-us x-cr-hashedpuzzle: ADqH Any0 CX9Q DD8t ERhU HwHS IKUS Ker6 LBZ+ Mjjh NtPf ObNQ SaB7 S85i S9wK Uiq+; 2; ZABpAG0AZQAtAGMAaABhAGkAcgBzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {E5DEAE3A-23BD-4AFF-9029-F0DAFB3BC4C8}; ZwB3AHoAQABuAGUAdAAtAHoAZQBuAC4AbgBlAHQA; Mon, 06 Dec 2010 07:16:16 GMT; VwBHAEwAQwAgAGYAbwByACAAaAB0AHQAcABzADoALwAvAGQAYQB0AGEAdAByAGEAYwBrAGUAcgAuAGkAZQB0AGYALgBvAHIAZwAvAGQAbwBjAC8AZAByAGEAZgB0AC0AaQBlAHQAZgAtAGQAaQBtAGUALQByAGYAYwA0ADAAMAA1AGIAaQBzAC8APwA= x-cr-puzzleid: {E5DEAE3A-23BD-4AFF-9029-F0DAFB3BC4C8} Cc: dime@ietf.org Subject: [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, 06 Dec 2010 07:15:33 -0000 I think that it's ready... From gwz@net-zen.net Fri Dec 10 05:42:18 2010 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 669D428C0D0 for ; Fri, 10 Dec 2010 05:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 8TX+pGAsfQCh for ; Fri, 10 Dec 2010 05:42:16 -0800 (PST) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id 74D103A6CA7 for ; Fri, 10 Dec 2010 05:42:13 -0800 (PST) Received: (qmail 24733 invoked from network); 10 Dec 2010 13:43:43 -0000 Received: from unknown (124.120.74.27) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 10 Dec 2010 13:43:42 -0000 From: "Glen Zorn" To: Date: Fri, 10 Dec 2010 20:43:26 +0700 Organization: Network Zen Message-ID: <005e01cb9870$3ab83160$b0289420$@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: AcuYcDaqS7W20PWoT1Wg2nRzImFkhg== Content-Language: en-us x-cr-hashedpuzzle: AOVz Aoky CDLb E/lQ FKMk FcHd Fc4a GgyG GmbA Go9L G4w6 IYSm Ju3u LCga LEht LR9t; 1; ZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {65A1B8B6-03E4-45B7-9451-4121D964700E}; ZwB3AHoAQABuAGUAdAAtAHoAZQBuAC4AbgBlAHQA; Fri, 10 Dec 2010 13:43:23 GMT; RQByAHIAbwByACAAaQBuACAAUgBGAEMAIAAzADUAOAA4AGIAaQBzAD8A x-cr-puzzleid: {65A1B8B6-03E4-45B7-9451-4121D964700E} Subject: [Dime] Error in RFC 3588bis? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 13:42:18 -0000 In Section 1.2, the definition of Redirect Agent says "As with proxy agents, redirect agents do not keep state with respect to sessions or NAS resources." However, just above the definition of Proxy Agent says "In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning. This is typically accomplished by tracking the state of NAS devices." I seem to detect a contradiction. From gwz@net-zen.net Fri Dec 10 19:55:14 2010 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 9E91D28C0CF for ; Fri, 10 Dec 2010 19:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 QOM569QkU35F for ; Fri, 10 Dec 2010 19:55:13 -0800 (PST) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id CBE3B28B797 for ; Fri, 10 Dec 2010 19:55:13 -0800 (PST) Received: (qmail 22823 invoked from network); 11 Dec 2010 03:56:46 -0000 Received: from unknown (124.122.184.73) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 11 Dec 2010 03:56:45 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: In-Reply-To: Date: Sat, 11 Dec 2010 10:56:25 +0700 Organization: Network Zen Message-ID: <000801cb98e7$64365220$2ca2f660$@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: ActpTMct8R9Pe9VpTOaTe7t84CC1KQvmYFuw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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: Sat, 11 Dec 2010 03:55:14 -0000 Dan Romascanu [mailto://dromasca@avaya.com] writes: ... > 2. Same comment about the Diameter realm routing clarifications > described in RFC 5729. Section 1.1.1 now reads: 1.1.1. Description of the Document Set The Diameter specification consists of an updated version of the base protocol specification (this document) and the Transport Profile [RFC3539]. This document obsoletes RFC 3588. A summary of the base protocol updates included in this document can be found in Section 1.1.3. This document defines the base protocol specification for AAA, which includes support for accounting. There are also a myriad of applications documents describing applications that use this base specification for Authentication, Authorization and Accounting. These application documents specify how to use the Diameter protocol within the context of their application. The Transport Profile document [RFC3539] discusses transport layer issues that arise with AAA protocols and recommendations on how to overcome these issues. This document also defines the Diameter failover algorithm and state machine. RFC 5729 [RFC5729] defines the behavior required of Diameter agents when routing requests in which the User-Name Attribute-Value Pair Section 8.14 contains a Network Access Identifier [RFC4282] formatted with multiple realms. Does this satisfy your concern? BTW, it seems that the reasons for not incorporating the content of RFC 5729 into 3588bis (& obsolescing it) seem to have evaporated. Wouldn't it be a good idea to do this? > > 3. How is backwards compatibility ensured between RFC 3588 > implementations which were mandating IPSec and this new version which > mandates TLS and makes IPSec support optional, while disallowing usage > of Diameter without any security mechanisms? > > Thanks and Regards, > > Dan > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Mon Dec 13 03:06:00 2010 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 ABCD73A6E8D for ; Mon, 13 Dec 2010 03:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 i+hY01JS8S43 for ; Mon, 13 Dec 2010 03:05:59 -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 90DE03A6E89 for ; Mon, 13 Dec 2010 03:05:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOaMBU2HCzI1/2dsb2JhbACjfHioPQKYRYVKBI4n X-IronPort-AV: E=Sophos;i="4.59,335,1288584000"; d="scan'208";a="222917795" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Dec 2010 06:07:36 -0500 X-IronPort-AV: E=Sophos;i="4.59,335,1288584000"; d="scan'208";a="556263328" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Dec 2010 06:07:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Dec 2010 12:07:24 +0100 Message-ID: In-Reply-To: <000801cb98e7$64365220$2ca2f660$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt Thread-Index: ActpTMct8R9Pe9VpTOaTe7t84CC1KQvmYFuwAHPPQ7A= References: <000801cb98e7$64365220$2ca2f660$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 13 Dec 2010 11:06:00 -0000 =20 > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net]=20 >=20 > Does this satisfy your concern? BTW, it seems that the=20 > reasons for not incorporating the content of RFC 5729 into=20 > 3588bis (& obsolescing it) seem to have evaporated. Wouldn't=20 > it be a good idea to do this? >=20 Edits look good. Yes, we can go all the way and incorporate all content of 5729 to the bis if the WG agrees (as 3588bis is anyway open for more consistent edits).=20 Dan From jouni.nospam@gmail.com Mon Dec 13 03:51:19 2010 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 BDEB53A6E8E for ; Mon, 13 Dec 2010 03:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 9+qzoro1lrWR for ; Mon, 13 Dec 2010 03:51:19 -0800 (PST) Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by core3.amsl.com (Postfix) with ESMTP id C72C33A6E91 for ; Mon, 13 Dec 2010 03:51:18 -0800 (PST) Received: by fxm18 with SMTP id 18so5972212fxm.16 for ; Mon, 13 Dec 2010 03:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ulWAtQBkPn0nW2kWimZ4tdmNx5vte0z30EtqBKJJd3Y=; b=yBpbAW47R6upFZbKg9zI9kgFQuf/s6hBxnIZX55rYiQXeuainekcfr4Vn/otGyrK6G T80ohIcq6/MC86wpKS50u/hw4p4FPIYcePEouhC0GK8unvd3bkbHIT1IdXS05RqqmMgo TKMnBoL6JMyPW8Fex6Oi8ZPpKWLnXPaI4vTTo= 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=c76IBZvqTKedlkqr5mlgVeUs9fnhbgIRw2Nd7gzumW0xWbq++DXwWLdr7yAJhDzdxC ip7GegBh8yzI3sxx0x1YzxlfS8S9o4ivvHPHEflfMvAjwdC5Mtfr9RHuwCauhCJRXXJ8 lbipXfSbXRMiqW0LbjknadCmzKDrKjlDTJ9eA= Received: by 10.223.70.142 with SMTP id d14mr2555269faj.110.1292241175974; Mon, 13 Dec 2010 03:52:55 -0800 (PST) Received: from a88-114-169-232.elisa-laajakaista.fi (a88-114-169-232.elisa-laajakaista.fi [88.114.169.232]) by mx.google.com with ESMTPS id l3sm683038fan.0.2010.12.13.03.52.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 03:52:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 13 Dec 2010 13:52:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> References: <000801cb98e7$64365220$2ca2f660$@net> To: "Romascanu, Dan (Dan)" , Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 13 Dec 2010 11:51:19 -0000 Hi, On Dec 13, 2010, at 1:07 PM, Romascanu, Dan (Dan) wrote: >=20 >=20 >> -----Original Message----- >> From: Glen Zorn [mailto:gwz@net-zen.net]=20 >=20 >>=20 >> Does this satisfy your concern? BTW, it seems that the=20 >> reasons for not incorporating the content of RFC 5729 into=20 >> 3588bis (& obsolescing it) seem to have evaporated. Wouldn't=20 >> it be a good idea to do this? >>=20 >=20 >=20 > Edits look good. Yes, we can go all the way and incorporate all = content > of 5729 to the bis if the WG agrees (as 3588bis is anyway open for = more > consistent edits).=20 My concern/question here is, regarding obsoleting 5729, what happens to = stuff that gets implemented/deployed based on 3588 and also use 5279, = and do not have a rush to go for 3588bis in foreseen future? - Jouni >=20 > Dan > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Mon Dec 13 04:17:39 2010 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 62A793A6E8E for ; Mon, 13 Dec 2010 04:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 XS+n0wqzVIc8 for ; Mon, 13 Dec 2010 04:17:38 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 6EA763A6D9E for ; Mon, 13 Dec 2010 04:17:38 -0800 (PST) Received: (qmail 12657 invoked from network); 13 Dec 2010 12:19:15 -0000 Received: from unknown (124.120.90.173) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 13 Dec 2010 12:19:14 -0000 From: "Glen Zorn" To: "'jouni korhonen'" , "'Romascanu, Dan \(Dan\)'" References: <000801cb98e7$64365220$2ca2f660$@net> <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> In-Reply-To: <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> Date: Mon, 13 Dec 2010 19:18:45 +0700 Organization: Network Zen Message-ID: <000601cb9abf$e5dda3d0$b198eb70$@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: AcuavEkIDeZRsjtoRNGNZ2UV4ShIUwAA0sug Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 13 Dec 2010 12:17:39 -0000 jouni korhonen [mailto:jouni.nospam@gmail.com] writes: ... > > Edits look good. Yes, we can go all the way and incorporate all > content > > of 5729 to the bis if the WG agrees (as 3588bis is anyway open for > more > > consistent edits). > > My concern/question here is, regarding obsoleting 5729, what happens to > stuff that gets implemented/deployed based on 3588 and also use 5279, > and do not have a rush to go for 3588bis in foreseen future? I don't understand; it's not like 3588 & 5279 are going to disappear, nor implementations suddenly become non-standard... ... From dromasca@avaya.com Mon Dec 13 06:47:12 2010 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 E43C428C0E8 for ; Mon, 13 Dec 2010 06:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 K-qV386WMLfN for ; Mon, 13 Dec 2010 06:47:12 -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 E459528C0FB for ; Mon, 13 Dec 2010 06:47:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD/ABU3GmAcF/2dsb2JhbACYRIs+eKk+AphihUoEjieCWA X-IronPort-AV: E=Sophos;i="4.59,336,1288584000"; d="scan'208";a="222955595" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Dec 2010 09:48:48 -0500 X-IronPort-AV: E=Sophos;i="4.59,336,1288584000"; d="scan'208";a="554894673" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Dec 2010 09:48:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Dec 2010 15:48:33 +0100 Message-ID: In-Reply-To: <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt Thread-Index: AcuavEmWx4WTOyQeTV6R8swzzpayOgAGF71g References: <000801cb98e7$64365220$2ca2f660$@net> <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" , "Glen Zorn" Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 13 Dec 2010 14:47:13 -0000 Why would this be a problem? I guess for quite a while there will be implementations conforming with 3588 while the world transitions to 3588bis. Do I miss something?=20 Dan =20 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, December 13, 2010 1:53 PM > To: Romascanu, Dan (Dan); Glen Zorn > Cc: dime@ietf.org > Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt >=20 > Hi, >=20 > On Dec 13, 2010, at 1:07 PM, Romascanu, Dan (Dan) wrote: >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Glen Zorn [mailto:gwz@net-zen.net] > >=20 > >>=20 > >> Does this satisfy your concern? BTW, it seems that the=20 > reasons for=20 > >> not incorporating the content of RFC 5729 into 3588bis (&=20 > obsolescing=20 > >> it) seem to have evaporated. Wouldn't it be a good idea=20 > to do this? > >>=20 > >=20 > >=20 > > Edits look good. Yes, we can go all the way and incorporate all=20 > > content of 5729 to the bis if the WG agrees (as 3588bis is=20 > anyway open=20 > > for more consistent edits). >=20 > My concern/question here is, regarding obsoleting 5729, what=20 > happens to stuff that gets implemented/deployed based on 3588=20 > and also use 5279, and do not have a rush to go for 3588bis=20 > in foreseen future? >=20 > - Jouni >=20 >=20 >=20 > >=20 > > Dan > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 From jouni.nospam@gmail.com Mon Dec 13 07:19:01 2010 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 BB16028C0E4 for ; Mon, 13 Dec 2010 07:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 KJte7n22jKY7 for ; Mon, 13 Dec 2010 07:19:00 -0800 (PST) Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by core3.amsl.com (Postfix) with ESMTP id E0C7F3A6EA4 for ; Mon, 13 Dec 2010 07:18:59 -0800 (PST) Received: by fxm18 with SMTP id 18so6197320fxm.16 for ; Mon, 13 Dec 2010 07:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=nlI1o0+7dzE2DSh7qOAJRAL0n8jWEQQCtmiUUWLY7vk=; b=B0wLUINi4ONto8wZXjoL9Ri+XDw1VgDKG2FuKkmyrXtA/fo2Th02mKZ7u693UaUoDS abGaA/DqLylJS4fC906MXrPp7eSq0+YVYog8SXScbjMfFSmk0Rf2sSa9DE27tQaABnHX iqe6DTDgecaEMivTHDizbifFCYkp8YxAc05dU= 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=x85eda/lc1LxnFhJF67IpwByVTZ2YTrDkOPTNzyhOH+e+gYv0sld+r0ySNBZ10NB1O yc0eJLApFgj8+z3/ix47GhnnA+W6B+dfO2P6z5dkazcAEWtqZ2xUS2wqr4lfuVpTZSxy W21orOxjqEDmFsDj4qzgdVhhANyv4zCWdt1g0= Received: by 10.223.106.129 with SMTP id x1mr1552511fao.39.1292253636947; Mon, 13 Dec 2010 07:20:36 -0800 (PST) Received: from a88-114-169-232.elisa-laajakaista.fi (a88-114-169-232.elisa-laajakaista.fi [88.114.169.232]) by mx.google.com with ESMTPS id y3sm1699749fai.14.2010.12.13.07.20.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 07:20:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <000601cb9abf$e5dda3d0$b198eb70$@net> Date: Mon, 13 Dec 2010 17:20:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000801cb98e7$64365220$2ca2f660$@net> <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> <000601cb9abf$e5dda3d0$b198eb70$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 13 Dec 2010 15:19:01 -0000 On Dec 13, 2010, at 2:18 PM, Glen Zorn wrote: > jouni korhonen [mailto:jouni.nospam@gmail.com] writes: >=20 > ... >=20 >>> Edits look good. Yes, we can go all the way and incorporate all >> content >>> of 5729 to the bis if the WG agrees (as 3588bis is anyway open for >> more >>> consistent edits). >>=20 >> My concern/question here is, regarding obsoleting 5729, what happens = to >> stuff that gets implemented/deployed based on 3588 and also use 5279, >> and do not have a rush to go for 3588bis in foreseen future? >=20 > I don't understand; it's not like 3588 & 5279 are going to disappear, = nor > implementations suddenly become non-standard... ... Existing implementations for sure won't have their binaries modified and = unlike to have their existing code base changed :) The point being, if = you deprecate some spec i.e. writing down "RFC xyz is now = deprecated/obsoleted", then implementing it for new products is not = recommended/allowed anymore. Can I still state that forthcoming new = implementations (or deployments) based on 3588 are not affected by = whatever 3588bis deprecates? I just want to be clear with this myself.. = I know this is just specification world trickery but we often get hit by = "outdated & obsoleted spec hammer" even if it does not make sense in = certain cases.=20 - JOuni >=20 > ... >=20 >=20 From dromasca@avaya.com Mon Dec 13 07:21:43 2010 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 6D6AD3A6DCB for ; Mon, 13 Dec 2010 07:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 mxc6j9sr1jv7 for ; Mon, 13 Dec 2010 07:21:41 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 4B21428C0F8 for ; Mon, 13 Dec 2010 07:21:41 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOfIBU3GmAcF/2dsb2JhbACYRYs+eKlCAphshUoEjieCWA X-IronPort-AV: E=Sophos;i="4.59,336,1288584000"; d="scan'208";a="254678013" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Dec 2010 10:23:19 -0500 X-IronPort-AV: E=Sophos;i="4.59,336,1288584000"; d="scan'208";a="554911514" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Dec 2010 10:23:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Dec 2010 16:22:58 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt Thread-Index: Acua2U9iwNJy57OHTtOw4Dj0ngpvLAAADl7g References: <000801cb98e7$64365220$2ca2f660$@net> <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> <000601cb9abf$e5dda3d0$b198eb70$@net> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" , "Glen Zorn" Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 13 Dec 2010 15:21:43 -0000 =20 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, December 13, 2010 5:21 PM > To: Glen Zorn > Cc: Romascanu, Dan (Dan); dime@ietf.org > Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt >=20 >=20 > On Dec 13, 2010, at 2:18 PM, Glen Zorn wrote: >=20 > > jouni korhonen [mailto:jouni.nospam@gmail.com] writes: > >=20 > > ... > >=20 > >>> Edits look good. Yes, we can go all the way and incorporate all > >> content > >>> of 5729 to the bis if the WG agrees (as 3588bis is anyway open for > >> more > >>> consistent edits). > >>=20 > >> My concern/question here is, regarding obsoleting 5729,=20 > what happens=20 > >> to stuff that gets implemented/deployed based on 3588 and also use=20 > >> 5279, and do not have a rush to go for 3588bis in foreseen future? > >=20 > > I don't understand; it's not like 3588 & 5279 are going to=20 > disappear,=20 > > nor implementations suddenly become non-standard... >=20 > ... >=20 > Existing implementations for sure won't have their binaries=20 > modified and unlike to have their existing code base changed=20 > :) The point being, if you deprecate some spec i.e. writing=20 > down "RFC xyz is now deprecated/obsoleted", then implementing=20 > it for new products is not recommended/allowed anymore. Can=20 > I still state that forthcoming new implementations (or=20 > deployments) based on 3588 are not affected by whatever=20 > 3588bis deprecates? I just want to be clear with this=20 > myself.. I know this is just specification world trickery=20 > but we often get hit by "outdated & obsoleted spec hammer"=20 > even if it does not make sense in certain cases.=20 >=20 > - JOuni >=20 You can clarify this with text in 3588bis.=20 Dan From gwz@net-zen.net Mon Dec 13 19:23:10 2010 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 5BCFA3A6E3B for ; Mon, 13 Dec 2010 19:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 xITKKMzLRddv for ; Mon, 13 Dec 2010 19:23:07 -0800 (PST) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id B41303A6E39 for ; Mon, 13 Dec 2010 19:23:07 -0800 (PST) Received: (qmail 2219 invoked from network); 14 Dec 2010 03:24:46 -0000 Received: from unknown (124.122.110.184) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 14 Dec 2010 03:24:45 -0000 From: "Glen Zorn" To: "'jouni korhonen'" References: <000801cb98e7$64365220$2ca2f660$@net> <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> <000601cb9abf$e5dda3d0$b198eb70$@net> In-Reply-To: Date: Tue, 14 Dec 2010 10:24:13 +0700 Organization: Network Zen Message-ID: <00fe01cb9b3e$63f947f0$2bebd7d0$@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: Acua2Uz2fY7olQqZRwmSfQpkSYkyVgAZGHPg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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: Tue, 14 Dec 2010 03:23:10 -0000 jouni korhonen [mailto:jouni.nospam@gmail.com] writes: > On Dec 13, 2010, at 2:18 PM, Glen Zorn wrote: > > > jouni korhonen [mailto:jouni.nospam@gmail.com] writes: > > > > ... > > > >>> Edits look good. Yes, we can go all the way and incorporate all > >> content > >>> of 5729 to the bis if the WG agrees (as 3588bis is anyway open for > >> more > >>> consistent edits). > >> > >> My concern/question here is, regarding obsoleting 5729, what happens > to > >> stuff that gets implemented/deployed based on 3588 and also use 5279, > >> and do not have a rush to go for 3588bis in foreseen future? > > > > I don't understand; it's not like 3588 & 5279 are going to disappear, > nor > > implementations suddenly become non-standard... > > ... > > Existing implementations for sure won't have their binaries modified and > unlike to have their existing code base changed :) The point being, if > you deprecate some spec i.e. writing down "RFC xyz is now > deprecated/obsoleted", then implementing it for new products is not > recommended/allowed anymore. Can I still state that forthcoming new > implementations (or deployments) based on 3588 are not affected by > whatever 3588bis deprecates? I'm not sure, but I don't think that "obsoletes" == "deprecates". > I just want to be clear with this myself.. > I know this is just specification world trickery but we often get hit by > "outdated & obsoleted spec hammer" even if it does not make sense in > certain cases. You seem to be arguing that 3588bis be either abandoned or published as if it came from a vacuum (presenting the interesting situation of having two standard Diameter protocols). > > - JOuni > > > > > ... > > > > From gwz@net-zen.net Mon Dec 13 19:27:14 2010 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 E285C3A6E35 for ; Mon, 13 Dec 2010 19:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 YIWftpGt2W-n for ; Mon, 13 Dec 2010 19:27:14 -0800 (PST) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 250883A6D9B for ; Mon, 13 Dec 2010 19:27:13 -0800 (PST) Received: (qmail 9677 invoked from network); 14 Dec 2010 03:28:53 -0000 Received: from unknown (124.122.110.184) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 14 Dec 2010 03:28:52 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: <000801cb98e7$64365220$2ca2f660$@net> <20388740-CAF4-42E2-BFE9-212D4B4E7EE9@gmail.com> <000601cb9abf$e5dda3d0$b198eb70$@net> In-Reply-To: Date: Tue, 14 Dec 2010 10:28:20 +0700 Organization: Network Zen Message-ID: <00ff01cb9b3e$f6dce360$e496aa20$@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: Acua2U9iwNJy57OHTtOw4Dj0ngpvLAAADl7gABk+sTA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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: Tue, 14 Dec 2010 03:27:15 -0000 Romascanu, Dan (Dan) [mailto://dromasca@avaya.com] > > ... > > > > Existing implementations for sure won't have their binaries > > modified and unlike to have their existing code base changed > > :) The point being, if you deprecate some spec i.e. writing > > down "RFC xyz is now deprecated/obsoleted", then implementing > > it for new products is not recommended/allowed anymore. Can > > I still state that forthcoming new implementations (or > > deployments) based on 3588 are not affected by whatever > > 3588bis deprecates? I just want to be clear with this > > myself.. I know this is just specification world trickery > > but we often get hit by "outdated & obsoleted spec hammer" > > even if it does not make sense in certain cases. > > > > - JOuni > > > > You can clarify this with text in 3588bis. I don't know how, without seriously impairing the adoption of 3588bis as the standard for Diameter. All in all, this attention to eliminating stress in (presumably) other SDOs seems misguided... > > Dan From jouni.korhonen@nsn.com Thu Dec 23 02:07:43 2010 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 A3A553A6B05 for ; Thu, 23 Dec 2010 02:07:43 -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 na68eaHZ211A for ; Thu, 23 Dec 2010 02:07:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 9E4DF3A6805 for ; Thu, 23 Dec 2010 02:07:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oBNA9f7o024111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Dec 2010 11:09:41 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oBNA9eLM001890; Thu, 23 Dec 2010 11:09:41 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Dec 2010 11:09:37 +0100 Received: from 10.144.241.229 ([10.144.241.229]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server demuexc023.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Dec 2010 10:09:33 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 23 Dec 2010 12:09:32 +0200 From: Jouni Korhonen To: ext Glen Zorn , Message-ID: Thread-Topic: WGLC for https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/? Thread-Index: AcuVFXjadROIVMrsTx2uGYudTJLh5QNdAU8X In-Reply-To: <001301cb9515$7e1a3650$7a4ea2f0$@net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Dec 2010 10:09:37.0798 (UTC) FILETIME=[818E0A60:01CBA289] 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: Thu, 23 Dec 2010 10:07:43 -0000 I'll have the chairs' review on the document shortly and based on that start moving the I-D forward or ask for "more work". Sorry for a slight lag.. - Jouni On 12/6/10 9:16 AM, "ext Glen Zorn" wrote: > I think that it's ready... > From jouni.korhonen@nsn.com Thu Dec 30 01:30:23 2010 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 2624228C0D8 for ; Thu, 30 Dec 2010 01:30:23 -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 JqcvW7lbWR3r for ; Thu, 30 Dec 2010 01:30:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 89ADE28B23E for ; Thu, 30 Dec 2010 01:30:21 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oBU9WPJe022197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Dec 2010 10:32:26 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oBU9WIE9004613; Thu, 30 Dec 2010 10:32:24 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Dec 2010 10:32:16 +0100 Received: from 10.144.244.213 ([10.144.244.213]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server demuexc023.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Dec 2010 09:32:15 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 30 Dec 2010 11:32:14 +0200 From: Jouni Korhonen To: ext Glen Zorn , Message-ID: Thread-Topic: WGLC for https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/? Thread-Index: AcuVFXjadROIVMrsTx2uGYudTJLh5QNdAU8XAV68vCE= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Dec 2010 09:32:16.0103 (UTC) FILETIME=[724AC770:01CBA804] Cc: ext Jouni Korhonen , 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: Thu, 30 Dec 2010 09:30:23 -0000 Hello, I did a "chairs'" review of draft-ietf-dime-rfc4005bis-02. 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. 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. Section 1.3 o RFC 3588 still mentioned and should be replaced with RFC3588bis reference. Section 2.3 o LCP is never expanded 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 o DSCP is not expanded on the first use. 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. Section 4.3.1 o References missing for IPsec and TLS. o TLS is not expanded on the first use. Section 4.3.2 o Expand ARAP on the first use. Section 4.4.10.5.7 o IPv6 addresses here should follow the RFC5156 documentation prefix. Section 4.4.10.8.1 o s/[ARAP]/(ARAP) [ARAP] Section 4.4.11.5.1 o Is it useful still to mention Vax & Alpha clusters? Section 4.5.8 o PAC and LAC are never expanded Section 4.5.9 o s/decidewitch/decide witch 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. Section 6.5 o This will cause a textual update in IANA registry policy, right? (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.. - Jouni On 12/23/10 12:09 PM, "ext Jouni Korhonen" wrote: > > I'll have the chairs' review on the document shortly and based on that start > moving the I-D forward or ask for "more work". Sorry for a slight lag.. > > - Jouni > > > On 12/6/10 9:16 AM, "ext Glen Zorn" wrote: > >> I think that it's ready... >> >