From jouni.nospam@gmail.com Thu Mar 1 07:15:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381FB21E81B5 for ; Thu, 1 Mar 2012 07:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtShiLXb3xVv for ; Thu, 1 Mar 2012 07:15:50 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 620D621E81AF for ; Thu, 1 Mar 2012 07:15:50 -0800 (PST) Received: by eaaq11 with SMTP id q11so234893eaa.31 for ; Thu, 01 Mar 2012 07:15:49 -0800 (PST) Received-SPF: pass (google.com: domain of jouni.nospam@gmail.com designates 10.112.102.68 as permitted sender) client-ip=10.112.102.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jouni.nospam@gmail.com designates 10.112.102.68 as permitted sender) smtp.mail=jouni.nospam@gmail.com; dkim=pass header.i=jouni.nospam@gmail.com Received: from mr.google.com ([10.112.102.68]) by 10.112.102.68 with SMTP id fm4mr2579832lbb.7.1330614949468 (num_hops = 1); Thu, 01 Mar 2012 07:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=SOGtGJfsVAxkcEIgabnb5WbvSC+UgGKSDoVcMrOV4so=; b=CigXWfHTaTGO4LAcIvGia/1kWgERi4waZ/BoDN6hvwT03rORHk1jRrKCFrpU7bM3aj /Ma7FVsqZgj0Scq/ajtO4fVUV1IehGZ1baxNbYyy+FDO7v0XVduWto2wZat1q/De6aWn WMuEa73UQ72qAs03a6sXw4x5Y9heS26Dj6enw= Received: by 10.112.102.68 with SMTP id fm4mr2113248lbb.7.1330614949405; Thu, 01 Mar 2012 07:15:49 -0800 (PST) Received: from a88-114-174-162.elisa-laajakaista.fi (a88-114-174-162.elisa-laajakaista.fi. [88.114.174.162]) by mx.google.com with ESMTPS id j4sm3331797lbf.6.2012.03.01.07.15.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 07:15:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 1 Mar 2012 17:15:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Krishna Prasad X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] wrong diameter Identity in CEA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 15:15:51 -0000 Hi, I don't quite understand what you mean by "wrong identity". Receiving a CER or CEA from a "wrong" peer is different from what RFC3588 says "unknown" peer, at least to me. Section 5.3 says: CERs received from unknown peers MAY be silently discarded, or a CEA MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. In both cases, the transport connection is closed. If the local ^^^^^^^^^^^^^^ Which is pretty clear to me. - Jouni On Mar 1, 2012, at 8:26 AM, Krishna Prasad wrote: > Hi All, > The base RFC (and also the bis) says that if a CER is received = from an unexpected peer (wrong diameter identity in Orig host AVP) CEA = will be sent with unknown peer error. > But if the diameter Identity in CEA is wrong (i.e. the initiator is = expecting some other identity in CEA) what is the expected behavior; = does the node silently close the connection or this is not at all an = error? I think RFC is silent on this. > =20 > Regards > Prasad. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From kprasad@sandvine.com Thu Mar 1 19:59:34 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08A621F889E for ; Thu, 1 Mar 2012 19:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA2jvfTZGQOX for ; Thu, 1 Mar 2012 19:59:34 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF0021F888F for ; Thu, 1 Mar 2012 19:59:32 -0800 (PST) Received: from blr-exch-1.sandvine.com (10.30.4.60) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 1 Mar 2012 22:59:31 -0500 Received: from BLR-EXCH-1.sandvine.com ([fe80::b896:bd62:3a8d:e51d]) by blr-exch-1.sandvine.com ([fe80::b896:bd62:3a8d:e51d%16]) with mapi id 14.01.0289.001; Fri, 2 Mar 2012 09:29:29 +0530 From: Krishna Prasad To: jouni korhonen Thread-Topic: [Dime] wrong diameter Identity in CEA Thread-Index: Acz3dEObmyI/SGtSSsC+/7A6rM5NeAAG882AACYHAnA= Date: Fri, 2 Mar 2012 03:59:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.10.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] wrong diameter Identity in CEA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 03:59:35 -0000 When we say the 'unknown peer', the receiver of CER will identify the peer = is known or unknown by checking or validating the Orig host AVP value in CE= R (this is my understanding). Similarly when CEA is received does the recei= ver of CEA need not verify if the Orig host AVP value is as expected or not= ? =20 -----Original Message----- From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Thursday, March 01, 2012 8:46 PM To: Krishna Prasad Cc: dime@ietf.org Subject: Re: [Dime] wrong diameter Identity in CEA Hi, I don't quite understand what you mean by "wrong identity". Receiving a CER or CEA from a "wrong" peer is different from what RFC3588 says "unknown" peer, at least to me. Section 5.3 says: CERs received from unknown peers MAY be silently discarded, or a CEA MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. In both cases, the transport connection is closed. If the local ^^^^^^^^^^^^^^ Which is pretty clear to me. - Jouni On Mar 1, 2012, at 8:26 AM, Krishna Prasad wrote: > Hi All, > The base RFC (and also the bis) says that if a CER is received from a= n unexpected peer (wrong diameter identity in Orig host AVP) CEA will be se= nt with unknown peer error. > But if the diameter Identity in CEA is wrong (i.e. the initiator is expec= ting some other identity in CEA) what is the expected behavior; does the no= de silently close the connection or this is not at all an error? I think RF= C is silent on this. > =20 > Regards > Prasad. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Thu Mar 1 20:45:01 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FAB21E801F for ; Thu, 1 Mar 2012 20:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0XaaBKyrMiN for ; Thu, 1 Mar 2012 20:45:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A601B21F8A19 for ; Thu, 1 Mar 2012 20:44:59 -0800 (PST) Received: by iazz13 with SMTP id z13so2070506iaz.31 for ; Thu, 01 Mar 2012 20:44:59 -0800 (PST) Received-SPF: pass (google.com: domain of glenzorn@gmail.com designates 10.42.133.198 as permitted sender) client-ip=10.42.133.198; Authentication-Results: mr.google.com; spf=pass (google.com: domain of glenzorn@gmail.com designates 10.42.133.198 as permitted sender) smtp.mail=glenzorn@gmail.com; dkim=pass header.i=glenzorn@gmail.com Received: from mr.google.com ([10.42.133.198]) by 10.42.133.198 with SMTP id i6mr5810281ict.49.1330663499438 (num_hops = 1); Thu, 01 Mar 2012 20:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KH1ZiF84RdvMExrjz1YQb0zOGNL9H8SQ06HD16NGUCY=; b=Xt2RiMkc4DI+kPYE3cPq0MbNCOXWkaWVcqtlnlbZ3eE4rK/QP87Nhd6J8dTLCG5X8b PwkhXtMaY6UxriouugjEOw9H25QgaqmZBJO+pEbib4deaiqbZ1Uz1dvpxZ/e2e3U9B1h rdxwjiSzZQagDhh6vjWuqHlQD1kszfe/ZFh3z0VIIWUSyQL4cBN4I0ooYiirgshCscwo Ao590u+YSEdbAfD1/w9aukpa4Or8f1k+aCq40LLEEc3L4fH1/uhGKL5yYQ/adn1gIm8T Lqxzo7eYfKWxVaAioDlSsjwqfg7JkSVrywoAJdtCreJWgL0LwHEUZpJEo0VytLwVl8mM gKnw== Received: by 10.42.133.198 with SMTP id i6mr4758874ict.49.1330663499392; Thu, 01 Mar 2012 20:44:59 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-29-31.revip2.asianet.co.th. [124.120.29.31]) by mx.google.com with ESMTPS id r1sm553316igb.0.2012.03.01.20.44.55 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 20:44:57 -0800 (PST) Message-ID: <4F505044.3030406@gmail.com> Date: Fri, 02 Mar 2012 11:44:52 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: jouni korhonen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] wrong diameter Identity in CEA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 04:45:01 -0000 On 3/1/2012 10:15 PM, jouni korhonen wrote: > Hi, > > I don't quite understand what you mean by "wrong identity". Receiving > a CER or CEA from a "wrong" peer is different from what RFC3588 says > "unknown" peer, at least to me. > > Section 5.3 says: > > CERs received from unknown peers MAY be silently discarded, or a CEA > MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. > In both cases, the transport connection is closed. If the local > ^^^^^^^^^^^^^^ > > Which is pretty clear to me. It's quite clear, but it also doesn't have anything to do w/the question which I believe had to do with the handling of a CEA containing a Diameter identity that was incorrect (possibly due to a masquerade attack). > > - Jouni > > On Mar 1, 2012, at 8:26 AM, Krishna Prasad wrote: > >> Hi All, >> The base RFC (and also the bis) says that if a CER is received from an unexpected peer (wrong diameter identity in Orig host AVP) CEA will be sent with unknown peer error. >> But if the diameter Identity in CEA is wrong (i.e. the initiator is expecting some other identity in CEA) what is the expected behavior; does the node silently close the connection or this is not at all an error? I think RFC is silent on this. >> >> Regards >> Prasad. >> _______________________________________________ >> 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 kprasad@sandvine.com Thu Mar 1 21:22:46 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3421E800E for ; Thu, 1 Mar 2012 21:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWmvIr-pAmHJ for ; Thu, 1 Mar 2012 21:22:44 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 78EF821E803F for ; Thu, 1 Mar 2012 21:22:43 -0800 (PST) Received: from blr-exch-1.sandvine.com (10.30.4.60) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 2 Mar 2012 00:22:42 -0500 Received: from BLR-EXCH-1.sandvine.com ([fe80::b896:bd62:3a8d:e51d]) by blr-exch-1.sandvine.com ([fe80::b896:bd62:3a8d:e51d%16]) with mapi id 14.01.0289.001; Fri, 2 Mar 2012 10:52:39 +0530 From: Krishna Prasad To: Glen Zorn , jouni korhonen Thread-Topic: [Dime] wrong diameter Identity in CEA Thread-Index: Acz3dEObmyI/SGtSSsC+/7A6rM5NeAAG882AABxCEQAADLuPcA== Date: Fri, 2 Mar 2012 05:22:38 +0000 Message-ID: References: <4F505044.3030406@gmail.com> In-Reply-To: <4F505044.3030406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.10.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] wrong diameter Identity in CEA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 05:22:46 -0000 -----Original Message----- From: Glen Zorn [mailto:glenzorn@gmail.com]=20 Sent: Friday, March 02, 2012 10:15 AM To: jouni korhonen Cc: Krishna Prasad; dime@ietf.org Subject: Re: [Dime] wrong diameter Identity in CEA On 3/1/2012 10:15 PM, jouni korhonen wrote: > Hi, >=20 > I don't quite understand what you mean by "wrong identity". Receiving > a CER or CEA from a "wrong" peer is different from what RFC3588 says > "unknown" peer, at least to me. >=20 > Section 5.3 says: >=20 > CERs received from unknown peers MAY be silently discarded, or a CEA > MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. > In both cases, the transport connection is closed. If the local > ^^^^^^^^^^^^^^ >=20 > Which is pretty clear to me. It's quite clear, but it also doesn't have anything to do w/the question which I believe had to do with the handling of a CEA containing a Diameter identity that was incorrect (possibly due to a masquerade attack). Yes, Glen has summarized my question in a more clear way, the incorrect Dia= meter identity in CEA may be due to wrong configurations also. >=20 > - Jouni >=20 > On Mar 1, 2012, at 8:26 AM, Krishna Prasad wrote: >=20 >> Hi All, >> The base RFC (and also the bis) says that if a CER is received from = an unexpected peer (wrong diameter identity in Orig host AVP) CEA will be s= ent with unknown peer error. >> But if the diameter Identity in CEA is wrong (i.e. the initiator is expe= cting some other identity in CEA) what is the expected behavior; does the n= ode silently close the connection or this is not at all an error? I think R= FC is silent on this. >> =20 >> Regards >> Prasad. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Mar 1 23:51:27 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C0421F8826 for ; Thu, 1 Mar 2012 23:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5TYWVrvdt2i for ; Thu, 1 Mar 2012 23:51:27 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8F21F87EA for ; Thu, 1 Mar 2012 23:51:26 -0800 (PST) Received: by eaaq11 with SMTP id q11so489208eaa.31 for ; Thu, 01 Mar 2012 23:51:24 -0800 (PST) Received-SPF: pass (google.com: domain of jouni.nospam@gmail.com designates 10.14.33.218 as permitted sender) client-ip=10.14.33.218; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jouni.nospam@gmail.com designates 10.14.33.218 as permitted sender) smtp.mail=jouni.nospam@gmail.com; dkim=pass header.i=jouni.nospam@gmail.com Received: from mr.google.com ([10.14.33.218]) by 10.14.33.218 with SMTP id q66mr5131087eea.67.1330674684098 (num_hops = 1); Thu, 01 Mar 2012 23:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=+SVw3c/GUJOa2Q9AP3Ga89iQ7nEUkZ2Unj4JiH87tDQ=; b=z+RoVSrJIRZk1+07E4k1LxqH6JbZ4UBijXU36aU+CTDSasCjmN+QNFYgpAXsnOzx0m f6M3KqoaKmySh1RJhcIpgsbQMKUo81BtESO79ppzDV9NCbyu1TBmJaADsFe2hKbyp33C ZTn6YjhDERW4jnUxueoIL76/bd54GZYEtm6Z0cnEqKzlYcDffz4d+6aIMRvFK0K2rI1+ WBP6W5JfvzJCBnYIAEhITdwmvxBOpbe/k4rOMX2Nc/toe8Z8p2V5ww9NqknRsSk1hWhc DKbaUd1L1MlaPt685N9IcGR0813PPIjis8I3Omq1Dxe9jZpelwyzBLRiyGLp3hoQ8AEI w/2w== Received: by 10.14.33.218 with SMTP id q66mr3952063eea.67.1330674683983; Thu, 01 Mar 2012 23:51:23 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id c15sm17375489eei.9.2012.03.01.23.51.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 23:51:23 -0800 (PST) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 09:51:20 +0200 Message-Id: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com> To: Mark Jones Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: dime@ietf.org, Glen Zorn Subject: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 07:51:28 -0000 Mark, Are you OK for me to close the Ticket #19 ? Ref these emails: http://www.ietf.org/mail-archive/web/dime/current/msg04690.html and then the comment in issue tracker: http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:1 =46rom my side, I see this issue resolved. - Jouni= From jouni.nospam@gmail.com Fri Mar 2 06:21:41 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BA121F8555 for ; Fri, 2 Mar 2012 06:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI+CkZfCcaJP for ; Fri, 2 Mar 2012 06:21:39 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1A721F8573 for ; Fri, 2 Mar 2012 06:21:39 -0800 (PST) Received: by eeke51 with SMTP id e51so620779eek.31 for ; Fri, 02 Mar 2012 06:21:38 -0800 (PST) Received-SPF: pass (google.com: domain of jouni.nospam@gmail.com designates 10.14.98.73 as permitted sender) client-ip=10.14.98.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jouni.nospam@gmail.com designates 10.14.98.73 as permitted sender) smtp.mail=jouni.nospam@gmail.com; dkim=pass header.i=jouni.nospam@gmail.com Received: from mr.google.com ([10.14.98.73]) by 10.14.98.73 with SMTP id u49mr6122232eef.35.1330698098670 (num_hops = 1); Fri, 02 Mar 2012 06:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WiNxY5gMCHpTrxbJR+thyxrFD9c76uaLc75N+M4TLlY=; b=GBZ4QRrwZle+LmPryDBTT+eJQ1nWPX7M3Z+iEVfnJ/2tLGUTDawAY8gUWUl8nKpijS 3au300WWJ9HoHNU30DRN1yqb9WxLhyyJhZDnp5pSNcpD2RF/ob5kCAeRsRf4gSWTBfGO wAfXdL05Bj30olW4ZzgMiH2mUtQUiubr7mBgZTCa2XpxN3cnTOvvWdaYGA8ct1aq8hmF 9TTovjmzpB6mmp6oGE/qmI86AZ5hBsfz/+ZKW/XX9zGO4ZbdHNAXaDa8oekya2k3bbsM YFvbb6g3uevKCFmWEGKvVP0dChngug56ln8YxQUWJwn9KIIxUaZCC5DE/Se7/n2VezXp Kw5Q== Received: by 10.14.98.73 with SMTP id u49mr4708672eef.35.1330698098431; Fri, 02 Mar 2012 06:21:38 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id c15sm20813243eei.9.2012.03.02.06.21.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Mar 2012 06:21:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Fri, 2 Mar 2012 16:21:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5DCE5774-E39B-4700-9757-E53F6BFE7102@gmail.com> References: <4F505044.3030406@gmail.com> To: Krishna Prasad X-Mailer: Apple Mail (2.1257) Cc: "dime@ietf.org" Subject: Re: [Dime] wrong diameter Identity in CEA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 14:21:41 -0000 Right, thanks for clarification.. I agree the RFC is silent of this but = do you have other choices than dropping the connection if the peer you talk to is not who you think it should be? Either silently or preferably = using Disconnect. - Jouni On Mar 2, 2012, at 7:22 AM, Krishna Prasad wrote: >=20 >=20 > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@gmail.com]=20 > Sent: Friday, March 02, 2012 10:15 AM > To: jouni korhonen > Cc: Krishna Prasad; dime@ietf.org > Subject: Re: [Dime] wrong diameter Identity in CEA >=20 > On 3/1/2012 10:15 PM, jouni korhonen wrote: >> Hi, >>=20 >> I don't quite understand what you mean by "wrong identity". Receiving >> a CER or CEA from a "wrong" peer is different from what RFC3588 says >> "unknown" peer, at least to me. >>=20 >> Section 5.3 says: >>=20 >> CERs received from unknown peers MAY be silently discarded, or a = CEA >> MAY be issued with the Result-Code AVP set to = DIAMETER_UNKNOWN_PEER. >> In both cases, the transport connection is closed. If the local >> ^^^^^^^^^^^^^^ >>=20 >> Which is pretty clear to me. >=20 > It's quite clear, but it also doesn't have anything to do w/the = question > which I believe had to do with the handling of a CEA containing a > Diameter identity that was incorrect (possibly due to a masquerade > attack). >=20 > Yes, Glen has summarized my question in a more clear way, the = incorrect Diameter identity in CEA may be due to wrong configurations = also. >=20 >>=20 >> - Jouni >>=20 >> On Mar 1, 2012, at 8:26 AM, Krishna Prasad wrote: >>=20 >>> Hi All, >>> The base RFC (and also the bis) says that if a CER is received = from an unexpected peer (wrong diameter identity in Orig host AVP) CEA = will be sent with unknown peer error. >>> But if the diameter Identity in CEA is wrong (i.e. the initiator is = expecting some other identity in CEA) what is the expected behavior; = does the node silently close the connection or this is not at all an = error? I think RFC is silent on this. >>>=20 >>> Regards >>> Prasad. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From mark@azu.ca Fri Mar 2 14:47:09 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8721E8029 for ; Fri, 2 Mar 2012 14:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MqI1bRi+sDa for ; Fri, 2 Mar 2012 14:47:09 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2521E8010 for ; Fri, 2 Mar 2012 14:47:08 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2232834vcb.31 for ; Fri, 02 Mar 2012 14:47:08 -0800 (PST) Received-SPF: pass (google.com: domain of mark@azu.ca designates 10.52.76.164 as permitted sender) client-ip=10.52.76.164; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mark@azu.ca designates 10.52.76.164 as permitted sender) smtp.mail=mark@azu.ca Received: from mr.google.com ([10.52.76.164]) by 10.52.76.164 with SMTP id l4mr19786688vdw.6.1330728428537 (num_hops = 1); Fri, 02 Mar 2012 14:47:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.76.164 with SMTP id l4mr16903809vdw.6.1330728428469; Fri, 02 Mar 2012 14:47:08 -0800 (PST) Received: by 10.52.22.6 with HTTP; Fri, 2 Mar 2012 14:47:08 -0800 (PST) In-Reply-To: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com> References: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com> Date: Fri, 2 Mar 2012 17:47:08 -0500 Message-ID: From: Mark Jones To: jouni korhonen Content-Type: multipart/alternative; boundary=bcaec50166d3457ef004ba4a5bc7 X-Gm-Message-State: ALoCoQmlqdLvwNub+Ar0K1vTSJbOClE9y9SUBA/tCctB3Zp9zGtonwRgTeIos/kbCuXSl17IgR2W Cc: dime@ietf.org, Glen Zorn Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 22:47:10 -0000 --bcaec50166d3457ef004ba4a5bc7 Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, I'm OK to close the ticket but I suggest adding Glen's explanation to it: >> And the reasoning behind is? > OK,I give: how many different reasons could there be? I can only think > of one: the text is meant to be descriptive, not prescriptive, that is, > no rationale is required for acting differently and Diameter > interoperability is not, AFAICT, effected. /Mark On Fri, Mar 2, 2012 at 2:51 AM, Jouni wrote: > Mark, > > Are you OK for me to close the Ticket #19 ? Ref these emails: > http://www.ietf.org/mail-archive/web/dime/current/msg04690.html > and then the comment in issue tracker: > http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:1 > > From my side, I see this issue resolved. > > - Jouni --bcaec50166d3457ef004ba4a5bc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jouni,

I'm OK to close the ticket but I suggest a= dding Glen's explanation to it:

>> And the reasoning behind is?

&g= t; OK,I give: how many different reasons could there be? =A0I can only thin= k
> of one: the text is meant to be descriptive, not prescript= ive, that is,
> no rationale is required for= acting differently and Diameter
> interoper= ability is not, AFAICT, effected.

/Mark

On Fri, M= ar 2, 2012 at 2:51 AM, Jouni <jouni.nospam@gmail.com> wrote:
Mark,

Are you OK for me to close the Ticket #19 ? Ref these emails:
http://www.ietf.org/mail-archive/web/dime/current/msg046= 90.html
and then the comment in issue tracker:
http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:1<= /a>

>From my side, I see this issue resolved.

- Jouni

--bcaec50166d3457ef004ba4a5bc7-- From jouni.nospam@gmail.com Sat Mar 3 03:24:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A48E21F84B8 for ; Sat, 3 Mar 2012 03:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz1SobgTnvPX for ; Sat, 3 Mar 2012 03:24:31 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 434C621F871D for ; Sat, 3 Mar 2012 03:24:31 -0800 (PST) Received: by lagj5 with SMTP id j5so3656316lag.31 for ; Sat, 03 Mar 2012 03:24:30 -0800 (PST) Received-SPF: pass (google.com: domain of jouni.nospam@gmail.com designates 10.152.145.135 as permitted sender) client-ip=10.152.145.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jouni.nospam@gmail.com designates 10.152.145.135 as permitted sender) smtp.mail=jouni.nospam@gmail.com; dkim=pass header.i=jouni.nospam@gmail.com Received: from mr.google.com ([10.152.145.135]) by 10.152.145.135 with SMTP id su7mr12167997lab.5.1330773870267 (num_hops = 1); Sat, 03 Mar 2012 03:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OB1hYeoOjA/hL60sP26dP/TAVsD4Qo6/bUTs3gdteaU=; b=OJQPQV7ryAGHQ888JkohW4axaE1w/5w6YleP3muCC8m5akm9RYCASqemXJMOFj9jAO NxCNqHnzjCDIMMD+Yx4Di89rPb7/2KWGog5XcE5mquUHGO/9jtAyy1cgLy6M3JS57bNI IJHLpj2VbDABdEdEwiKTd3zmd8WvUS27lnp9nSU6Nm9rEdjXd85ankPnyivoESFUvQ9P ESGhVIOLSt8WoyBVTdt+jq3YE99w1VolN29Nxzs0dNsP8l8Kcgko1n/2TIU/q4fpweLh IRuhi6sIfliXICigb1mbM/MQCLCoWuXbidfaf365G+xXxDRFi/5rsf/t9g658rWLnPWv +2iQ== Received: by 10.152.145.135 with SMTP id su7mr9982020lab.5.1330773870115; Sat, 03 Mar 2012 03:24:30 -0800 (PST) Received: from a88-114-174-162.elisa-laajakaista.fi (a88-114-174-162.elisa-laajakaista.fi. [88.114.174.162]) by mx.google.com with ESMTPS id hv2sm12639141lbb.9.2012.03.03.03.24.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Mar 2012 03:24:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Sat, 3 Mar 2012 13:24:26 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com> To: Mark Jones , Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 03 Mar 2012 11:24:32 -0000 Hi, Ok good. I support adding the clarification below. Glen, once you have done the update I'll take the required actions to advance this document. - Jouni On Mar 3, 2012, at 12:47 AM, Mark Jones wrote: > Hi Jouni, > > I'm OK to close the ticket but I suggest adding Glen's explanation to it: > > >> And the reasoning behind is? > > > OK,I give: how many different reasons could there be? I can only think > > of one: the text is meant to be descriptive, not prescriptive, that is, > > no rationale is required for acting differently and Diameter > > interoperability is not, AFAICT, effected. > > /Mark > > On Fri, Mar 2, 2012 at 2:51 AM, Jouni wrote: > Mark, > > Are you OK for me to close the Ticket #19 ? Ref these emails: > http://www.ietf.org/mail-archive/web/dime/current/msg04690.html > and then the comment in issue tracker: > http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:1 > > From my side, I see this issue resolved. > > - Jouni > From glenzorn@gmail.com Sun Mar 4 01:59:01 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9DA21F8554 for ; Sun, 4 Mar 2012 01:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ2mlU+zMj5d for ; Sun, 4 Mar 2012 01:59:00 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED6C21F8551 for ; Sun, 4 Mar 2012 01:58:59 -0800 (PST) Received: by iazz13 with SMTP id z13so4970895iaz.31 for ; Sun, 04 Mar 2012 01:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=k+oh7GG0oI3XmYoTf/LPLM4EtuxRSjwdizvD8jOBniw=; b=ebUlfhVX5r4r/vAm81O81u4ePsMbT5coEIR4HB/gSFPCuTWUdV/EEdhqDvewKbgWdu BxEAMzn9x+/T61F61+Zw8mRwp2SDPHlOhyYascUAz+9DCLFycRfe7knebgxyT6k4d/74 B26Egj1ka9Al7BBXz0oyzO9tVeFnsDB8p1MwCB5R/n8IRezar7/7ZFXAhoNqDh+iFESi dhoN0PktspxPP/jucmUHRPUeJg2gmtlaMaorjlXLvyERUYuao8fextdYkSbBrfuN5jw3 U8hy2gipE6a0K75i+vCiEzUfGIlRcurETvMzC+/T8ZLUQuBl2516jL/rm2nf44ZCcWqL 7ZGA== Received: by 10.50.222.137 with SMTP id qm9mr2977067igc.45.1330855138705; Sun, 04 Mar 2012 01:58:58 -0800 (PST) Received: from [192.168.1.98] (ppp-124-122-159-198.revip2.asianet.co.th. [124.122.159.198]) by mx.google.com with ESMTPS id c2sm7844170igj.1.2012.03.04.01.58.55 (version=SSLv3 cipher=OTHER); Sun, 04 Mar 2012 01:58:57 -0800 (PST) Message-ID: <4F533CDB.1050404@gmail.com> Date: Sun, 04 Mar 2012 16:58:51 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: jouni korhonen References: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2012 09:59:01 -0000 On 3/3/2012 6:24 PM, jouni korhonen wrote: > Hi, > > Ok good. I support adding the clarification below. OK, what am I supposed to be updating/clarifying, the ticket or the draft? I don't understand the term 'clarify' in the latter case: the draft seems pretty much crystalline, esp. insofar as the words in question are intentionally not capitalized. > > Glen, once you have done the update I'll take the required > actions to advance this document. > > - Jouni > > > On Mar 3, 2012, at 12:47 AM, Mark Jones wrote: > >> Hi Jouni, >> >> I'm OK to close the ticket but I suggest adding Glen's explanation to it: >> >>>> And the reasoning behind is? >> >>> OK,I give: how many different reasons could there be? I can only think >>> of one: the text is meant to be descriptive, not prescriptive, that is, >>> no rationale is required for acting differently and Diameter >>> interoperability is not, AFAICT, effected. >> >> /Mark >> >> On Fri, Mar 2, 2012 at 2:51 AM, Jouni wrote: >> Mark, >> >> Are you OK for me to close the Ticket #19 ? Ref these emails: >> http://www.ietf.org/mail-archive/web/dime/current/msg04690.html >> and then the comment in issue tracker: >> http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:1 >> >> From my side, I see this issue resolved. >> >> - Jouni >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From kprasad@sandvine.com Mon Mar 5 02:45:02 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536C021F8644 for ; Mon, 5 Mar 2012 02:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzVbwYWcJfiO for ; Mon, 5 Mar 2012 02:45:01 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 75AE621F8624 for ; Mon, 5 Mar 2012 02:45:01 -0800 (PST) Received: from blr-exch-1.sandvine.com (10.30.4.60) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 5 Mar 2012 05:45:00 -0500 Received: from BLR-EXCH-1.sandvine.com ([fe80::b896:bd62:3a8d:e51d]) by blr-exch-1.sandvine.com ([fe80::b896:bd62:3a8d:e51d%16]) with mapi id 14.01.0289.001; Mon, 5 Mar 2012 16:09:54 +0530 From: Krishna Prasad To: Jouni Thread-Topic: [Dime] wrong diameter Identity in CEA Thread-Index: Acz3dEObmyI/SGtSSsC+/7A6rM5NeAAG882AABxCEQAADLuPcAAHaGWAAJp1I1A= Date: Mon, 5 Mar 2012 10:39:52 +0000 Message-ID: References: <4F505044.3030406@gmail.com> <5DCE5774-E39B-4700-9757-E53F6BFE7102@gmail.com> In-Reply-To: <5DCE5774-E39B-4700-9757-E53F6BFE7102@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.10.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] wrong diameter Identity in CEA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 10:45:02 -0000 -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, March 02, 2012 7:52 PM To: Krishna Prasad Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] wrong diameter Identity in CEA Right, thanks for clarification.. I agree the RFC is silent of this but do you have other choices than dropping the connection if the peer you talk to is not who you think it should be? Either silently or preferably using Disconnect. - Jouni Probably sending DPR with proper disconnect-cause (nearest will be DO_NOT_W= ANT_TO_TALK_TO_YOU) can be a good idea. Not sure what others think. On Mar 2, 2012, at 7:22 AM, Krishna Prasad wrote: >=20 >=20 > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@gmail.com]=20 > Sent: Friday, March 02, 2012 10:15 AM > To: jouni korhonen > Cc: Krishna Prasad; dime@ietf.org > Subject: Re: [Dime] wrong diameter Identity in CEA >=20 > On 3/1/2012 10:15 PM, jouni korhonen wrote: >> Hi, >>=20 >> I don't quite understand what you mean by "wrong identity". Receiving >> a CER or CEA from a "wrong" peer is different from what RFC3588 says >> "unknown" peer, at least to me. >>=20 >> Section 5.3 says: >>=20 >> CERs received from unknown peers MAY be silently discarded, or a CEA >> MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. >> In both cases, the transport connection is closed. If the local >> ^^^^^^^^^^^^^^ >>=20 >> Which is pretty clear to me. >=20 > It's quite clear, but it also doesn't have anything to do w/the question > which I believe had to do with the handling of a CEA containing a > Diameter identity that was incorrect (possibly due to a masquerade > attack). >=20 > Yes, Glen has summarized my question in a more clear way, the incorrect D= iameter identity in CEA may be due to wrong configurations also. >=20 >>=20 >> - Jouni >>=20 >> On Mar 1, 2012, at 8:26 AM, Krishna Prasad wrote: >>=20 >>> Hi All, >>> The base RFC (and also the bis) says that if a CER is received from = an unexpected peer (wrong diameter identity in Orig host AVP) CEA will be s= ent with unknown peer error. >>> But if the diameter Identity in CEA is wrong (i.e. the initiator is exp= ecting some other identity in CEA) what is the expected behavior; does the = node silently close the connection or this is not at all an error? I think = RFC is silent on this. >>>=20 >>> Regards >>> Prasad. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From miguel.a.garcia@ericsson.com Mon Mar 5 06:22:21 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B4421F86B0 for ; Mon, 5 Mar 2012 06:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDyRigfL3JLw for ; Mon, 5 Mar 2012 06:22:21 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7E421F86DC for ; Mon, 5 Mar 2012 06:22:20 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-d2-4f54cc1bacfb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0B.7D.01970.B1CC45F4; Mon, 5 Mar 2012 15:22:19 +0100 (CET) Received: from [159.107.24.226] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Mar 2012 15:22:18 +0100 Message-ID: <4F54CC1A.7060906@ericsson.com> Date: Mon, 5 Mar 2012 15:22:18 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Frank Brockners (fbrockne)" References: <4F4B8F2E.4070604@ericsson.com> <0D212BD466921646B58854FB79092CEC07C40C61@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC07C40C61@XMB-AMS-106.cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "dime@ietf.org" Subject: Re: [Dime] Comments on Diameter NAT control -13 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 14:22:21 -0000 Hi Frank, Thanks for taking the time to reply with so many details. I think I now better understand how the NCR command works. I would have designed it slightly differently, but I can live with the way it works. BR, Miguel On 28/02/2012 17:34, Frank Brockners (fbrockne) wrote: > Hi Miguel, > > thanks for your email and also thanks for brining the discussion to the > list. IMHO there are two different views, depending on what you identify > as the entity that DNCA manages. Right now the managed entity is the > _session_ associated with an endpoint. To manage the life-cycle of a > session one would need to be able to > a) initialize/create it > b) update parameters associated with the session > c) terminate it > d) query the state of one or multiple sessions > The NCR command currently handles a), b), and d) - and the action is > indicated using a single de-multiplexer, the NC-Request-Type AVP. a) is > served by INITIAL_REQUEST, b) by UPDATE_REQUEST, and d) by > QUERY_REQUEST. c) is served by the normal STA command. Updating a > session could include adding bindings, removing bindings, changing the > maximum number of binding supported on a session. What kind of update > actions are needed are determined by the AVPs present in an update > request. This obviously means that you need to evaluate all the AVPs in > the NCR/Update-Request message. If a future revision of the protocol > would require additional parameters to be managed on a session (think of > e.g. managing the timeouts for bindings on a per-endpoint basis), we'd > just add the additional AVP - changes to the protocol would be > relatively small - though an implementation would of course need to > evaluate yet another AVP. > > In your email below you inspire a somewhat different approach. You seem > to hint at making the different objects kept at NAT-device the managed > entity for DNCA. Those objects at the NAT-devices are obviously the > NAT-bindings, but are not limited to bindings, because we also manage > other objects such as the maximum amount of bindings allowed for a > particular endpoint. > > If we'd follow this logic then we some form of "command" to install, > update, and remove these objects at the NAT-device. These commands would > not be limited to individual bindings, but should equally apply to other > objects such as the Max-NAT-Bindings. > That said, the need for managing the session (e.g. query the state) does > not disappear. This means that you'd need to differentiate between > - session level commands (init, update, terminate, query) and > - for the specific use of "update" a session, implement either a > specific de-multiplexer or add additional commands > > Given that an implementation would need to check the validity of a > message in any case, would adding a multiplexer AVP - for the use within > "update" - really add much? This multiplexer would likely come in the > form of a bit-mask, with a bit for "NAT-Control-Install AVP present", > "NAT-Control-Remove AVP present", etc. - and the bit-mask should be long > enough so that we can leave room for future additions (think of the > timeout example above). All the bit mask AVP would do is off-load us > from checking all the AVPs - though, per what I said above, you likely > need to check all the AVPs in any case to do a validity check on the > message, hence I'm not sure what we gain here. > The other alternative would be to add additional commands per parameter, > e.g. UPDATE-ADD-BINDING, UPDATE-REMOVE-BINDING, > UPDATE-CHANGE-MAX_BINDINGS... etc. - though this would make extensions > more difficult - and at the same time would no longer allow us to change > multiple parameters/objects of an endpoint session with a single command > (i.e. add bindings and remove binding and change max-bindings). > > Thoughts? > > Thanks, Frank > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > Of Miguel >> A. Garcia >> Sent: Monday, February 27, 2012 3:12 PM >> To: dime@ietf.org >> Subject: [Dime] Comments on Diameter NAT control -13 >> >> Hi: >> >> I was doing a review of earlier versions of the Diameter NAT control >> draft for the Gen-ART team. And I have been in touch with the authors, >> keeping an eye to this draft. >> >> I would like to share one of the comments with other members of the >> working group to see if the WG can better get an opinion. >> >> - NCR demultiplexor. >> As I understand, the NCR command has three main functions: create or >> update a binding, remove a binding, or query for a binding. At the > moment >> there is not a single AVP that clearly indicates the function of the >> command. A server has to inspect the presence of the > NAT-Control-Install >> to see if this is a create or update (the difference between create an >> update is given by the NCR-Request-Type AVP). Or the presence of the >> NAT-Control-Remove to see that this is a remove. Or the > NCR-Request-Type >> set to QUERY_REQUEST to see that this is a query. >> >> >> I was arguing that is a good protocol design practice to have clear > and >> easily expandable semantics in messages. In this case, there is no > clear >> semantics of the NCR command. The receiver of this command should > inspect >> NCR-Request-Type and NAT-Control-Remove to find out what this is all > about. >> >> This mechanism also poses a future problem, if an application needs to >> add additional semantics to NCR. So, I was recommending to have a > single >> AVP that clearly denotes the function of the NCR command >> >> What do the WG think about? >> >> /Miguel >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From mark@azu.ca Mon Mar 5 10:56:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA8C21F8871 for ; Mon, 5 Mar 2012 10:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NyuXVVIpQee for ; Mon, 5 Mar 2012 10:55:59 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 39DE421F8866 for ; Mon, 5 Mar 2012 10:55:57 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so4252185vcb.31 for ; Mon, 05 Mar 2012 10:55:56 -0800 (PST) Received-SPF: pass (google.com: domain of mark@azu.ca designates 10.52.95.74 as permitted sender) client-ip=10.52.95.74; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mark@azu.ca designates 10.52.95.74 as permitted sender) smtp.mail=mark@azu.ca Received: from mr.google.com ([10.52.95.74]) by 10.52.95.74 with SMTP id di10mr36822202vdb.46.1330973756779 (num_hops = 1); Mon, 05 Mar 2012 10:55:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.95.74 with SMTP id di10mr31502455vdb.46.1330973756566; Mon, 05 Mar 2012 10:55:56 -0800 (PST) Received: by 10.52.36.233 with HTTP; Mon, 5 Mar 2012 10:55:51 -0800 (PST) In-Reply-To: <4F533CDB.1050404@gmail.com> References: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com> <4F533CDB.1050404@gmail.com> Date: Mon, 5 Mar 2012 13:55:51 -0500 Message-ID: From: Mark Jones To: Glen Zorn , jouni korhonen Content-Type: multipart/alternative; boundary=20cf307f3406f72c3904ba837989 X-Gm-Message-State: ALoCoQn7j/66PRgQrRSc2EPpUi+RbEpr7za6cvLsiiTlFCj4lVYur72kH+ygZIuxoTWcnRoLWrP0 Cc: dime@ietf.org Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 18:56:00 -0000 --20cf307f3406f72c3904ba837989 Content-Type: text/plain; charset=ISO-8859-1 > OK, what am I supposed to be updating/clarifying, the ticket or the draft? My request was to update the ticket. I assume Glen's "Yes. Its intentional" in the ticket was referring to the absence of requirement keywords in this 4.5.8 sub-clause: - If this AVP is not present, then the session is assigned to an unnamed tunnel. If an unnamed tunnel does not yet exist between the specified endpoints, then it is established and used for this session and for subsequent ones established without the Tunnel-Assignment-Id attribute. A tunnel initiator MUST NOT assign a session for which a Tunnel-Assignment-Id AVP was not specified to a named tunnel (i.e., one that was initiated by a session specifying this AVP). My request was to add Glen's explanation of the intent to the ticket so we have at least captured our agreed interpretation of this sub-clause. I did not think Glen's response was referring to the lower case "should" in section 4.5.8. I understand from RFC2119 that a "SHOULD" is a "should" is a "ShOuLd". Correct? /Mark On Sun, Mar 4, 2012 at 4:58 AM, Glen Zorn wrote: > On 3/3/2012 6:24 PM, jouni korhonen wrote: > > > Hi, > > > > Ok good. I support adding the clarification below. > > OK, what am I supposed to be updating/clarifying, the ticket or the > draft? I don't understand the term 'clarify' in the latter case: the > draft seems pretty much crystalline, esp. insofar as the words in > question are intentionally not capitalized. > > > > > Glen, once you have done the update I'll take the required > > actions to advance this document. > > > > - Jouni > > > > > > On Mar 3, 2012, at 12:47 AM, Mark Jones wrote: > > > >> Hi Jouni, > >> > >> I'm OK to close the ticket but I suggest adding Glen's explanation to > it: > >> > >>>> And the reasoning behind is? > >> > >>> OK,I give: how many different reasons could there be? I can only think > >>> of one: the text is meant to be descriptive, not prescriptive, that is, > >>> no rationale is required for acting differently and Diameter > >>> interoperability is not, AFAICT, effected. > >> > >> /Mark > >> > >> On Fri, Mar 2, 2012 at 2:51 AM, Jouni wrote: > >> Mark, > >> > >> Are you OK for me to close the Ticket #19 ? Ref these emails: > >> http://www.ietf.org/mail-archive/web/dime/current/msg04690.html > >> and then the comment in issue tracker: > >> http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:1 > >> > >> From my side, I see this issue resolved. > >> > >> - Jouni > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > --20cf307f3406f72c3904ba837989 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> OK, what am I supposed to be updating/clarifying, the ticket or t= he=A0draft?=A0

My request was to update the ticket= . I assume Glen's "Yes. Its intentional" in the ticket was re= ferring to the absence of requirement keywords in this 4.5.8=A0sub-clause:<= /div>
  • If this AVP = is not present, then the session is assigned to an=A0unnamed tunnel. If an= unnamed tunnel does not yet exist between=A0the specified endpoints, then = it is established and used for this=A0session and for subsequent ones estab= lished without the Tunnel-Assignment-Id attribute. A tunnel initiator MUST= NOT assign a=A0session for which a Tunnel-Assignment-Id AVP was not specif= ied to=A0a named tunnel (i.e., one that was initiated by a session=A0specif= ying this AVP).
My reques= t was to add Glen's explanation of the intent to the ticket so we have = at least captured our agreed interpretation of this=A0sub-clause.

I did not think Glen's response was referring to th= e lower case "should" in section 4.5.8. I understand from RFC2119= that a "SHOULD" is a "should" is a "ShOuLd".= Correct?

/Mark


On Sun, Mar 4, 2012 at 4:58 AM, Glen Zorn <= ;glenzorn@gmail.com> wr= ote:
On 3/3/2012 6:24 PM, jouni= korhonen wrote:

> Hi,
>
> Ok good. I support adding the clarification below.

OK, what am I supposed to be updating/clarifying, the ticket or the draft? =A0I don't understand the term 'clarify' in the latter c= ase: the
draft seems pretty much crystalline, esp. insofar as the words in
question are intentionally not capitalized.

>
> Glen, once you have done the update I'll take the required
> actions to advance this document.
>
> - Jouni
>
>
> On Mar 3, 2012, at 12:47 AM, Mark Jones wrote:
>
>> Hi Jouni,
>>
>> I'm OK to close the ticket but I suggest adding Glen's exp= lanation to it:
>>
>>>> And the reasoning behind is?
>>
>>> OK,I give: how many different reasons could there be? =A0I can= only think
>>> of one: the text is meant to be descriptive, not prescriptive,= that is,
>>> no rationale is required for acting differently and Diameter >>> interoperability is not, AFAICT, effected.
>>
>> /Mark
>>
>> On Fri, Mar 2, 2012 at 2:51 AM, Jouni <jouni.nospam@gmail.com> wrote:
>> Mark,
>>
>> Are you OK for me to close the Ticket #19 ? Ref these emails:
>> http://www.ietf.org/mail-archive/web/dime/curre= nt/msg04690.html
>> and then the comment in issue tracker:
>> http://trac.tools.ietf.org/wg/dime/trac/ticket/19#c= omment:1
>>
>> From my side, I see this issue resolved.
>>
>> - Jouni
>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--20cf307f3406f72c3904ba837989-- From glenzorn@gmail.com Tue Mar 6 00:14:03 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF2D21E80B3 for ; Tue, 6 Mar 2012 00:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aCAGbY3XZUy for ; Tue, 6 Mar 2012 00:14:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A788421E808C for ; Tue, 6 Mar 2012 00:14:02 -0800 (PST) Received: by iazz13 with SMTP id z13so7851720iaz.31 for ; Tue, 06 Mar 2012 00:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lzI5eB6ohmQ9MxgiWHBBpeTyigHK1F5z/KHqQpAfIjI=; b=gIULP87vk4WbLT/JDb1BNcCfIBMoyG4JftBN+qNeZDOVqyQVBe+66k6O0w8SEzJWR6 D+PyeZ/CbFoloKPueclA03M3XP5SGPlM3VQdTY4SLqzzpt+yIUiwfEmNmNf0RtTSh0sY SWxOgvW9Nb9TBTYWtebXjYxtBDlcfxX6N0SfQ9OtcpNB5SAeVjH7WJ/v2hmFe8dg84pQ SJuz5J4QBJw4/3QwhoTonULylFVMpQyCOE1M4G1n73HFSxMgGEDBFoQ41fdIwOpznWNL QgT6hOZ7iTBqhgYxS6Af+R6qZoLNdTsDogD8V/eEzLVumTN2yiJ707QhayuiiGYKgrVg m5nQ== Received: by 10.50.182.231 with SMTP id eh7mr7994503igc.29.1331021641579; Tue, 06 Mar 2012 00:14:01 -0800 (PST) Received: from [192.168.1.98] (ppp-58-11-150-180.revip2.asianet.co.th. [58.11.150.180]) by mx.google.com with ESMTPS id cx9sm14022227igc.12.2012.03.06.00.13.56 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 00:13:59 -0800 (PST) Message-ID: <4F55C741.3050200@gmail.com> Date: Tue, 06 Mar 2012 15:13:53 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mark Jones References: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com> <4F533CDB.1050404@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 08:14:03 -0000 On 3/6/2012 1:55 AM, Mark Jones wrote: >> OK, what am I supposed to be updating/clarifying, the ticket or > the draft? > > My request was to update the ticket. OK, thanks. > I assume Glen's "Yes. Its > intentional" in the ticket was referring to the absence of requirement > keywords in this 4.5.8 sub-clause: > > * If this AVP is not present, then the session is assigned to > an unnamed tunnel. If an unnamed tunnel does not yet exist > between the specified endpoints, then it is established and used for > this session and for subsequent ones established without the > Tunnel-Assignment-Id attribute. A tunnel initiator MUST NOT assign > a session for which a Tunnel-Assignment-Id AVP was not specified > to a named tunnel (i.e., one that was initiated by a > session specifying this AVP). > > My request was to add Glen's explanation of the intent to the ticket so > we have at least captured our agreed interpretation of this sub-clause. > > I did not think Glen's response was referring to the lower case "should" > in section 4.5.8. Actually, it was referring to everything in that section after this: If a tunnel initiator supports the Tunnel-Assignment-Id AVP, then it should assign a session to a tunnel in the following manner: > I understand from RFC2119 that a "SHOULD" is a > "should" is a "ShOuLd". Correct? I guess that this comes from the statement in the abstract for 2119 that In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. My interpretation of this is a little different, though: I take it as a description of the existing practice at the time, not as part of the codification of future practice that the rest of the document specifies. > > /Mark > > > On Sun, Mar 4, 2012 at 4:58 AM, Glen Zorn > wrote: > > On 3/3/2012 6:24 PM, jouni korhonen wrote: > > > Hi, > > > > Ok good. I support adding the clarification below. > > OK, what am I supposed to be updating/clarifying, the ticket or the > draft? I don't understand the term 'clarify' in the latter case: the > draft seems pretty much crystalline, esp. insofar as the words in > question are intentionally not capitalized. > > > > > Glen, once you have done the update I'll take the required > > actions to advance this document. > > > > - Jouni > > > > > > On Mar 3, 2012, at 12:47 AM, Mark Jones wrote: > > > >> Hi Jouni, > >> > >> I'm OK to close the ticket but I suggest adding Glen's > explanation to it: > >> > >>>> And the reasoning behind is? > >> > >>> OK,I give: how many different reasons could there be? I can > only think > >>> of one: the text is meant to be descriptive, not prescriptive, > that is, > >>> no rationale is required for acting differently and Diameter > >>> interoperability is not, AFAICT, effected. > >> > >> /Mark > >> > >> On Fri, Mar 2, 2012 at 2:51 AM, Jouni > wrote: > >> Mark, > >> > >> Are you OK for me to close the Ticket #19 ? Ref these emails: > >> http://www.ietf.org/mail-archive/web/dime/current/msg04690.html > >> and then the comment in issue tracker: > >> http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:1 > >> > >> From my side, I see this issue resolved. > >> > >> - Jouni > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > From trac+dime@trac.tools.ietf.org Tue Mar 6 02:49:43 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2D21F8621 for ; Tue, 6 Mar 2012 02:49: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-3L4Db3kFSG for ; Tue, 6 Mar 2012 02:49:43 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 73E1421F8618 for ; Tue, 6 Mar 2012 02:49:43 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S4rxR-0006FN-01; Tue, 06 Mar 2012 05:49:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: dime@ietf.org, gwz@net-zen.net X-Trac-Project: dime Date: Tue, 06 Mar 2012 10:49:28 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:2 Message-ID: <079.56d2d471ec8292dfb9696a937a988193@trac.tools.ietf.org> References: <064.7acde6a2bdf9a7529b6f9f784b27fa78@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <064.7acde6a2bdf9a7529b6f9f784b27fa78@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, gwz@net-zen.net, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] [dime] #19: Tunnel-Assignment-Id AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 06 Mar 2012 10:49:44 -0000 #19: Tunnel-Assignment-Id AVP Comment (by gwz@…): The reasoning behind this is that the text is meant to be descriptive, not prescriptive; that is, no rationale is required for acting differently and Diameter interoperability is not, AFAICT, effected. -- -----------------------------+--------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: defect | Status: new Priority: major | Milestone: Component: rfc4005bis | Version: Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+--------------------- Ticket URL: dime From dromasca@avaya.com Tue Mar 6 03:29:14 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7021F88C6 for ; Tue, 6 Mar 2012 03:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.359 X-Spam-Level: X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 134XZyGK0Aas for ; Tue, 6 Mar 2012 03:29:14 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 64D3C21F88C5 for ; Tue, 6 Mar 2012 03:29:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFr0VU/GmAcF/2dsb2JhbABDtQeBB4F9AQEBAQMSHgo/DAQCAQgNCA0GDAsBBgFFEQEBBAESCBqHZaNZlECPe2MEm0OKEYJk X-IronPort-AV: E=Sophos;i="4.73,539,1325480400"; d="scan'208";a="334746086" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Mar 2012 06:29:10 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Mar 2012 06:21:43 -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, 6 Mar 2012 12:29:08 +0100 Message-ID: In-Reply-To: <4F55C741.3050200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC4005bis and issue tracker Ticket #19 Thread-Index: Acz7cRq/bMW/NG7rQwWL3FrT09BPMQAGv3Tg References: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com><4F533CDB.1050404@gmail.com> <4F55C741.3050200@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , "Mark Jones" Cc: dime@ietf.org Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 11:29:14 -0000 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Glen Zorn >=20 > > I understand from RFC2119 that a "SHOULD" is a > > "should" is a "ShOuLd". Correct? >=20 > I guess that this comes from the statement in the abstract for 2119 > that >=20 > In many standards track documents several words are used to signify > the requirements in the specification. These words are often > capitalized. >=20 > My interpretation of this is a little different, though: I take it as a > description of the existing practice at the time, not as part of the > codification of future practice that the rest of the document > specifies. >=20 [[DR]] As Glen says. More specifically in a normative document, wherever interoperability on the wire is impacted the good practice is to use capitalized keywords. Otherwise use them scarcely if at all.=20 Dan From trac+dime@trac.tools.ietf.org Tue Mar 6 03:48:06 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3344221F88B0 for ; Tue, 6 Mar 2012 03:48:06 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+wCmJxjx8V1 for ; Tue, 6 Mar 2012 03:48:05 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD921F887D for ; Tue, 6 Mar 2012 03:48:05 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S4ss0-000305-4L; Tue, 06 Mar 2012 06:47:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: dime@ietf.org, gwz@net-zen.net, jouni.nospam@gmail.com X-Trac-Project: dime Date: Tue, 06 Mar 2012 11:47:55 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/19#comment:3 Message-ID: <079.8c797164418861c365520aa21d907a4e@trac.tools.ietf.org> References: <064.7acde6a2bdf9a7529b6f9f784b27fa78@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <064.7acde6a2bdf9a7529b6f9f784b27fa78@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, gwz@net-zen.net, jouni.nospam@gmail.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] [dime] #19: Tunnel-Assignment-Id AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 06 Mar 2012 11:48:06 -0000 #19: Tunnel-Assignment-Id AVP Changes (by jouni.nospam@…): * cc: jouni.nospam@… (added) * status: new => closed * resolution: => fixed -- -----------------------------+--------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: defect | Status: closed Priority: major | Milestone: Component: rfc4005bis | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+--------------------- Ticket URL: dime From mark@azu.ca Tue Mar 6 06:15:49 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD99C21F88FC for ; Tue, 6 Mar 2012 06:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJPX6Bx-5oPX for ; Tue, 6 Mar 2012 06:15:49 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A97921F8659 for ; Tue, 6 Mar 2012 06:15:38 -0800 (PST) Received: by vbbez10 with SMTP id ez10so5094111vbb.31 for ; Tue, 06 Mar 2012 06:15:37 -0800 (PST) Received-SPF: pass (google.com: domain of mark@azu.ca designates 10.52.240.177 as permitted sender) client-ip=10.52.240.177; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mark@azu.ca designates 10.52.240.177 as permitted sender) smtp.mail=mark@azu.ca Received: from mr.google.com ([10.52.240.177]) by 10.52.240.177 with SMTP id wb17mr41499369vdc.63.1331043337707 (num_hops = 1); Tue, 06 Mar 2012 06:15:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.240.177 with SMTP id wb17mr35480216vdc.63.1331043337574; Tue, 06 Mar 2012 06:15:37 -0800 (PST) Received: by 10.52.36.233 with HTTP; Tue, 6 Mar 2012 06:15:37 -0800 (PST) In-Reply-To: References: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com> <4F533CDB.1050404@gmail.com> <4F55C741.3050200@gmail.com> Date: Tue, 6 Mar 2012 09:15:37 -0500 Message-ID: From: Mark Jones To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn1OaL3qIVID62I6MJUjGo29rKaRiUq3vCwd45wLI0ctpdNyr37+wGD6P688KTF9Olm6JH8 Cc: dime@ietf.org Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 14:15:49 -0000 Hi Dan, > [[DR]] As Glen says. More specifically in a normative document, wherever > interoperability on the wire is impacted the good practice is to use > capitalized keywords. Otherwise use them scarcely if at all. > Agreed. I follow this practice but I recently noticed that the Terminology section in some RFCs (like 4005) have: The key words "MUST", ... But others (e.g. RFC3920) have: The capitalized key words "MUST",... Should I interpret a lower-case "should" differently in these two RFCs? /Mark From dromasca@avaya.com Tue Mar 6 06:58:53 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7921F8935 for ; Tue, 6 Mar 2012 06:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.363 X-Spam-Level: X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ3vkR58OGej for ; Tue, 6 Mar 2012 06:58:52 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC2321F86EB for ; Tue, 6 Mar 2012 06:58:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIslVk+HCzI1/2dsb2JhbABDtGuBB4F9AQEBAQMSHgo/DAQCAQgNBAQBAQsGDAsBBgFFCQgBAQQTCBqHZZ0LnCCPe2MEm0SKEYJk X-IronPort-AV: E=Sophos;i="4.73,540,1325480400"; d="scan'208";a="334796156" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Mar 2012 09:58:45 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Mar 2012 09:43:40 -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, 6 Mar 2012 15:58:43 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC4005bis and issue tracker Ticket #19 Thread-Index: Acz7o52Kcf1hGRhRSdusTQDiO9nxZQABcLOw References: <899A65F7-2ADD-4386-8F9F-A7B6B1DAE10B@gmail.com><4F533CDB.1050404@gmail.com><4F55C741.3050200@gmail.com> From: "Romascanu, Dan (Dan)" To: "Mark Jones" Cc: dime@ietf.org Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 14:58:53 -0000 > -----Original Message----- > From: Mark Jones [mailto:mark@azu.ca] > Sent: Tuesday, March 06, 2012 4:16 PM > To: Romascanu, Dan (Dan) > Cc: Glen Zorn; dime@ietf.org > Subject: Re: [Dime] RFC4005bis and issue tracker Ticket #19 >=20 > Hi Dan, >=20 > > [[DR]] As Glen says. More specifically in a normative document, > wherever > > interoperability on the wire is impacted the good practice is to use > > capitalized keywords. Otherwise use them scarcely if at all. > > >=20 > Agreed. I follow this practice but I recently noticed that the > Terminology section in some RFCs (like 4005) have: >=20 > The key words "MUST", ... >=20 > But others (e.g. RFC3920) have: >=20 > The capitalized key words "MUST",... >=20 > Should I interpret a lower-case "should" differently in these two RFCs? >=20 > /Mark No, I do not think the interpretation is different. It is rather about the automatic tools having started to prompt rigorously to the boilerplate text deviations at some point in time.=20 Dan From glenzorn@gmail.com Wed Mar 7 00:03:38 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42C21E80A8; Wed, 7 Mar 2012 00:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFdaSmuNVF+d; Wed, 7 Mar 2012 00:03:37 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB26221E807D; Wed, 7 Mar 2012 00:03:36 -0800 (PST) Received: by ghbg16 with SMTP id g16so3068657ghb.31 for ; Wed, 07 Mar 2012 00:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DWeSLnjhcPHv7FfQGGTBccXkIfX3d4tMAdIk2Vc6Syo=; b=EYK3BObb8GS0cf2N/GOwZymivwxPN/LL6IK9hZQ4vs9NNwpQ/XlCtRcPqcurziCzN4 pdn07DwUrA2zG5soyLJgjXpYQV2KQowsIW7AGiwNdv8g5BGfYLQBLwQsBpDA3qO5tT1C WAbpOY2Rw7Ye71S0h1AiRocK9u/mAtkwSag3ctHXyGdD/fIyNEkJIYyUukbecJ8i65n6 SCQGvLBVYdcSQ8owQVTaOQA7LY2GJpuI+SAIDuV0TTCqn+mavFWWJDFH0E08biBSuhxb YJXCd3+Odd2lGbsYF+Vv4rkWs58sDgCnbczp50IvaMPWtakIOv9H13gGas4uhOBBRw2c KMsw== Received: by 10.236.190.134 with SMTP id e6mr1772738yhn.98.1331107416491; Wed, 07 Mar 2012 00:03:36 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-24-129.revip2.asianet.co.th. [124.120.24.129]) by mx.google.com with ESMTPS id p41sm56268502yhj.14.2012.03.07.00.03.31 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 00:03:35 -0800 (PST) Message-ID: <4F571650.5010103@gmail.com> Date: Wed, 07 Mar 2012 15:03:28 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Sparks References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> In-Reply-To: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 08:03:38 -0000 On 9/21/2011 4:17 AM, Robert Sparks wrote: > Robert Sparks has entered the following ballot position for > draft-ietf-dime-rfc3588bis-29: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The document reflects the change of the name of the Well-Known > IANA policy definition from "IETF Consensus" to "IETF Review", but > seems to state that this is a change of policy rather than a change > of the policy name (as explained in RFC5226). Specifically, it says > "now only require IETF Review as opposed to an IETF Consensus". > Has the working group captured what it intended? I don't think so; how about this: OLD: AVPs may be allocated following Expert Review (or Designated Expert) with Specification Required [RFC5226]. As a change from RFC3588, a block allocation (release of more than 3 at a time for a given purpose) now only require IETF Review as opposed to an IETF Consensus in RFC3588. NEW: AVPs may be allocated following Expert Review (or Designated Expert) with Specification Required [RFC5226]. A block allocation (release of more than 3 AVPs at a time for a given purpose) requires IETF Review. > > This sentence in section 2.1 is not clear: > For TLS [RFC5246] and DTLS [RFC4347], a Diameter > node that initiate a connection prior to any message exchanges MUST > run on port [TBD]. > What was its intent? It could be misread to say that you cannot establish > a connection on any other port than [TBD]. I'm not sure that that would be a mis-reading. > > In the new text on dynamic agent discovery, Section 5.2 part 3 - > should an element that's looked up SRV records as specified in this > item follow all of the requirements in RFC 2782 if multiple SRV records > are returned (in particular, following the balancing algorithm over > records with the same Priority)? Shouldn't this section reference RFC 2782? Makes sense to me. How about this: OLD: 3. If no NAPTR records are found, the requester directly queries for SRV records '_diameter._sctp'.realm, '_diameter._dtls'.realm, '_diameter._tcp'.realm and '_diameter._tls'.realm depending on the requesters network protocol capabilities. If SRV records are found then the requester can perform address record query (A RR's and/or AAAA RR's) for the target hostname specified in the SRV records. If no SRV records are found, the requester gives up. NEW: 3. If no NAPTR records are found, the requester directly queries for one of the following SRV records: for Diameter over TCP, use "_diameter._tcp.realm"; for Diameter over TLS, use "_diameters._tcp.realm"; for Diameter over SCTP, use "_diameter._sctp.realm"; for Diameter over DTLS, use "_diameters._sctp.realm". If SRV records are found then the requester can perform address record query (A RR's and/or AAAA RR's) for the target hostname specified in the SRV records following the rules given in Gulbrandsen, et al. [RFC2782]. If no SRV records are found, the requester gives up. > > In the new text on the Election Process, "lexicographically succeeds" needs > additional description. Not quite sure why: IIRC, the term was chosen because it precisely states the desired operation and is well-understood (straight out of Intro to CS, actually). > > The note at the end of 6.1 is very ambiguous - does "this section" mean > just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those > subsections? Either way, it leaves the requirements language very hard > to follow. Does this say certain implemenentations MAY ignore some MUSTs? > If so, which ones? Again, I'm having trouble seeing any ambiguity here: the word "this" very specific and the phrase "this section", if present in a section, seems only to denote that section, not any sections that might follow or precede it. Maybe cut down on the caffeine? ;-) > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In section 1.3.1's second paragraph, starting the second sentence with > "Typically," is likely to introduce confusion about the allocation policy. How can it introduce confusion about allocation policy _in this document_ when the whole paragraph is just suggesting policies for _other documents_? > Why is the word needed in this sentence? Because it's not specifying a rule, it's just making a suggestion. > > In section 2, 2nd to last paragraph before section 2.1: This edit (moving > how tranparency is described) resulted in a sentence that says Diameter Relays > and redirect agents MUST support all Diameter applications. Please consider > touching it again to make it clearer that those elements MUST be transparent > to the applications, and as a result trivially support them. It's hard to see the difference. > > In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP, > please consider pointing out that section 2.2 still requires _SOME_ security > mechanism be used. The reason why the initiator reverts is that the peer only supports RFC 3588, which requires some security mechanism to be used. > > The edits to the first paragraph of the description of AVP flags left > the sentence "Unrecognized bits SHOULD be considered an error." unsupported. > It's not clear (without looking at the diff to 3588) what bits might > possibly be unrecognized. I think that this is correct: any unrecognized bit would have to be one of the 'r' bits it seems & a sender MUST set all the r' bits to 0 so this can never happen (with a conformant implementation. How about we just remove that sentence? > > In section 6.1.2, can the document say why the hop-by-hop identifier > SHOULD be locally unique rather than MUST be? I don't know; anybody? > > > NITS: > In section 1.3.1 paragraph 1, the reference to 11.4 should be 11.3. Fixed. > > Section 2.7 Realm Name: s/that is MUST/that MUST/ Fixed > > Section 6.1.9: s/list of commonly recommended/list of common recommendations/ > Fixed. > Something is wrong with this line in section 7.2 > (The line is unchanged from 3588, but if this is a bug, it should be > addressed at some point). > ::= < Diameter Header: code, ERR [PXY] > > That has either one too many or one too few commas in it. I think that this should read ::= < Diameter Header: code, ERR [, PXY] > > > The following is a pedantic nit, but please consider addressing it. > In several places (both in text from 3588 and new text introduced as > part of this effort), the text refers to the definitions of commands > in the representational language defined in section 3.2 as ABNF. For > example: > The Grouped Data field has the following ABNF grammar: > > Proxy-Info ::= < AVP Header: 284 > > { Proxy-Host } > { Proxy-State } > * [ AVP ] > > That is not ABNF. Instead, it is a well formed message in a language described > by the ABNF in section 3.2. It would be better to say something like > "The Grouped data field has the following Command Code specification:". This particular pedantic nit seems very popular amongst the IESG ;-). I would like it very much if you folks could come to a consensus as to whether it must be changed and, if so, how to change it. TIA! > > > > > From gwz@net-zen.net Wed Mar 7 19:07:52 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3626821E801E for ; Wed, 7 Mar 2012 19:07:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5aJDD8hGSaQ for ; Wed, 7 Mar 2012 19:07:48 -0800 (PST) Received: from p3plsmtpa06-07.prod.phx3.secureserver.net (p3plsmtpa06-07.prod.phx3.secureserver.net [173.201.192.108]) by ietfa.amsl.com (Postfix) with SMTP id 7F8A621F85FC for ; Wed, 7 Mar 2012 19:07:48 -0800 (PST) Received: (qmail 11825 invoked from network); 8 Mar 2012 03:01:08 -0000 Received: from unknown (115.87.64.205) by p3plsmtpa06-07.prod.phx3.secureserver.net (173.201.192.108) with ESMTP; 08 Mar 2012 03:01:07 -0000 Message-ID: <4F5820EC.5080907@net-zen.net> Date: Thu, 08 Mar 2012 10:01:00 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Sparks References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> In-Reply-To: <4F57BF79.7060403@nostrum.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/mixed; boundary="------------020100080507090505010404" Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 03:07:52 -0000 This is a multi-part message in MIME format. --------------020100080507090505010404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/8/2012 3:05 AM, Robert Sparks wrote: > Thanks for the response Glen > > Discussion inline. > ... >>> This sentence in section 2.1 is not clear: >>> For TLS [RFC5246] and DTLS [RFC4347], a Diameter >>> node that initiate a connection prior to any message exchanges MUST >>> run on port [TBD]. >>> What was its intent? It could be misread to say that you cannot establish >>> a connection on any other port than [TBD]. >> I'm not sure that that would be a mis-reading. > If that's the case, consider saying "run only on port". But doesn't that > interact badly > with the peer discovery mechanism? Or are you saying it would be an > error to create > an SRV record that pointed to any port other than TBD? Actually, I'm just not sure (I didn't write this part ;-). I'm hoping that somebody else will chime in... ... >>> In the new text on the Election Process, "lexicographically succeeds" needs >>> additional description. >> Not quite sure why: IIRC, the term was chosen because it precisely >> states the desired operation and is well-understood (straight out of >> Intro to CS, actually). > Rereading this after several months, I think it's fine. My point was you > need to specify > the lexicon. You did (case-insensitive ASCII - so you know "A2"<"AA"). > The way you > point to Appendix D makes it seem that will affect ordering (it > doesn't). Is there a place > in the DNS specs you can point to that makes order comparisons explicit > to remove > all potential ambiguity? Beats me; anybody? > >> >>> The note at the end of 6.1 is very ambiguous - does "this section" mean >>> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those >>> subsections? Either way, it leaves the requirements language very hard >>> to follow. Does this say certain implemenentations MAY ignore some MUSTs? >>> If so, which ones? >> Again, I'm having trouble seeing any ambiguity here: the word "this" >> very specific and the phrase "this section", if present in a section, >> seems only to denote that section, not any sections that might follow or >> precede it. Maybe cut down on the caffeine? ;-) > You didn't answer whether you believe 6.1.1 is part of, or follows, 6.1. I think that 6.1.1 is not part of 6.1; the following subsection _do_ contain RFC 2119 language, while 6.1 doesn't, so I would expect that the broad outline of processing in 6.1 is descriptive while the following subsections are prescriptive. >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> In section 1.3.1's second paragraph, starting the second sentence with >>> "Typically," is likely to introduce confusion about the allocation policy. >> How can it introduce confusion about allocation policy _in this >> document_ when the whole paragraph is just suggesting policies for >> _other documents_? >> >>> Why is the word needed in this sentence? >> Because it's not specifying a rule, it's just making a suggestion. > I don't know what potential confusion I saw at the time. I'll remove the > comment, > but consider changing "should" to "would" in that suggestion. OK. >> >>> In section 2, 2nd to last paragraph before section 2.1: This edit (moving >>> how tranparency is described) resulted in a sentence that says Diameter Relays >>> and redirect agents MUST support all Diameter applications. Please consider >>> touching it again to make it clearer that those elements MUST be transparent >>> to the applications, and as a result trivially support them. >> It's hard to see the difference. > A clarification would make it more obvious that "support" in this > circumstance > means simply "be transparent". Encourage the focus of the implementer > towards > being transparent to an abstract thing rather than making sure they > "support" > whatever the current list of defined applications is. I think we may be talking about two different kinds of transparency. I don't think that redirect agents, in particular, can actually be transparent to the endpoint nodes (since they actually return a message telling where to send the original message) ; relays can probably be transparent, but they need to recognize, at least, any Diameter message that comes to them so that it can be forwarded correctly. > >> >>> In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP, >>> please consider pointing out that section 2.2 still requires _SOME_ security >>> mechanism be used. >> The reason why the initiator reverts is that the peer only supports RFC >> 3588, which requires some security mechanism to be used. > It would hurt to point that out? Just seems like beating a dying (if not dead) horse ;-) >> >>> The edits to the first paragraph of the description of AVP flags left >>> the sentence "Unrecognized bits SHOULD be considered an error." unsupported. >>> It's not clear (without looking at the diff to 3588) what bits might >>> possibly be unrecognized. >> I think that this is correct: any unrecognized bit would have to be one >> of the 'r' bits it seems & a sender MUST set all the r' bits to 0 so >> this can never happen (with a conformant implementation. How about we >> just remove that sentence? > I think you still need it. > > Note that subsequent Diameter applications MAY define additional bits > within the AVP Header, and an unrecognized bit SHOULD be considered an > error. > > The 3588bis text says this now: > New Diameter applications SHOULD NOT define > additional AVP Flag bits. The sender of the AVP MUST set 'r' > (reserved) bits to 0 and the receiver SHOULD ignore all 'r' > (reserved) bits. Unrecognized bits SHOULD be considered an error. > > The new text still leaves the possibility for additional (unrecognized) > AVP bits to show up, > defined by new applications. > > Maybe just swap the last two sentences in the new text? OK ... >>> The following is a pedantic nit, but please consider addressing it. >>> In several places (both in text from 3588 and new text introduced as >>> part of this effort), the text refers to the definitions of commands >>> in the representational language defined in section 3.2 as ABNF. For >>> example: >>> The Grouped Data field has the following ABNF grammar: >>> >>> Proxy-Info ::= < AVP Header: 284 > >>> { Proxy-Host } >>> { Proxy-State } >>> * [ AVP ] >>> >>> That is not ABNF. Instead, it is a well formed message in a language described >>> by the ABNF in section 3.2. It would be better to say something like >>> "The Grouped data field has the following Command Code specification:". >> This particular pedantic nit seems very popular amongst the IESG ;-). I >> would like it very much if you folks could come to a consensus as to >> whether it must be changed and, if so, how to change it. TIA! > Well, I put this in as a comment, not a blocking point. > > I think changing it would make the document more correct, and the suggestion > I make above would fix it and doesn't look too hard to implement. Am I > missing something? My point is that several IESG members have complained about this; I don't mind fixing it, if necessary, but I only want to do it once. Just BTW, as I recall RFC 3588 was gone over with a fine-tooth comb by various ABNF geeks before it was published; since neither the definition of ABNF nor the actual "ABNF" in 3588bis has changed since then I find it rather amazing that it has somehow become defective. --------------020100080507090505010404 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gwz.vcf" YmVnaW46dmNhcmQNCmZuOkdsZW4gWm9ybg0Kbjpab3JuO0dsZW4NCm9yZzpOZXR3b3JrIFpl bg0KYWRyOjs7O1NlYXR0bGU7V0E7O1VTQQ0KZW1haWw7aW50ZXJuZXQ6Z3d6QG5ldC16ZW4u bmV0DQp0ZWw7Y2VsbDorNjYgODcgMDQwIDQ2MTcNCm5vdGU6UEdQIEtleSBGaW5nZXJwcmlu dDogREFEMyBGNUQzIEFDRTYgNDE5NSA5QzVDICAyRUUxIDZFMTcgQjVGNiA1OTUzIEI0NUYg DQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------020100080507090505010404-- From glenzorn@gmail.com Wed Mar 7 21:19:45 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81A721E8042; Wed, 7 Mar 2012 21:19:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aop2fxMuNx8X; Wed, 7 Mar 2012 21:19:45 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F20C121F8473; Wed, 7 Mar 2012 21:19:44 -0800 (PST) Received: by ghbg16 with SMTP id g16so47188ghb.31 for ; Wed, 07 Mar 2012 21:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uywHYTVTgTUgnFyMN0NqksMWzcQhZTKc/IE0JCPQXvA=; b=ayD7eYGWVscv5DaMxOOwGwla8VkKhP5WMOAKDZ4n+ITbgXtqTjJ3ewMHxUU52VZx66 owPZblvzZGM1GAyxI5PO3sLUI6u5N9YRtret1zvojNVIRCVGeBoHwKaYPQbxBJQgrIbX KRRjQRWXdRm4aT+eoDoTDBTw4mDVNBF3he/U+hRGaFBtpXeQ5QIr2sVzlINsySq0YevS BFHIauuwJZdbgxZHz6+mRlWGsip6AxHz73D3PwbZ69o/RrZuZsmtguqZEDbngvejBpDk /+vlV7ZYMgoN+ofjxCp4Oo4H/uS26SMkLtO6PN9ljwA3c/ylCa+TJywIk9nOoiRuqHtL u5Mg== Received: by 10.236.168.71 with SMTP id j47mr9025567yhl.6.1331183984639; Wed, 07 Mar 2012 21:19:44 -0800 (PST) Received: from [192.168.1.98] (ppp-115-87-64-205.revip4.asianet.co.th. [115.87.64.205]) by mx.google.com with ESMTPS id p3sm1282495and.4.2012.03.07.21.19.40 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 21:19:43 -0800 (PST) Message-ID: <4F58416A.7010603@gmail.com> Date: Thu, 08 Mar 2012 12:19:38 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Sparks References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> In-Reply-To: <4F5820EC.5080907@net-zen.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 05:19:45 -0000 On 3/8/2012 10:01 AM, Glen Zorn wrote: ... >>>> The edits to the first paragraph of the description of AVP flags left >>>> the sentence "Unrecognized bits SHOULD be considered an error." unsupported. >>>> It's not clear (without looking at the diff to 3588) what bits might >>>> possibly be unrecognized. >>> I think that this is correct: any unrecognized bit would have to be one >>> of the 'r' bits it seems & a sender MUST set all the r' bits to 0 so >>> this can never happen (with a conformant implementation. How about we >>> just remove that sentence? >> I think you still need it. >> >> Note that subsequent Diameter applications MAY define additional bits >> within the AVP Header, and an unrecognized bit SHOULD be considered an >> error. >> >> The 3588bis text says this now: >> New Diameter applications SHOULD NOT define >> additional AVP Flag bits. The sender of the AVP MUST set 'r' >> (reserved) bits to 0 and the receiver SHOULD ignore all 'r' >> (reserved) bits. Unrecognized bits SHOULD be considered an error. >> >> The new text still leaves the possibility for additional (unrecognized) >> AVP bits to show up, >> defined by new applications. >> >> Maybe just swap the last two sentences in the new text? > > OK How' about this: OLD: AVP Flags The AVP Flags field informs the receiver how each attribute must be handled. New Diameter applications SHOULD NOT define additional AVP Flag bits. The sender of the AVP MUST set 'r' (reserved) bits to 0 and the receiver SHOULD ignore all 'r' (reserved) bits. Unrecognized bits SHOULD be considered an error. NEW: AVP Flags The AVP Flags field informs the receiver how each attribute must be handled. New Diameter applications SHOULD NOT define additional AVP Flag bits. Note however, that new Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. The sender of the AVP MUST set 'r' (reserved) bits to 0 and the receiver SHOULD ignore all 'r' (reserved) bits. ... From jouni.nospam@gmail.com Thu Mar 8 01:40:16 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9513321F8512 for ; Thu, 8 Mar 2012 01:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJdjHidLWbFT for ; Thu, 8 Mar 2012 01:40:16 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6C8321F84E4 for ; Thu, 8 Mar 2012 01:40:15 -0800 (PST) Received: by dakl33 with SMTP id l33so323138dak.31 for ; Thu, 08 Mar 2012 01:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2PVT79CLMzc2jY75fPT6rnW2DVJt7Rwl3y5mrIQXtHU=; b=o1iEe+HhHZrQft8rJrzUJf+drIaBc9KO1HabfWs8gm8qV1R3YDq8qFigKfeA4oqq+R k6Iw+Lu5S6SeMvtN1rWPJPMcYQeFB2pdsCyDoapjNTu9do6LLr7EEdRSbUuiG1iL75O3 PsOek1ZEDjDbRA7R2liqtBFlzu35oOrcschb30xhqWAe6Ap5exdoE7YdeZFOrGCWQHIa WUbwHatkF1bZcWP56uycQ3B/EfxdJ0NQEFlhvRGFBMxOwCG38HUmn+VGg1+QXU2/sWHN NKbzL29WMtJDu+Y0eaR6+esbMly08GBdDuyN27IU9wpZ3L15GnFZnCoSwtqzVHs+kwFj +9Pg== Received: by 10.68.227.193 with SMTP id sc1mr8448092pbc.52.1331199615650; Thu, 08 Mar 2012 01:40:15 -0800 (PST) Received: from [10.255.131.45] ([192.100.123.77]) by mx.google.com with ESMTPS id f10sm2328022pbn.58.2012.03.08.01.40.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 01:40:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <9FBF870D-27E5-4AD2-8B2F-E96C6978BFA4@gmail.com> Date: Thu, 8 Mar 2012 11:40:09 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0A5AA855-C7A4-4ABB-9DCF-088294CDA74F@gmail.com> References: <9FBF870D-27E5-4AD2-8B2F-E96C6978BFA4@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] Agenda call for Dime meeting in IETF#83 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 09:40:16 -0000 Just a reminder. - Jouni & Lionel On Feb 27, 2012, at 11:46 AM, jouni korhonen wrote: > > Folks, > > Our WG meeting has been scheduled to Thursday afternoon session II, which > means we have 2h slot. If you want to have a presentation slot, send a > request to the chairs with abstract, your I-D name, time needed and why > you think the presentation is needed. > > - Jouni & Lionel From internet-drafts@ietf.org Thu Mar 8 01:42:45 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F93C21F8656; Thu, 8 Mar 2012 01:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8IPg+6DTmi8; Thu, 8 Mar 2012 01:42:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815EE21F8648; Thu, 8 Mar 2012 01:42:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308094244.18002.78194.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 01:42:44 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc3588bis-30.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 09:42:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Base Protocol Author(s) : Victor Fajardo Jari Arkko John Loughney Glen Zorn Filename : draft-ietf-dime-rfc3588bis-30.txt Pages : 153 Date : 2012-03-08 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 obsoletes RFC 3588 and must be supported by all new Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-30.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-30.txt From lionel.morand@orange.com Thu Mar 8 10:13:30 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7535B21F8691 for ; Thu, 8 Mar 2012 10:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fVWYTQnehBz for ; Thu, 8 Mar 2012 10:13:29 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C599C21F8685 for ; Thu, 8 Mar 2012 10:13:29 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 707AA16C003; Thu, 8 Mar 2012 19:13:28 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 665FD16C001; Thu, 8 Mar 2012 19:13:28 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 19:13:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 19:13:27 +0100 Message-ID: In-Reply-To: <0A5AA855-C7A4-4ABB-9DCF-088294CDA74F@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Agenda call for Dime meeting in IETF#83 Thread-Index: Acz9D3pHM75Bo6l/ROuw7KIe8juekgARt5mQ References: <9FBF870D-27E5-4AD2-8B2F-E96C6978BFA4@gmail.com> <0A5AA855-C7A4-4ABB-9DCF-088294CDA74F@gmail.com> From: To: , X-OriginalArrivalTime: 08 Mar 2012 18:13:28.0553 (UTC) FILETIME=[29677590:01CCFD57] Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] Agenda call for Dime meeting in IETF#83 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 18:13:30 -0000 Hi jouni, As editor, I would like a slot for discussion on how to progress and = finalize the work on the draft on guidelines. I'm preparing a set of questions that will be sent to the mailing list = before the session. Regards, Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de jouni korhonen Envoy=E9=A0: jeudi 8 mars 2012 10:40 =C0=A0: dime@ietf.org Cc=A0: dime-chairs@tools.ietf.org Objet=A0: Re: [Dime] Agenda call for Dime meeting in IETF#83 Just a reminder. - Jouni & Lionel On Feb 27, 2012, at 11:46 AM, jouni korhonen wrote: >=20 > Folks, >=20 > Our WG meeting has been scheduled to Thursday afternoon session II, = which > means we have 2h slot. If you want to have a presentation slot, send a > request to the chairs with abstract, your I-D name, time needed and = why > you think the presentation is needed. >=20 > - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From rjsparks@nostrum.com Thu Mar 8 12:02:14 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A88021E8032 for ; Thu, 8 Mar 2012 12:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk2gFuJEcm60 for ; Thu, 8 Mar 2012 12:02:14 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2521E802B for ; Thu, 8 Mar 2012 12:02:13 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28K2DDJ020660 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 8 Mar 2012 14:02:13 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F591045.6010601@nostrum.com> Date: Thu, 08 Mar 2012 14:02:13 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Subject: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 20:02:14 -0000 Question: Is the DNS-based peer discovery mechanism mandatory to implement? The first paragraph of 5.2 speaks in terms of "supported" and if you read that to mean "implemented" the answer is no, but after talking to some folks I'm not sure that was the intent. Was the intent mandatory to implement, optional to use? That would ensure that an operator had the option to start using the DNS-based discovery mechanism when it was the right thing to do. RjS From rjsparks@nostrum.com Thu Mar 8 13:17:13 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02A121E805D; Thu, 8 Mar 2012 13:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnQ7d6TIN510; Thu, 8 Mar 2012 13:17:11 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4021E8063; Thu, 8 Mar 2012 13:17:08 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28LH5UM032502 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 15:17:06 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F5921D1.4030804@nostrum.com> Date: Thu, 08 Mar 2012 15:17:05 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Glen Zorn References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> In-Reply-To: <4F5820EC.5080907@net-zen.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 21:17:13 -0000 On 3/7/12 9:01 PM, Glen Zorn wrote: > On 3/8/2012 3:05 AM, Robert Sparks wrote: >> Thanks for the response Glen >> >> Discussion inline. >> > ... > >>>> This sentence in section 2.1 is not clear: >>>> For TLS [RFC5246] and DTLS [RFC4347], a Diameter >>>> node that initiate a connection prior to any message exchanges MUST >>>> run on port [TBD]. >>>> What was its intent? It could be misread to say that you cannot establish >>>> a connection on any other port than [TBD]. >>> I'm not sure that that would be a mis-reading. >> If that's the case, consider saying "run only on port". But doesn't that >> interact badly >> with the peer discovery mechanism? Or are you saying it would be an >> error to create >> an SRV record that pointed to any port other than TBD? > Actually, I'm just not sure (I didn't write this part ;-). I'm hoping > that somebody else will chime in... Who should be responding? I think the right thing to do here is to change the MUST above to "by default" and note that the SRV-based peer discovery mechanism may specify other ports. > > ... > >>>> In the new text on the Election Process, "lexicographically succeeds" needs >>>> additional description. >>> Not quite sure why: IIRC, the term was chosen because it precisely >>> states the desired operation and is well-understood (straight out of >>> Intro to CS, actually). >> Rereading this after several months, I think it's fine. My point was you >> need to specify >> the lexicon. You did (case-insensitive ASCII - so you know "A2"<"AA"). >> The way you >> point to Appendix D makes it seem that will affect ordering (it >> doesn't). Is there a place >> in the DNS specs you can point to that makes order comparisons explicit >> to remove >> all potential ambiguity? > Beats me; anybody? > >>>> The note at the end of 6.1 is very ambiguous - does "this section" mean >>>> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those >>>> subsections? Either way, it leaves the requirements language very hard >>>> to follow. Does this say certain implemenentations MAY ignore some MUSTs? >>>> If so, which ones? >>> Again, I'm having trouble seeing any ambiguity here: the word "this" >>> very specific and the phrase "this section", if present in a section, >>> seems only to denote that section, not any sections that might follow or >>> precede it. Maybe cut down on the caffeine? ;-) >> You didn't answer whether you believe 6.1.1 is part of, or follows, 6.1. > I think that 6.1.1 is not part of 6.1; the following subsection _do_ > contain RFC 2119 language, while 6.1 doesn't, so I would expect that the > broad outline of processing in 6.1 is descriptive while the following > subsections are prescriptive. And when I read it, I don't. This still looks like a loophole for people to avoid implementing what the spec should be requiring. With these two sentences: " Note the processing rules contained in this section are intended to be used as general guidelines to Diameter developers. Certain implementations MAY use different methods than the ones described here, and still comply with the protocol specification." and implementer could totally ignore the MUSTs in section 6.1.3: "6.1.3. Receiving Requests A relay or proxy agent MUST check for forwarding loops when receiving requests. A loop is detected if the server finds its own identity in a Route-Record AVP. When such an event occurs, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED." and still claim to comply with the protocol specification. Would the following work for you: "The overview contained in this section (6.1) are intended to be used as general guidelines to Diameter developers. Implementations are free to use different methods than the ones described here as long as they conform to the requirements in sections 6.1.1 through 6.1.9". > >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> In section 1.3.1's second paragraph, starting the second sentence with >>>> "Typically," is likely to introduce confusion about the allocation policy. >>> How can it introduce confusion about allocation policy _in this >>> document_ when the whole paragraph is just suggesting policies for >>> _other documents_? >>> >>>> Why is the word needed in this sentence? >>> Because it's not specifying a rule, it's just making a suggestion. >> I don't know what potential confusion I saw at the time. I'll remove the >> comment, >> but consider changing "should" to "would" in that suggestion. > OK. (just to make sure you left it on purpose - it's still should in 30). > >>>> In section 2, 2nd to last paragraph before section 2.1: This edit (moving >>>> how tranparency is described) resulted in a sentence that says Diameter Relays >>>> and redirect agents MUST support all Diameter applications. Please consider >>>> touching it again to make it clearer that those elements MUST be transparent >>>> to the applications, and as a result trivially support them. >>> It's hard to see the difference. >> A clarification would make it more obvious that "support" in this >> circumstance >> means simply "be transparent". Encourage the focus of the implementer >> towards >> being transparent to an abstract thing rather than making sure they >> "support" >> whatever the current list of defined applications is. > I think we may be talking about two different kinds of transparency. I > don't think that redirect agents, in particular, can actually be > transparent to the endpoint nodes (since they actually return a message > telling where to send the original message) ; Sure, but the redirect mechanics are general, not application specific. > relays can probably be > transparent, but they need to recognize, at least, any Diameter message > that comes to them so that it can be forwarded correctly. Fair enough. The end goal is to make sure redirect agents and relays don't necessarily have to be touched in order to deploy new applications. The behavior I'm hoping most to not encourage is a relay keeping a list of applications that it checks each message against before forwarding it. That said, I don't have text to propose, and you've done what I asked (which was to consider a clarification). I'm willing to let this go. > >>>> In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP, >>>> please consider pointing out that section 2.2 still requires _SOME_ security >>>> mechanism be used. >>> The reason why the initiator reverts is that the peer only supports RFC >>> 3588, which requires some security mechanism to be used. >> It would hurt to point that out? > Just seems like beating a dying (if not dead) horse ;-) Product managers look hard to find ways to push features off... > >>>> The edits to the first paragraph of the description of AVP flags left >>>> the sentence "Unrecognized bits SHOULD be considered an error." unsupported. >>>> It's not clear (without looking at the diff to 3588) what bits might >>>> possibly be unrecognized. >>> I think that this is correct: any unrecognized bit would have to be one >>> of the 'r' bits it seems& a sender MUST set all the r' bits to 0 so >>> this can never happen (with a conformant implementation. How about we >>> just remove that sentence? >> I think you still need it. >> >> Note that subsequent Diameter applications MAY define additional bits >> within the AVP Header, and an unrecognized bit SHOULD be considered an >> error. >> >> The 3588bis text says this now: >> New Diameter applications SHOULD NOT define >> additional AVP Flag bits. The sender of the AVP MUST set 'r' >> (reserved) bits to 0 and the receiver SHOULD ignore all 'r' >> (reserved) bits. Unrecognized bits SHOULD be considered an error. >> >> The new text still leaves the possibility for additional (unrecognized) >> AVP bits to show up, >> defined by new applications. >> >> Maybe just swap the last two sentences in the new text? > OK Thanks for making that change - as I noted while updating my ballot, I think the MAY that got added hurts a little. > > ... > >>>> The following is a pedantic nit, but please consider addressing it. >>>> In several places (both in text from 3588 and new text introduced as >>>> part of this effort), the text refers to the definitions of commands >>>> in the representational language defined in section 3.2 as ABNF. For >>>> example: >>>> The Grouped Data field has the following ABNF grammar: >>>> >>>> Proxy-Info ::=< AVP Header: 284> >>>> { Proxy-Host } >>>> { Proxy-State } >>>> * [ AVP ] >>>> >>>> That is not ABNF. Instead, it is a well formed message in a language described >>>> by the ABNF in section 3.2. It would be better to say something like >>>> "The Grouped data field has the following Command Code specification:". >>> This particular pedantic nit seems very popular amongst the IESG ;-). I >>> would like it very much if you folks could come to a consensus as to >>> whether it must be changed and, if so, how to change it. TIA! >> Well, I put this in as a comment, not a blocking point. >> >> I think changing it would make the document more correct, and the suggestion >> I make above would fix it and doesn't look too hard to implement. Am I >> missing something? > My point is that several IESG members have complained about this; I > don't mind fixing it, if necessary, but I only want to do it once. Just > BTW, as I recall RFC 3588 was gone over with a fine-tooth comb by > various ABNF geeks before it was published; since neither the definition > of ABNF nor the actual "ABNF" in 3588bis has changed since then I find > it rather amazing that it has somehow become defective. Well, let me see if I can pull the consensus you're looking for together quickly. As far as I can tell, nobody's blocking this - they're just noting it's had an error for all this time and now would be an easy time to fix it. The value returned for going through the pain will be making it less likely that some other spec developer copies the error. (And maybe avoiding going through this same conversation the next time this spec is revised). From jouni.nospam@gmail.com Thu Mar 8 13:20:30 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC6921E8042 for ; Thu, 8 Mar 2012 13:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q+EOi0rlv+P for ; Thu, 8 Mar 2012 13:20:29 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A53D321E8039 for ; Thu, 8 Mar 2012 13:20:28 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so676607wgb.13 for ; Thu, 08 Mar 2012 13:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8ROIF1NyAXE2S8lhy5QsuAvJgpRtRF95efpEcUlTdx0=; b=tsR5GEKOYJ6LW/WY8xHrSYwm/ypOeGfR9HGvoMzO4Ssiz8f4dSEvY9CCF4XVKTlEKH Qfln03LOS98nYumvOx2IWpiZ1SKYdrRUggnczcs2wPvprABdsuR13Gi+WcI9I2cInrYd jWMuQgFDmognciZnWnnku7R/TNxIWV67ekCRwVP/DJEgAyzNNHEMTgcHbQubGVa9KiPF fs/OYY0RTrK/6BJU4uhwBty6rMtofA5PbqUZ6wUVR9OPuGMc6l+yti5KGZneTK5gAMAJ rGClQPtd69jWWiLeJdCOLhEKSkzV36hnmIFVwycnZcKvkrAR0eK7Yo1ATZDcUicQK+pY GC7g== Received: by 10.180.95.197 with SMTP id dm5mr27658179wib.20.1331241627658; Thu, 08 Mar 2012 13:20:27 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id 9sm14265140wid.2.2012.03.08.13.20.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 13:20:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <4F591045.6010601@nostrum.com> Date: Thu, 8 Mar 2012 23:20:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <265BA881-7161-4F97-84CD-D486C7F998EB@gmail.com> References: <4F591045.6010601@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1257) Cc: "dime@ietf.org" Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 21:20:30 -0000 Robert, On Mar 8, 2012, at 10:02 PM, Robert Sparks wrote: > Question: Is the DNS-based peer discovery mechanism mandatory to = implement? No. >=20 > The first paragraph of 5.2 speaks in terms of "supported" and if you = read that to mean "implemented" the answer is no, but after talking to = some folks I'm not sure that was the intent. Was the intent mandatory to = implement, optional to use? That would ensure that an operator had the = option to start using the DNS-based discovery mechanism when it was the = right thing to do. Optional to implement and optional to use. - Jouni >=20 > RjS >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From rjsparks@nostrum.com Thu Mar 8 13:42:45 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969B821E8062; Thu, 8 Mar 2012 13:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yys64mNsvgbr; Thu, 8 Mar 2012 13:42:43 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57521E8036; Thu, 8 Mar 2012 13:42:43 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28LgfgY036359 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 15:42:41 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F5927D1.6020907@nostrum.com> Date: Thu, 08 Mar 2012 15:42:41 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Glen Zorn References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> In-Reply-To: <4F5921D1.4030804@nostrum.com> Content-Type: multipart/alternative; boundary="------------040009000902020100090401" Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG , dime-chairs@tools.ietf.org Subject: [Dime] Command Code syntax vs ABNF X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 21:42:45 -0000 This is a multi-part message in MIME format. --------------040009000902020100090401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit WG participants, and document reviewers: Several folks have pointed out that 3588 misused the term ABNF in a few places, and the misuse was inherited by 3588bis. The command code syntax itself is specified (correctly) using ABNF. Phrases like the section header for 3.2 "3.2 Command Code ABNF Specification" are correct. Sections that _use_ the command code grammar incorrectly call that ABNF. An example is section 4.4.1, where it says: The Grouped Data field has the following ABNF grammar: Example-AVP ::= < AVP Header: 999999 > { Origin-Host } 1*{ Session-Id } *[ AVP ] That isn't ABNF, it's an expression in the command code grammar defined by the ABNF in section 3.2. An ABNF parser would reject it if you provided it as input. A diameter command code syntax parser would accept it. This is a minor, pedantic, point, but several reviewers raised it (but none are asking to block the document on changing it). There's an opportunity to clean it up now. The benefit would be a slight increase in correctness, a decrease in the likelihood that someone would copy the mistake in a future specification, and avoiding another set of comments like this one should RFC-to-be-3588bis should ever be revised. Here's a concrete suggestion that I think is easy to implement and would satisfy all the review comments. Would anyone object to changing the places where ABNF is misused to variants of "command code specification"? For instance, the errant sentence in 4.4.1 would become "The Grouped Data field has the following command code specification". In section 6.6, "An ABNF for a request message" would be come "The command code specification for a request message". And so on. RjS On 3/8/12 3:17 PM, Robert Sparks wrote: > > > On 3/7/12 9:01 PM, Glen Zorn wrote: >> On 3/8/2012 3:05 AM, Robert Sparks wrote: >>> Thanks for the response Glen >>> >>> Discussion inline. >>> >> ... >> >>>>> This sentence in section 2.1 is not clear: >>>>> For TLS [RFC5246] and DTLS [RFC4347], a Diameter >>>>> node that initiate a connection prior to any message exchanges >>>>> MUST >>>>> run on port [TBD]. >>>>> What was its intent? It could be misread to say that you cannot >>>>> establish >>>>> a connection on any other port than [TBD]. >>>> I'm not sure that that would be a mis-reading. >>> If that's the case, consider saying "run only on port". But doesn't >>> that >>> interact badly >>> with the peer discovery mechanism? Or are you saying it would be an >>> error to create >>> an SRV record that pointed to any port other than TBD? >> Actually, I'm just not sure (I didn't write this part ;-). I'm hoping >> that somebody else will chime in... > Who should be responding? > > I think the right thing to do here is to change the MUST above to "by > default" and note that > the SRV-based peer discovery mechanism may specify other ports. >> >> ... >> >>>>> In the new text on the Election Process, "lexicographically >>>>> succeeds" needs >>>>> additional description. >>>> Not quite sure why: IIRC, the term was chosen because it precisely >>>> states the desired operation and is well-understood (straight out of >>>> Intro to CS, actually). >>> Rereading this after several months, I think it's fine. My point was >>> you >>> need to specify >>> the lexicon. You did (case-insensitive ASCII - so you know "A2"<"AA"). >>> The way you >>> point to Appendix D makes it seem that will affect ordering (it >>> doesn't). Is there a place >>> in the DNS specs you can point to that makes order comparisons explicit >>> to remove >>> all potential ambiguity? >> Beats me; anybody? >> >>>>> The note at the end of 6.1 is very ambiguous - does "this section" >>>>> mean >>>>> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include >>>>> those >>>>> subsections? Either way, it leaves the requirements language very >>>>> hard >>>>> to follow. Does this say certain implemenentations MAY ignore >>>>> some MUSTs? >>>>> If so, which ones? >>>> Again, I'm having trouble seeing any ambiguity here: the word "this" >>>> very specific and the phrase "this section", if present in a section, >>>> seems only to denote that section, not any sections that might >>>> follow or >>>> precede it. Maybe cut down on the caffeine? ;-) >>> You didn't answer whether you believe 6.1.1 is part of, or follows, >>> 6.1. >> I think that 6.1.1 is not part of 6.1; the following subsection _do_ >> contain RFC 2119 language, while 6.1 doesn't, so I would expect that the >> broad outline of processing in 6.1 is descriptive while the following >> subsections are prescriptive. > And when I read it, I don't. This still looks like a loophole for > people to avoid > implementing what the spec should be requiring. With these two sentences: > > " Note the processing rules contained in this section are intended to > be used as general guidelines to Diameter developers. Certain > implementations MAY use different methods than the ones described > here, and still comply with the protocol specification." > > and implementer could totally ignore the MUSTs in section 6.1.3: > > "6.1.3. Receiving Requests > > A relay or proxy agent MUST check for forwarding loops when receiving > requests. A loop is detected if the server finds its own identity in > a Route-Record AVP. When such an event occurs, the agent MUST answer > with the Result-Code AVP set to DIAMETER_LOOP_DETECTED." > > and still claim to comply with the protocol specification. > > Would the following work for you: > > "The overview contained in this section (6.1) are intended to be > used as general guidelines to Diameter developers. Implementations > are free to use different methods than the ones described here as long > as they conform to the requirements in sections 6.1.1 through 6.1.9". > > >> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> In section 1.3.1's second paragraph, starting the second sentence >>>>> with >>>>> "Typically," is likely to introduce confusion about the allocation >>>>> policy. >>>> How can it introduce confusion about allocation policy _in this >>>> document_ when the whole paragraph is just suggesting policies for >>>> _other documents_? >>>> >>>>> Why is the word needed in this sentence? >>>> Because it's not specifying a rule, it's just making a suggestion. >>> I don't know what potential confusion I saw at the time. I'll remove >>> the >>> comment, >>> but consider changing "should" to "would" in that suggestion. >> OK. > (just to make sure you left it on purpose - it's still should in 30). >> >>>>> In section 2, 2nd to last paragraph before section 2.1: This edit >>>>> (moving >>>>> how tranparency is described) resulted in a sentence that says >>>>> Diameter Relays >>>>> and redirect agents MUST support all Diameter applications. Please >>>>> consider >>>>> touching it again to make it clearer that those elements MUST be >>>>> transparent >>>>> to the applications, and as a result trivially support them. >>>> It's hard to see the difference. >>> A clarification would make it more obvious that "support" in this >>> circumstance >>> means simply "be transparent". Encourage the focus of the implementer >>> towards >>> being transparent to an abstract thing rather than making sure they >>> "support" >>> whatever the current list of defined applications is. >> I think we may be talking about two different kinds of transparency. I >> don't think that redirect agents, in particular, can actually be >> transparent to the endpoint nodes (since they actually return a message >> telling where to send the original message) ; > Sure, but the redirect mechanics are general, not application specific. >> relays can probably be >> transparent, but they need to recognize, at least, any Diameter message >> that comes to them so that it can be forwarded correctly. > Fair enough. The end goal is to make sure redirect agents and relays > don't > necessarily have to be touched in order to deploy new applications. The > behavior I'm hoping most to not encourage is a relay keeping a list > of applications > that it checks each message against before forwarding it. > > That said, I don't have text to propose, and you've done what I asked > (which was to consider > a clarification). I'm willing to let this go. > >> >>>>> In section 2.1, 3rd paragraph when discussing reverting to TCP or >>>>> SCTP, >>>>> please consider pointing out that section 2.2 still requires >>>>> _SOME_ security >>>>> mechanism be used. >>>> The reason why the initiator reverts is that the peer only supports >>>> RFC >>>> 3588, which requires some security mechanism to be used. >>> It would hurt to point that out? >> Just seems like beating a dying (if not dead) horse ;-) > Product managers look hard to find ways to push features off... >> >>>>> The edits to the first paragraph of the description of AVP flags left >>>>> the sentence "Unrecognized bits SHOULD be considered an error." >>>>> unsupported. >>>>> It's not clear (without looking at the diff to 3588) what bits might >>>>> possibly be unrecognized. >>>> I think that this is correct: any unrecognized bit would have to be >>>> one >>>> of the 'r' bits it seems& a sender MUST set all the r' bits to 0 so >>>> this can never happen (with a conformant implementation. How about we >>>> just remove that sentence? >>> I think you still need it. >>> >>> Note that subsequent Diameter applications MAY define additional bits >>> within the AVP Header, and an unrecognized bit SHOULD be considered an >>> error. >>> >>> The 3588bis text says this now: >>> New Diameter applications SHOULD NOT define >>> additional AVP Flag bits. The sender of the AVP MUST set 'r' >>> (reserved) bits to 0 and the receiver SHOULD ignore all 'r' >>> (reserved) bits. Unrecognized bits SHOULD be considered an >>> error. >>> >>> The new text still leaves the possibility for additional (unrecognized) >>> AVP bits to show up, >>> defined by new applications. >>> >>> Maybe just swap the last two sentences in the new text? >> OK > Thanks for making that change - as I noted while updating my ballot, I > think the MAY that got added hurts a little. >> >> ... >> >>>>> The following is a pedantic nit, but please consider addressing it. >>>>> In several places (both in text from 3588 and new text introduced as >>>>> part of this effort), the text refers to the definitions of commands >>>>> in the representational language defined in section 3.2 as ABNF. For >>>>> example: >>>>> The Grouped Data field has the following ABNF grammar: >>>>> >>>>> Proxy-Info ::=< AVP Header: 284> >>>>> { Proxy-Host } >>>>> { Proxy-State } >>>>> * [ AVP ] >>>>> >>>>> That is not ABNF. Instead, it is a well formed message in a >>>>> language described >>>>> by the ABNF in section 3.2. It would be better to say something like >>>>> "The Grouped data field has the following Command Code >>>>> specification:". >>>> This particular pedantic nit seems very popular amongst the IESG >>>> ;-). I >>>> would like it very much if you folks could come to a consensus as to >>>> whether it must be changed and, if so, how to change it. TIA! >>> Well, I put this in as a comment, not a blocking point. >>> >>> I think changing it would make the document more correct, and the >>> suggestion >>> I make above would fix it and doesn't look too hard to implement. Am I >>> missing something? >> My point is that several IESG members have complained about this; I >> don't mind fixing it, if necessary, but I only want to do it once. Just >> BTW, as I recall RFC 3588 was gone over with a fine-tooth comb by >> various ABNF geeks before it was published; since neither the definition >> of ABNF nor the actual "ABNF" in 3588bis has changed since then I find >> it rather amazing that it has somehow become defective. > Well, let me see if I can pull the consensus you're looking for > together quickly. > > As far as I can tell, nobody's blocking this - they're just noting > it's had an error for all this time and now > would be an easy time to fix it. The value returned for going through > the pain will be making it less likely > that some other spec developer copies the error. (And maybe avoiding > going through this same conversation > the next time this spec is revised). > --------------040009000902020100090401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit WG participants, and document reviewers:

Several folks have pointed out that 3588 misused the term ABNF in a few places, and the misuse was inherited by 3588bis.

The command code syntax itself is specified (correctly) using ABNF. Phrases like the section header for 3.2
"3.2 Command Code ABNF Specification"
are correct.

Sections that _use_ the command code grammar incorrectly call that ABNF. An example is section
4.4.1, where it says:

         The Grouped Data field has the following ABNF grammar:

         Example-AVP  ::= < AVP Header: 999999 >
                          { Origin-Host }
                        1*{ Session-Id }
                         *[ AVP ]

That isn't ABNF, it's an expression in the command code grammar defined by the ABNF in section 3.2.
An ABNF parser would reject it if you provided it as input. A diameter command code syntax parser would
accept it.

This is a minor, pedantic, point, but several reviewers raised it (but none are asking to block the document
on changing it). There's an opportunity to clean it up now. The benefit would be a slight increase in correctness,
a decrease in the likelihood that someone would copy the mistake in a future specification, and avoiding
another set of comments like this one should RFC-to-be-3588bis should ever be revised.

Here's a concrete suggestion that I think is easy to implement and would satisfy all the review comments.

Would anyone object to changing the places where ABNF is misused to variants of "command code specification"?
For instance, the errant sentence in 4.4.1 would become "The Grouped Data field has the following command code specification". In section 6.6, "An ABNF for a request message" would be come "The command code specification for a request message". And so on.

RjS

On 3/8/12 3:17 PM, Robert Sparks wrote:


On 3/7/12 9:01 PM, Glen Zorn wrote:
On 3/8/2012 3:05 AM, Robert Sparks wrote:
Thanks for the response Glen

Discussion inline.

...

This sentence in section 2.1 is not clear:
    For TLS [RFC5246] and DTLS [RFC4347], a Diameter
    node that initiate a connection prior to any message exchanges MUST
    run on port [TBD].
What was its intent? It could be misread to say that you cannot establish
a connection on any other port than [TBD].
I'm not sure that that would be a mis-reading.
If that's the case, consider saying "run only on port". But doesn't that
interact badly
with the peer discovery mechanism? Or are you saying it would be an
error to create
an SRV record that pointed to any port other than TBD?
Actually, I'm just not sure (I didn't write this part ;-).  I'm hoping
that somebody else will chime in...
Who should be responding?

I think the right thing to do here is to change the MUST above to "by default" and note that
the SRV-based peer discovery mechanism may specify other ports.

...

In the new text on the Election Process, "lexicographically succeeds" needs
additional description.
Not quite sure why: IIRC, the term was chosen because it precisely
states the desired operation and is well-understood (straight out of
Intro to CS, actually).
Rereading this after several months, I think it's fine. My point was you
need to specify
the lexicon. You did (case-insensitive ASCII - so you know "A2"<"AA").
The way you
point to Appendix D makes it seem that will affect ordering (it
doesn't). Is there a place
in the DNS specs you can point to that makes order comparisons explicit
to remove
all potential ambiguity?
Beats me; anybody?

The note at the end of 6.1 is very ambiguous - does "this section" mean
just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those
subsections?  Either way, it leaves the requirements language very hard
to follow.  Does this say certain implemenentations MAY ignore some MUSTs?
If so, which ones?
Again, I'm having trouble seeing any ambiguity here: the word "this"
very specific and the phrase "this section", if present in a section,
seems only to denote that section, not any sections that might follow or
precede it.  Maybe cut down on the caffeine? ;-)
You didn't answer whether you believe 6.1.1 is part of, or follows, 6.1.
I think that 6.1.1 is not part of 6.1; the following subsection _do_
contain RFC 2119 language, while 6.1 doesn't, so I would expect that the
broad outline of processing in 6.1 is descriptive while the following
subsections are prescriptive.
And when I read it, I don't. This still looks like a loophole for people to avoid
implementing what the spec should be requiring. With these two sentences:

"   Note the processing rules contained in this section are intended to
   be used as general guidelines to Diameter developers.  Certain
   implementations MAY use different methods than the ones described
   here, and still comply with the protocol specification."

and implementer could totally ignore the MUSTs in section 6.1.3:

"6.1.3.  Receiving Requests

   A relay or proxy agent MUST check for forwarding loops when receiving
   requests.  A loop is detected if the server finds its own identity in
   a Route-Record AVP.  When such an event occurs, the agent MUST answer
   with the Result-Code AVP set to DIAMETER_LOOP_DETECTED."

and still claim to comply with the protocol specification.

Would the following work for you:

"The overview contained in this section (6.1) are intended to be
used as general guidelines to Diameter developers. Implementations
are free to use different methods than the ones described here as long
as they conform to the requirements in sections 6.1.1 through 6.1.9".




----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In section 1.3.1's second paragraph, starting the second sentence with
"Typically," is likely to introduce confusion about the allocation policy.
How can it introduce confusion about allocation policy _in this
document_ when the whole paragraph is just suggesting policies for
_other documents_?

Why is the word needed in this sentence?
Because it's not specifying a rule, it's just making a suggestion.
I don't know what potential confusion I saw at the time. I'll remove the
comment,
but consider changing "should" to "would" in that suggestion.
OK.
(just to make sure you left it on purpose - it's still should in 30).

In section 2, 2nd to last paragraph before section 2.1: This edit (moving
how tranparency is described) resulted in a sentence that says Diameter Relays
and redirect agents MUST support all Diameter applications. Please consider
touching it again to make it clearer that those elements MUST be transparent
to the applications, and as a result trivially support them.
It's hard to see the difference.
A clarification would make it more obvious that "support" in this
circumstance
means simply "be transparent". Encourage the focus of the implementer
towards
being transparent to an abstract thing rather than making sure they
"support"
whatever the current list of defined applications is.
I think we may be talking about two different kinds of transparency.  I
don't think that redirect agents, in particular, can actually be
transparent to the endpoint nodes (since they actually return a message
telling where to send the original message) ;
Sure, but the redirect mechanics are general, not application specific.
  relays can probably be
transparent, but they need to recognize, at least, any Diameter message
that comes to them so that it can be forwarded correctly.
Fair enough. The end goal is to make sure redirect agents and relays don't
necessarily have to be touched in order to deploy new applications. The
behavior I'm hoping most  to not encourage is a relay keeping a list of applications
that it checks each message against before forwarding it.

That said, I don't have text to propose, and you've done what I asked (which was to consider
a clarification). I'm willing to let this go.


In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP,
please consider pointing out that section 2.2 still requires _SOME_ security
mechanism be used.
The reason why the initiator reverts is that the peer only supports RFC
3588, which requires some security mechanism to be used.
It would hurt to point that out?
Just seems like beating a dying (if not dead) horse ;-)
Product managers look hard to find ways to push features off...

The edits to the first paragraph of the description of AVP flags left
the sentence "Unrecognized bits SHOULD be considered an error." unsupported.
It's not clear (without looking at the diff to 3588) what bits might
possibly be unrecognized.
I think that this is correct: any unrecognized bit would have to be one
of the 'r' bits it seems&  a sender MUST set all the r' bits to 0 so
this can never happen (with a conformant implementation.  How about we
just remove that sentence?
I think you still need it.

Note that subsequent Diameter applications MAY define additional bits
within the AVP Header, and an unrecognized bit SHOULD be considered an
error.

The 3588bis text says this now:
New Diameter applications SHOULD NOT define
       additional AVP Flag bits.  The sender of the AVP MUST set 'r'
       (reserved) bits to 0 and the receiver SHOULD ignore all 'r'
       (reserved) bits.  Unrecognized bits SHOULD be considered an error.

The new text still leaves the possibility for additional (unrecognized)
AVP bits to show up,
defined by new applications.

Maybe just swap the last two sentences in the new text?
OK
Thanks for making that change - as I noted while updating my ballot, I think the MAY that got added hurts a little.

...

The following is a pedantic nit, but please consider addressing it.
In several places (both in text from 3588 and new text introduced as
part of this effort), the text refers to the definitions of commands
in the representational language defined in section 3.2 as ABNF. For
example:
    The Grouped Data field has the following ABNF grammar:

          Proxy-Info ::=<  AVP Header: 284>
                         { Proxy-Host }
                         { Proxy-State }
                       * [ AVP ]

That is not ABNF. Instead, it is a well formed message in a language described
by the ABNF in section 3.2. It would be better to say something like
"The Grouped data field has the following Command Code specification:".
This particular pedantic nit seems very popular amongst the IESG ;-).  I
would like it very much if you folks could come to a consensus as to
whether it must be changed and, if so, how to change it.  TIA!
Well, I put this in as a comment, not a blocking point.

I think changing it would make the document more correct, and the suggestion
I make above would fix it and doesn't look too hard to implement. Am I
missing something?
My point is that several IESG members have complained about this; I
don't mind fixing it, if necessary, but I only want to do it once.  Just
BTW, as I recall RFC 3588 was gone over with a fine-tooth comb by
various ABNF geeks before it was published; since neither the definition
of ABNF nor the actual "ABNF" in 3588bis has changed since then I find
it rather amazing that it has somehow become defective.
Well, let me see if I can pull the consensus you're looking for together quickly.

As far as I can tell, nobody's blocking this - they're just noting it's had an error for all this time and now
would be an easy time to fix it. The value returned for going through the pain will be making it less likely
that some other spec developer copies the error. (And maybe avoiding going through this same conversation
the next time this spec is revised).

--------------040009000902020100090401-- From rjsparks@nostrum.com Thu Mar 8 13:52:30 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1243021E801B for ; Thu, 8 Mar 2012 13:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHfQw2nk83YZ for ; Thu, 8 Mar 2012 13:52:28 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 931F021F8694 for ; Thu, 8 Mar 2012 13:52:23 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28LqL5e037877 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 15:52:22 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F592A15.9050409@nostrum.com> Date: Thu, 08 Mar 2012 15:52:21 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jouni References: <4F591045.6010601@nostrum.com> <265BA881-7161-4F97-84CD-D486C7F998EB@gmail.com> In-Reply-To: <265BA881-7161-4F97-84CD-D486C7F998EB@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 21:52:33 -0000 On 3/8/12 3:20 PM, Jouni wrote: > Robert, > > On Mar 8, 2012, at 10:02 PM, Robert Sparks wrote: > >> Question: Is the DNS-based peer discovery mechanism mandatory to implement? > No. > >> The first paragraph of 5.2 speaks in terms of "supported" and if you read that to mean "implemented" the answer is no, but after talking to some folks I'm not sure that was the intent. Was the intent mandatory to implement, optional to use? That would ensure that an operator had the option to start using the DNS-based discovery mechanism when it was the right thing to do. > Optional to implement and optional to use. Is there a thread you can point to where the WG discussed this? > > - Jouni > > >> RjS >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Mar 8 14:26:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870CB21F85B1; Thu, 8 Mar 2012 14:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv5wdExlQxZe; Thu, 8 Mar 2012 14:26:53 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED9A621F855F; Thu, 8 Mar 2012 14:26:52 -0800 (PST) Received: by werb10 with SMTP id b10so867141wer.31 for ; Thu, 08 Mar 2012 14:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=LO8AEhgMlo7Ii2/NPvBhp7n85SjmwHo3ymAa1K3KXdw=; b=bHEqiVgXnf8Ixq4Pm/cugwe9myLTk3OLNaJ6HdGN9RDy42C6FcA6lsavY1BP5pwFQM JKoKpsMifRpK2DtyP83VXBNABr6VsFVW63MgfGcZUHN+rcCMY5tPTVmyZte4ZV9siQE7 hOdmW4JweleG30/X5vDtacu/FhS+qihpD4RaERiNM0Nmbh1sOkYvG31CV25XKZ714peV Htog+odG1KiN54b3AjAy7qY8d/N8xkhNRBemirxnd34Tv05evKYTHQD1HWZt9o9gcGqS cy5XSEIEd8k43cpmIU3+AHlZ1pD0k2lXRUHKk1XuhKFvQI1AwDATCYHqiEuJp6NWuUwU 3sJg== Received: by 10.180.92.229 with SMTP id cp5mr16509819wib.8.1331245611929; Thu, 08 Mar 2012 14:26:51 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id be4sm14974773wib.8.2012.03.08.14.26.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 14:26:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <4F5921D1.4030804@nostrum.com> Date: Fri, 9 Mar 2012 00:26:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1257) Cc: dime-chairs@tools.ietf.org, draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , Glen Zorn , The IESG Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 22:26:54 -0000 Robert, On Mar 8, 2012, at 11:17 PM, Robert Sparks wrote: >=20 >=20 > On 3/7/12 9:01 PM, Glen Zorn wrote: >> On 3/8/2012 3:05 AM, Robert Sparks wrote: >>> Thanks for the response Glen >>>=20 >>> Discussion inline. >>>=20 >> ... >>=20 >>>>> This sentence in section 2.1 is not clear: >>>>> For TLS [RFC5246] and DTLS [RFC4347], a Diameter >>>>> node that initiate a connection prior to any message exchanges = MUST >>>>> run on port [TBD]. >>>>> What was its intent? It could be misread to say that you cannot = establish >>>>> a connection on any other port than [TBD]. >>>> I'm not sure that that would be a mis-reading. >>> If that's the case, consider saying "run only on port". But doesn't = that >>> interact badly >>> with the peer discovery mechanism? Or are you saying it would be an >>> error to create >>> an SRV record that pointed to any port other than TBD? >> Actually, I'm just not sure (I didn't write this part ;-). I'm = hoping >> that somebody else will chime in... > Who should be responding? >=20 > I think the right thing to do here is to change the MUST above to "by = default" and note that > the SRV-based peer discovery mechanism may specify other ports. It actually looks fuzzy.. "run on port" intends to say that a Diameter = node must at least bind its listening socket to port [TBD]. When creating a = connection the source port can be other than [TBD] but should be the same [TBD].. The wording does not actually allow listening for incoming connections = on other ports that 3868 and [TBD], which effectively puts a restriction on the use of SRV. >> ... >>=20 >>>>> In the new text on the Election Process, "lexicographically = succeeds" needs >>>>> additional description. >>>> Not quite sure why: IIRC, the term was chosen because it precisely >>>> states the desired operation and is well-understood (straight out = of >>>> Intro to CS, actually). >>> Rereading this after several months, I think it's fine. My point was = you >>> need to specify >>> the lexicon. You did (case-insensitive ASCII - so you know = "A2"<"AA"). >>> The way you >>> point to Appendix D makes it seem that will affect ordering (it >>> doesn't). Is there a place >>> in the DNS specs you can point to that makes order comparisons = explicit >>> to remove >>> all potential ambiguity? >> Beats me; anybody? Not me. >>=20 >>>>> The note at the end of 6.1 is very ambiguous - does "this section" = mean >>>>> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include = those >>>>> subsections? Either way, it leaves the requirements language very = hard >>>>> to follow. Does this say certain implemenentations MAY ignore = some MUSTs? >>>>> If so, which ones? >>>> Again, I'm having trouble seeing any ambiguity here: the word = "this" >>>> very specific and the phrase "this section", if present in a = section, >>>> seems only to denote that section, not any sections that might = follow or >>>> precede it. Maybe cut down on the caffeine? ;-) >>> You didn't answer whether you believe 6.1.1 is part of, or follows, = 6.1. >> I think that 6.1.1 is not part of 6.1; the following subsection _do_ >> contain RFC 2119 language, while 6.1 doesn't, so I would expect that = the >> broad outline of processing in 6.1 is descriptive while the following >> subsections are prescriptive. > And when I read it, I don't. This still looks like a loophole for = people to avoid > implementing what the spec should be requiring. With these two = sentences: >=20 > " Note the processing rules contained in this section are intended = to > be used as general guidelines to Diameter developers. Certain > implementations MAY use different methods than the ones described > here, and still comply with the protocol specification." >=20 > and implementer could totally ignore the MUSTs in section 6.1.3: >=20 > "6.1.3. Receiving Requests >=20 > A relay or proxy agent MUST check for forwarding loops when = receiving > requests. A loop is detected if the server finds its own identity = in > a Route-Record AVP. When such an event occurs, the agent MUST = answer > with the Result-Code AVP set to DIAMETER_LOOP_DETECTED." >=20 > and still claim to comply with the protocol specification. >=20 > Would the following work for you: >=20 > "The overview contained in this section (6.1) are intended to be > used as general guidelines to Diameter developers. Implementations > are free to use different methods than the ones described here as long > as they conform to the requirements in sections 6.1.1 through 6.1.9". Would work for me. [snip] - Jouni= From jouni.nospam@gmail.com Thu Mar 8 14:51:57 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA0121F865B for ; Thu, 8 Mar 2012 14:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H9W-wS91eDa for ; Thu, 8 Mar 2012 14:51:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC221F8659 for ; Thu, 8 Mar 2012 14:51:47 -0800 (PST) Received: by werb10 with SMTP id b10so886334wer.31 for ; Thu, 08 Mar 2012 14:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=LJ6rp758YwuDxidoym1nOLopu/mXQECegPrRDJBNJ+Q=; b=B//c4qjiItlbVc73AhQCWxYB5+S6yya+acUcAi2XrPjRWe8SmWvqAnPyYjd7F0T85c fYhc8CN+RFYvtJxKpCKh5Kf7cltmfPuTFCiCFbnBKywY9sd4cr8t9AllLjLgywBh2Rp3 zFCKolvzPumGCOdcKCbKDw1gH0EFQA6dFguJH7/xpFFjThYtVxHR6fWfB5mF+OSTOje+ 2LoRVnYfzlB0IQCzN+G2myLd9aIqpI0icJrREsQ852DkzinBF+J98h62CRE94Bxb2DG4 DTsAuPvvLVrfSegSOfEhni2LhDhDbTGWe3uV3zDf574/PuIgHKZ1CKvP1P49O1lG84h4 zKIw== Received: by 10.216.139.229 with SMTP id c79mr5178471wej.16.1331247106403; Thu, 08 Mar 2012 14:51:46 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id p10sm1047276wic.0.2012.03.08.14.51.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 14:51:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <4F592A15.9050409@nostrum.com> Date: Fri, 9 Mar 2012 00:51:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F591045.6010601@nostrum.com> <265BA881-7161-4F97-84CD-D486C7F998EB@gmail.com> <4F592A15.9050409@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1257) Cc: "dime@ietf.org" Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 22:51:57 -0000 Robert, On Mar 8, 2012, at 11:52 PM, Robert Sparks wrote: >=20 >=20 > On 3/8/12 3:20 PM, Jouni wrote: >> Robert, >>=20 >> On Mar 8, 2012, at 10:02 PM, Robert Sparks wrote: >>=20 >>> Question: Is the DNS-based peer discovery mechanism mandatory to = implement? >> No. >>=20 >>> The first paragraph of 5.2 speaks in terms of "supported" and if you = read that to mean "implemented" the answer is no, but after talking to = some folks I'm not sure that was the intent. Was the intent mandatory to = implement, optional to use? That would ensure that an operator had the = option to start using the DNS-based discovery mechanism when it was the = right thing to do. >> Optional to implement and optional to use. > Is there a thread you can point to where the WG discussed this? Hmm.. I don't recall any with any analysis or such. It has been asked few times though. Optional to implement & use has been my interpretation since all time. Maybe Glen remembers discussions from the early days. - Jouni >=20 >>=20 >> - Jouni >>=20 >>=20 >>> RjS >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Thu Mar 8 16:56:09 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D67A21F85B6 for ; Thu, 8 Mar 2012 16:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItRyOQ-EwDXd for ; Thu, 8 Mar 2012 16:56:08 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4989F21F85B1 for ; Thu, 8 Mar 2012 16:56:08 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7BFA1074003; Fri, 9 Mar 2012 01:57:17 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id DF1081074001; Fri, 9 Mar 2012 01:57:17 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 01:56:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 01:56:06 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Is DNS-based diameter peer discovery mandatory toimplement? Thread-Index: Acz9fidzenx0cqU7S7ylIUHJv3Q3FwAD2lkg References: <4F591045.6010601@nostrum.com><265BA881-7161-4F97-84CD-D486C7F998EB@gmail.com><4F592A15.9050409@nostrum.com> From: To: , X-OriginalArrivalTime: 09 Mar 2012 00:56:07.0444 (UTC) FILETIME=[6939AD40:01CCFD8F] Cc: dime@ietf.org Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 00:56:09 -0000 Hi Robert, Sorry but I failed to understand how=20 =20 "The first option (manual configuration) MUST be supported by all = Diameter nodes, while the latter option (DNS) MAY be supported." can be interpreted as "DNS option is mandatory to implement and optional = to use". For me, the meaning of this sentence is clear, if not crystal clear: the = DNS-based mechanism was optional to implement (supported) and therefore = optional to use too. Regards, Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Jouni Envoy=E9=A0: jeudi 8 mars 2012 23:52 =C0=A0: Robert Sparks Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Is DNS-based diameter peer discovery mandatory = toimplement? Robert, On Mar 8, 2012, at 11:52 PM, Robert Sparks wrote: >=20 >=20 > On 3/8/12 3:20 PM, Jouni wrote: >> Robert, >>=20 >> On Mar 8, 2012, at 10:02 PM, Robert Sparks wrote: >>=20 >>> Question: Is the DNS-based peer discovery mechanism mandatory to = implement? >> No. >>=20 >>> The first paragraph of 5.2 speaks in terms of "supported" and if you = read that to mean "implemented" the answer is no, but after talking to = some folks I'm not sure that was the intent. Was the intent mandatory to = implement, optional to use? That would ensure that an operator had the = option to start using the DNS-based discovery mechanism when it was the = right thing to do. >> Optional to implement and optional to use. > Is there a thread you can point to where the WG discussed this? Hmm.. I don't recall any with any analysis or such. It has been asked few times though. Optional to implement & use has been my interpretation since all time. Maybe Glen remembers discussions from the early days. - Jouni >=20 >>=20 >> - Jouni >>=20 >>=20 >>> RjS >>>=20 >>> _______________________________________________ >>> 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 rjsparks@nostrum.com Thu Mar 8 17:14:18 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D521C21F8468 for ; Thu, 8 Mar 2012 17:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a04mCzvJTrvU for ; Thu, 8 Mar 2012 17:14:18 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 599B011E8072 for ; Thu, 8 Mar 2012 17:14:15 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q291ED6d068488 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 19:14:13 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F595965.1020704@nostrum.com> Date: Thu, 08 Mar 2012 19:14:13 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: lionel.morand@orange.com References: <4F591045.6010601@nostrum.com><265BA881-7161-4F97-84CD-D486C7F998EB@gmail.com><4F592A15.9050409@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 01:14:19 -0000 On 3/8/12 6:56 PM, lionel.morand@orange.com wrote: > Hi Robert, > > Sorry but I failed to understand how > > "The first option (manual configuration) MUST be supported by all Diameter nodes, while the latter option (DNS) MAY be supported." > > can be interpreted as "DNS option is mandatory to implement and optional to use". Reread my question - I'm not suggesting it does. I'm asking if what's written reflects what the working group decision was, and for a pointer into that working group discussion. > > For me, the meaning of this sentence is clear, if not crystal clear: the DNS-based mechanism was optional to implement (supported) and therefore optional to use too. > > Regards, > > Lionel > > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Jouni > Envoyé : jeudi 8 mars 2012 23:52 > À : Robert Sparks > Cc : dime@ietf.org > Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement? > > Robert, > > On Mar 8, 2012, at 11:52 PM, Robert Sparks wrote: > >> >> On 3/8/12 3:20 PM, Jouni wrote: >>> Robert, >>> >>> On Mar 8, 2012, at 10:02 PM, Robert Sparks wrote: >>> >>>> Question: Is the DNS-based peer discovery mechanism mandatory to implement? >>> No. >>> >>>> The first paragraph of 5.2 speaks in terms of "supported" and if you read that to mean "implemented" the answer is no, but after talking to some folks I'm not sure that was the intent. Was the intent mandatory to implement, optional to use? That would ensure that an operator had the option to start using the DNS-based discovery mechanism when it was the right thing to do. >>> Optional to implement and optional to use. >> Is there a thread you can point to where the WG discussed this? > Hmm.. I don't recall any with any analysis or such. It has been > asked few times though. Optional to implement& use has been my > interpretation since all time. > > Maybe Glen remembers discussions from the early days. > > > - Jouni > > >>> - Jouni >>> >>> >>>> RjS >>>> >>>> _______________________________________________ >>>> 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 glenzorn@gmail.com Thu Mar 8 19:01:18 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D8011E8080 for ; Thu, 8 Mar 2012 19:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=-1.610, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFtiIQ1rRXgi for ; Thu, 8 Mar 2012 19:01:17 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0211E8075 for ; Thu, 8 Mar 2012 19:01:06 -0800 (PST) Received: by ggmi1 with SMTP id i1so734397ggm.31 for ; Thu, 08 Mar 2012 19:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Rht29C2ov60P7v/Cb6Z/tU3RJ+dv2DBQlEGVxaGYnOQ=; b=Lf5wSdkbgVax7dinvTay6o/h/WEvLyHc9RWYGKnjiWOnAcPIQ9BZSD+PQYAL/elD2Y M2kvsuYZm32JyINNsCJbhbkuu+rxmCHpsyqfm/bf9jGX9AgHXe2FMynuI94zUxrDDi7h XlRtv9O9LOUiKc8UI/0JMpJ7/ad52m7BaV6a4uKQkHOQmWafKQZAYp+IouMtHR9IeIL2 tBseKejPDpWvMoGfg5SltdZm/PgBmiqqNHavYJKpLZvlMWpPJQhfg3J7p7+/8N1YknpP e95BJ9wAMwwWM04twNRrQ4yIhqM3hVG6ZLlXK7uwN9zeIk4hPP5WCnWu2nx0H8PNxmYH heZg== Received: by 10.236.144.133 with SMTP id n5mr569277yhj.54.1331262066124; Thu, 08 Mar 2012 19:01:06 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-7-18.revip2.asianet.co.th. [124.120.7.18]) by mx.google.com with ESMTPS id 32sm6775737anu.14.2012.03.08.19.01.03 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 19:01:04 -0800 (PST) Message-ID: <4F59726D.5070106@gmail.com> Date: Fri, 09 Mar 2012 10:01:01 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Sparks References: <4F591045.6010601@nostrum.com> In-Reply-To: <4F591045.6010601@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 03:01:18 -0000 On 3/9/2012 3:02 AM, Robert Sparks wrote: > Question: Is the DNS-based peer discovery mechanism mandatory to implement? > > The first paragraph of 5.2 speaks in terms of "supported" and if you > read that to mean "implemented" the answer is no, but after talking to > some folks I'm not sure that was the intent. Was the intent mandatory to > implement, optional to use? Good question. The text in question uses the term "Diameter node", which is a computer actually running Diameter, so my take on it would be that the node might not support the option (in terms of actually using it)but that the option would nevertheless be available (i.e., implemented). It seems like the text could be clearer though -- any suggestions? > That would ensure that an operator had the > option to start using the DNS-based discovery mechanism when it was the > right thing to do. > > RjS > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Thu Mar 8 20:15:37 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E66D21E804B for ; Thu, 8 Mar 2012 20:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.801 X-Spam-Level: X-Spam-Status: No, score=-99.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeXeYiG0zSDU for ; Thu, 8 Mar 2012 20:15:36 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by ietfa.amsl.com (Postfix) with SMTP id 711D621F853B for ; Thu, 8 Mar 2012 20:15:36 -0800 (PST) Received: (qmail 29284 invoked from network); 9 Mar 2012 04:15:35 -0000 Received: from unknown (124.120.7.18) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 09 Mar 2012 04:15:34 -0000 Message-ID: <4F5983E0.6010400@net-zen.net> Date: Fri, 09 Mar 2012 11:15:28 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Sparks References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> In-Reply-To: <4F5921D1.4030804@nostrum.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/mixed; boundary="------------020103030408020905050605" Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 04:15:37 -0000 This is a multi-part message in MIME format. --------------020103030408020905050605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/9/2012 4:17 AM, Robert Sparks wrote: > On 3/7/12 9:01 PM, Glen Zorn wrote: >> On 3/8/2012 3:05 AM, Robert Sparks wrote: >>> Thanks for the response Glen >>> >>> Discussion inline. >>> >> ... >> >>>>> This sentence in section 2.1 is not clear: >>>>> For TLS [RFC5246] and DTLS [RFC4347], a Diameter >>>>> node that initiate a connection prior to any message exchanges >>>>> MUST >>>>> run on port [TBD]. >>>>> What was its intent? It could be misread to say that you cannot >>>>> establish >>>>> a connection on any other port than [TBD]. >>>> I'm not sure that that would be a mis-reading. >>> If that's the case, consider saying "run only on port". But doesn't that >>> interact badly >>> with the peer discovery mechanism? Or are you saying it would be an >>> error to create >>> an SRV record that pointed to any port other than TBD? >> Actually, I'm just not sure (I didn't write this part ;-). I'm hoping >> that somebody else will chime in... > Who should be responding? > > I think the right thing to do here is to change the MUST above to "by > default" and note that > the SRV-based peer discovery mechanism may specify other ports. I'm gonna let the Chairs respond to this. ... >>>>> The note at the end of 6.1 is very ambiguous - does "this section" >>>>> mean >>>>> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those >>>>> subsections? Either way, it leaves the requirements language very >>>>> hard >>>>> to follow. Does this say certain implemenentations MAY ignore some >>>>> MUSTs? >>>>> If so, which ones? >>>> Again, I'm having trouble seeing any ambiguity here: the word "this" >>>> very specific and the phrase "this section", if present in a section, >>>> seems only to denote that section, not any sections that might >>>> follow or >>>> precede it. Maybe cut down on the caffeine? ;-) >>> You didn't answer whether you believe 6.1.1 is part of, or follows, 6.1. >> I think that 6.1.1 is not part of 6.1; the following subsection _do_ >> contain RFC 2119 language, while 6.1 doesn't, so I would expect that the >> broad outline of processing in 6.1 is descriptive while the following >> subsections are prescriptive. > And when I read it, I don't. This still looks like a loophole for people > to avoid > implementing what the spec should be requiring. With these two sentences: > > " Note the processing rules contained in this section are intended to > be used as general guidelines to Diameter developers. Certain > implementations MAY use different methods than the ones described > here, and still comply with the protocol specification." > > and implementer could totally ignore the MUSTs in section 6.1.3: Implementers can (and do!) do anything they want ;-) > > "6.1.3. Receiving Requests > > A relay or proxy agent MUST check for forwarding loops when receiving > requests. A loop is detected if the server finds its own identity in > a Route-Record AVP. When such an event occurs, the agent MUST answer > with the Result-Code AVP set to DIAMETER_LOOP_DETECTED." > > and still claim to comply with the protocol specification. > > Would the following work for you: > > "The overview contained in this section (6.1) are intended to be > used as general guidelines to Diameter developers. Implementations > are free to use different methods than the ones described here as long > as they conform to the requirements in sections 6.1.1 through 6.1.9". OK w/me. > > >> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> In section 1.3.1's second paragraph, starting the second sentence with >>>>> "Typically," is likely to introduce confusion about the allocation >>>>> policy. >>>> How can it introduce confusion about allocation policy _in this >>>> document_ when the whole paragraph is just suggesting policies for >>>> _other documents_? >>>> >>>>> Why is the word needed in this sentence? >>>> Because it's not specifying a rule, it's just making a suggestion. >>> I don't know what potential confusion I saw at the time. I'll remove the >>> comment, >>> but consider changing "should" to "would" in that suggestion. >> OK. > (just to make sure you left it on purpose - it's still should in 30). Whoops! Thank you. >> >>>>> In section 2, 2nd to last paragraph before section 2.1: This edit >>>>> (moving >>>>> how tranparency is described) resulted in a sentence that says >>>>> Diameter Relays >>>>> and redirect agents MUST support all Diameter applications. Please >>>>> consider >>>>> touching it again to make it clearer that those elements MUST be >>>>> transparent >>>>> to the applications, and as a result trivially support them. >>>> It's hard to see the difference. >>> A clarification would make it more obvious that "support" in this >>> circumstance >>> means simply "be transparent". Encourage the focus of the implementer >>> towards >>> being transparent to an abstract thing rather than making sure they >>> "support" >>> whatever the current list of defined applications is. >> I think we may be talking about two different kinds of transparency. I >> don't think that redirect agents, in particular, can actually be >> transparent to the endpoint nodes (since they actually return a message >> telling where to send the original message) ; > Sure, but the redirect mechanics are general, not application specific. >> relays can probably be >> transparent, but they need to recognize, at least, any Diameter message >> that comes to them so that it can be forwarded correctly. > Fair enough. The end goal is to make sure redirect agents and relays don't > necessarily have to be touched in order to deploy new applications. The > behavior I'm hoping most to not encourage is a relay keeping a list of > applications > that it checks each message against before forwarding it. Because Diameter messages are outed by app ID & realm, I'm not sure how that can be avoided. > > That said, I don't have text to propose, and you've done what I asked > (which was to consider > a clarification). I'm willing to let this go. OK, thanks. > >> >>>>> In section 2.1, 3rd paragraph when discussing reverting to TCP or >>>>> SCTP, >>>>> please consider pointing out that section 2.2 still requires _SOME_ >>>>> security >>>>> mechanism be used. >>>> The reason why the initiator reverts is that the peer only supports RFC >>>> 3588, which requires some security mechanism to be used. >>> It would hurt to point that out? >> Just seems like beating a dying (if not dead) horse ;-) > Product managers look hard to find ways to push features off... One problem is that Diameter security requirements have been roundly ignored by the community in favor of plugging their ears and going "lalala" really loud ;-). I don't see how changing this will change that. In any case, -31 says that "The Diameter protocol MUST NOT be used without one of TLS, DTLS or IPsec." and this is repeated in the Security Considerations section; note that it doesn't say anything version-specific. >> >>>>> The edits to the first paragraph of the description of AVP flags left >>>>> the sentence "Unrecognized bits SHOULD be considered an error." >>>>> unsupported. >>>>> It's not clear (without looking at the diff to 3588) what bits might >>>>> possibly be unrecognized. >>>> I think that this is correct: any unrecognized bit would have to be one >>>> of the 'r' bits it seems& a sender MUST set all the r' bits to 0 so >>>> this can never happen (with a conformant implementation. How about we >>>> just remove that sentence? >>> I think you still need it. >>> >>> Note that subsequent Diameter applications MAY define additional bits >>> within the AVP Header, and an unrecognized bit SHOULD be considered an >>> error. >>> >>> The 3588bis text says this now: >>> New Diameter applications SHOULD NOT define >>> additional AVP Flag bits. The sender of the AVP MUST set 'r' >>> (reserved) bits to 0 and the receiver SHOULD ignore all 'r' >>> (reserved) bits. Unrecognized bits SHOULD be considered an >>> error. >>> >>> The new text still leaves the possibility for additional (unrecognized) >>> AVP bits to show up, >>> defined by new applications. >>> >>> Maybe just swap the last two sentences in the new text? >> OK > Thanks for making that change - as I noted while updating my ballot, I > think the MAY that got added hurts a little. I would be inclined to make the "MAY" into a "may" or a "might", as in Note however, that new Diameter applications might define additional bits within the AVP Header; an unrecognized bit SHOULD be considered an error. >> >> ... >> >>>>> The following is a pedantic nit, but please consider addressing it. >>>>> In several places (both in text from 3588 and new text introduced as >>>>> part of this effort), the text refers to the definitions of commands >>>>> in the representational language defined in section 3.2 as ABNF. For >>>>> example: >>>>> The Grouped Data field has the following ABNF grammar: >>>>> >>>>> Proxy-Info ::=< AVP Header: 284> >>>>> { Proxy-Host } >>>>> { Proxy-State } >>>>> * [ AVP ] >>>>> >>>>> That is not ABNF. Instead, it is a well formed message in a >>>>> language described >>>>> by the ABNF in section 3.2. It would be better to say something like >>>>> "The Grouped data field has the following Command Code >>>>> specification:". >>>> This particular pedantic nit seems very popular amongst the IESG >>>> ;-). I >>>> would like it very much if you folks could come to a consensus as to >>>> whether it must be changed and, if so, how to change it. TIA! >>> Well, I put this in as a comment, not a blocking point. >>> >>> I think changing it would make the document more correct, and the >>> suggestion >>> I make above would fix it and doesn't look too hard to implement. Am I >>> missing something? >> My point is that several IESG members have complained about this; I >> don't mind fixing it, if necessary, but I only want to do it once. Just >> BTW, as I recall RFC 3588 was gone over with a fine-tooth comb by >> various ABNF geeks before it was published; since neither the definition >> of ABNF nor the actual "ABNF" in 3588bis has changed since then I find >> it rather amazing that it has somehow become defective. > Well, let me see if I can pull the consensus you're looking for together > quickly. Thanks! > > As far as I can tell, nobody's blocking this - they're just noting it's > had an error for all this time and now > would be an easy time to fix it. The value returned for going through > the pain will be making it less likely > that some other spec developer copies the error. (And maybe avoiding > going through this same conversation > the next time this spec is revised). > > > --------------020103030408020905050605 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gwz.vcf" YmVnaW46dmNhcmQNCmZuOkdsZW4gWm9ybg0Kbjpab3JuO0dsZW4NCm9yZzpOZXR3b3JrIFpl bg0KYWRyOjs7O1NlYXR0bGU7V0E7O1VTQQ0KZW1haWw7aW50ZXJuZXQ6Z3d6QG5ldC16ZW4u bmV0DQp0ZWw7Y2VsbDorNjYgODcgMDQwIDQ2MTcNCm5vdGU6UEdQIEtleSBGaW5nZXJwcmlu dDogREFEMyBGNUQzIEFDRTYgNDE5NSA5QzVDICAyRUUxIDZFMTcgQjVGNiA1OTUzIEI0NUYg DQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------020103030408020905050605-- From gwz@net-zen.net Thu Mar 8 21:11:21 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2C21F8666 for ; Thu, 8 Mar 2012 21:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.801 X-Spam-Level: X-Spam-Status: No, score=-99.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTb5ewsGjIxF for ; Thu, 8 Mar 2012 21:11:20 -0800 (PST) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by ietfa.amsl.com (Postfix) with SMTP id BA0FA21F8663 for ; Thu, 8 Mar 2012 21:11:20 -0800 (PST) Received: (qmail 17568 invoked from network); 9 Mar 2012 05:11:19 -0000 Received: from unknown (124.120.7.18) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 09 Mar 2012 05:11:19 -0000 Message-ID: <4F5990F2.1080807@net-zen.net> Date: Fri, 09 Mar 2012 12:11:14 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jouni References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/mixed; boundary="------------090005000308060406090903" Cc: dime-chairs@tools.ietf.org, draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 05:11:21 -0000 This is a multi-part message in MIME format. --------------090005000308060406090903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/9/2012 5:26 AM, Jouni wrote: > > Robert, > > On Mar 8, 2012, at 11:17 PM, Robert Sparks wrote: > >> >> >> On 3/7/12 9:01 PM, Glen Zorn wrote: >>> On 3/8/2012 3:05 AM, Robert Sparks wrote: >>>> Thanks for the response Glen >>>> >>>> Discussion inline. >>>> >>> ... >>> >>>>>> This sentence in section 2.1 is not clear: >>>>>> For TLS [RFC5246] and DTLS [RFC4347], a Diameter >>>>>> node that initiate a connection prior to any message exchanges MUST >>>>>> run on port [TBD]. >>>>>> What was its intent? It could be misread to say that you cannot establish >>>>>> a connection on any other port than [TBD]. >>>>> I'm not sure that that would be a mis-reading. >>>> If that's the case, consider saying "run only on port". But doesn't that >>>> interact badly >>>> with the peer discovery mechanism? Or are you saying it would be an >>>> error to create >>>> an SRV record that pointed to any port other than TBD? >>> Actually, I'm just not sure (I didn't write this part ;-). I'm hoping >>> that somebody else will chime in... >> Who should be responding? >> >> I think the right thing to do here is to change the MUST above to "by default" and note that >> the SRV-based peer discovery mechanism may specify other ports. > > It actually looks fuzzy.. "run on port" intends to say that a Diameter node > must at least bind its listening socket to port [TBD]. When creating a connection > the source port can be other than [TBD] but should be the same [TBD].. > > The wording does not actually allow listening for incoming connections on > other ports that 3868 and [TBD], which effectively puts a restriction on > the use of SRV. OK, so how to change it? ... >>> >>>>>> The note at the end of 6.1 is very ambiguous - does "this section" mean >>>>>> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those >>>>>> subsections? Either way, it leaves the requirements language very hard >>>>>> to follow. Does this say certain implemenentations MAY ignore some MUSTs? >>>>>> If so, which ones? >>>>> Again, I'm having trouble seeing any ambiguity here: the word "this" >>>>> very specific and the phrase "this section", if present in a section, >>>>> seems only to denote that section, not any sections that might follow or >>>>> precede it. Maybe cut down on the caffeine? ;-) >>>> You didn't answer whether you believe 6.1.1 is part of, or follows, 6.1. >>> I think that 6.1.1 is not part of 6.1; the following subsection _do_ >>> contain RFC 2119 language, while 6.1 doesn't, so I would expect that the >>> broad outline of processing in 6.1 is descriptive while the following >>> subsections are prescriptive. >> And when I read it, I don't. This still looks like a loophole for people to avoid >> implementing what the spec should be requiring. With these two sentences: >> >> " Note the processing rules contained in this section are intended to >> be used as general guidelines to Diameter developers. Certain >> implementations MAY use different methods than the ones described >> here, and still comply with the protocol specification." >> >> and implementer could totally ignore the MUSTs in section 6.1.3: >> >> "6.1.3. Receiving Requests >> >> A relay or proxy agent MUST check for forwarding loops when receiving >> requests. A loop is detected if the server finds its own identity in >> a Route-Record AVP. When such an event occurs, the agent MUST answer >> with the Result-Code AVP set to DIAMETER_LOOP_DETECTED." >> >> and still claim to comply with the protocol specification. >> >> Would the following work for you: >> >> "The overview contained in this section (6.1) are intended to be >> used as general guidelines to Diameter developers. Implementations >> are free to use different methods than the ones described here as long >> as they conform to the requirements in sections 6.1.1 through 6.1.9". > > Would work for me. OK, this is what I have now: The overview contained in this section (6.1) is intended to provide general guidelines to Diameter developers. Implementations are free to use different methods than the ones described here as long as they conform to the requirements specified in Sections 6.1.1 through 6.1.9. See Section 7 for more detail on error handling. ... --------------090005000308060406090903 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------090005000308060406090903-- From glenzorn@gmail.com Thu Mar 8 23:19:23 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EF421F863C; Thu, 8 Mar 2012 23:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-1.246, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ7bftN9uLeY; Thu, 8 Mar 2012 23:19:21 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A16521F855F; Thu, 8 Mar 2012 23:19:21 -0800 (PST) Received: by ggmi1 with SMTP id i1so788239ggm.31 for ; Thu, 08 Mar 2012 23:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ICktLbNPAg8vjCQA9Te/m/zCABiryAtyqRZhjqyr7EA=; b=Uo/BUam86hEMNIZTNlUgjj8tFPHoGDSWTaAGaJ9cujGJlOuYh7jkNfQh11FOk+6MVy WusTNA58RcG7NKS7AfJsB2Zs9w1CDAf823ExLHwtiUENmGB3CLIWYNr77tPTAeRGOxPO jtQYTiyiXAvPjo5rUpEHTA4n+pjHCGkpbqYPNV0lgaI8ZRbxlgCUOGI8hwgD93LfCPgj QrFklGUhkPq1k1FeS7TpEpMOBry/z1/RY/7/zcGC1WH9OIE1fBjDJkLH65fCUjs5SEVR KfIOaNnRu6jIGihmK628TzkB54J8tH+QGhyptjsZoy4GmILlij5A7EHQmqhaE1qx3M5p vEnA== Received: by 10.236.185.42 with SMTP id t30mr1049418yhm.105.1331277561176; Thu, 08 Mar 2012 23:19:21 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-7-18.revip2.asianet.co.th. [124.120.7.18]) by mx.google.com with ESMTPS id n10sm7769459ani.8.2012.03.08.23.19.16 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 23:19:20 -0800 (PST) Message-ID: <4F59AEF2.8040008@gmail.com> Date: Fri, 09 Mar 2012 14:19:14 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Sparks References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> <4F5927D1.6020907@nostrum.com> In-Reply-To: <4F5927D1.6020907@nostrum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Glen Zorn , "dime@ietf.org" , The IESG Subject: Re: [Dime] Command Code syntax vs ABNF X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 07:19:23 -0000 On 3/9/2012 4:42 AM, Robert Sparks wrote: > WG participants, and document reviewers: > > Several folks have pointed out that 3588 misused the term ABNF in a few > places, and the misuse was inherited by 3588bis. > > The command code syntax itself is specified (correctly) using ABNF. > Phrases like the section header for 3.2 > "3.2 Command Code ABNF Specification" > are correct. > > Sections that _use_ the command code grammar incorrectly call that ABNF. > An example is section > 4.4.1, where it says: > > The Grouped Data field has the following ABNF grammar: > > Example-AVP ::= < AVP Header: 999999 > > { Origin-Host } > 1*{ Session-Id } > *[ AVP ] > > That isn't ABNF, it's an expression in the command code grammar defined > by the ABNF in section 3.2. > An ABNF parser would reject it if you provided it as input. A diameter > command code syntax parser would > accept it. > > This is a minor, pedantic, point, but several reviewers raised it (but > none are asking to block the document > on changing it). There's an opportunity to clean it up now. The benefit > would be a slight increase in correctness, > a decrease in the likelihood that someone would copy the mistake in a > future specification, and avoiding > another set of comments like this one should RFC-to-be-3588bis should > ever be revised. > > Here's a concrete suggestion that I think is easy to implement and would > satisfy all the review comments. > > Would anyone object to changing the places where ABNF is misused to > variants of "command code specification"? I would: there are at least 50 of those places in the draft and each would require individualized wordsmithing. If it really needs to be changed, I would prefer to have an acronym with which I could just globally replace "ABNF", saving hours of work. > For instance, the errant sentence in 4.4.1 would become "The Grouped > Data field has the following command code specification". In section > 6.6, "An ABNF for a request message" would be come "The command code > specification for a request message". And so on. > > RjS ... From jouni.nospam@gmail.com Fri Mar 9 00:17:37 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2DB21F8638 for ; Fri, 9 Mar 2012 00:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNEvSZCUwyF4 for ; Fri, 9 Mar 2012 00:17:36 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABDCC21F8629 for ; Fri, 9 Mar 2012 00:17:26 -0800 (PST) Received: by lagj5 with SMTP id j5so1626584lag.31 for ; Fri, 09 Mar 2012 00:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eSdYbZO6FSjNZn8TXPYup+xkp04vD1AkW1iFKawVJX8=; b=tmqBz2TSiSbIBQebK7tyEM2Rl1s3m3/XSRwrvEI+r7t6jq5WaRLsw/bI2lILQqKIyB EvaNIZFVURvMWdohbVj+G1QX7BbrNyux3amWqT0eabNqy7+GTW0Se4sSgsiUqOS17aAt RQdEf6dsUEr0PWt6sII5/QbiWwAgeTi0oLj41c/1156Wi8+Yg+Abd5ZrWNpW8f8eoVnP tsYSpYhE2P22GT6f7q4twOFA7qyH6OcEmPphyDGOb6r9ru2A3kG/0k8WVm0qx1Siu6J1 NHJn9MSkteUkTcX+Ggv9NeFFZ3aYpnIoOys+o/L7w2Z4ni3+UvF1KHUydJYLAr/cnhvT qKzg== Received: by 10.152.105.241 with SMTP id gp17mr1036595lab.21.1331281045604; Fri, 09 Mar 2012 00:17:25 -0800 (PST) Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id v4sm5555189lbx.13.2012.03.09.00.17.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 00:17:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F59726D.5070106@gmail.com> Date: Fri, 9 Mar 2012 10:17:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com> To: Robert Sparks , Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 08:17:37 -0000 Hi, On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote: > On 3/9/2012 3:02 AM, Robert Sparks wrote: >> Question: Is the DNS-based peer discovery mechanism mandatory to = implement? >>=20 >> The first paragraph of 5.2 speaks in terms of "supported" and if you >> read that to mean "implemented" the answer is no, but after talking = to >> some folks I'm not sure that was the intent. Was the intent mandatory = to >> implement, optional to use?=20 >=20 > Good question. The text in question uses the term "Diameter node", > which is a computer actually running Diameter, so my take on it would = be > that the node might not support the option (in terms of actually using > it)but that the option would nevertheless be available (i.e., > implemented). It seems like the text could be clearer though -- any > suggestions? How about: .. discovery, the following mechanisms are described. These are based on existing IETF standards. The first option (manual configuration) MUST be implemented and supported by all Diameter nodes, while the latter option (DNS) MAY be implemented and MAY be supported by Diameter nodes. However, we could also try to make DNS option more widely used, since every box in practice has to have some level of DNS resolver capability: .. MUST be implemented and supported by all Diameter nodes, while the latter option (DNS) SHOULD be implemented and if implemented MAY be used by Diameter nodes. Opinions? - Jouni >=20 >> That would ensure that an operator had the >> option to start using the DNS-based discovery mechanism when it was = the >> right thing to do. >>=20 >> RjS >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Fri Mar 9 00:27:52 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC85B21F8669 for ; Fri, 9 Mar 2012 00:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-1.498, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFZ90oFTyoni for ; Fri, 9 Mar 2012 00:27:52 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6079E21F8668 for ; Fri, 9 Mar 2012 00:27:52 -0800 (PST) Received: by obbta4 with SMTP id ta4so2052942obb.31 for ; Fri, 09 Mar 2012 00:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3gw3qajGVxTYFV3bA6NzJqxDHoEyRxs+wLCiyA58CY8=; b=C6qDNzxtMIDcKDMwSCEhsJLZRncoCEcN2FEjS0dnOOWfSD4uchfINS5pR4UGNle0xD s0BVW3YzcCNhzFLEOzZMyvy1mDzwzvoZo9ndrZWeZrX0MArTdRvG+SasZd2xjO7JjLVT RaooAFfD2nAe5wEyoFg672VNBziJh6epnmC+Ym7vVE/5hU1HlLVZQyyzAKnJAIuqN+tz zz9BnHAmfHZpsfp1ZhYMAeVIIwbSyxIcAosg0DL8pxMLYPHSJrtEK5UTFozRBxvoZ+CL vE9xKm+HF9NQJicZW6pDZlbMAQ7XE+PDyNVgXRLmeG9NUsp3r5HgpLYkzSvuo1mvK6OZ IrPQ== Received: by 10.182.231.38 with SMTP id td6mr521601obc.47.1331281671801; Fri, 09 Mar 2012 00:27:51 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-7-18.revip2.asianet.co.th. [124.120.7.18]) by mx.google.com with ESMTPS id x6sm2406625oex.12.2012.03.09.00.27.48 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 00:27:50 -0800 (PST) Message-ID: <4F59BF02.7060405@gmail.com> Date: Fri, 09 Mar 2012 15:27:46 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: jouni korhonen References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com> <19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> In-Reply-To: <19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 08:27:53 -0000 On 3/9/2012 3:17 PM, jouni korhonen wrote: > > Hi, > > On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote: > >> On 3/9/2012 3:02 AM, Robert Sparks wrote: >>> Question: Is the DNS-based peer discovery mechanism mandatory to implement? >>> >>> The first paragraph of 5.2 speaks in terms of "supported" and if you >>> read that to mean "implemented" the answer is no, but after talking to >>> some folks I'm not sure that was the intent. Was the intent mandatory to >>> implement, optional to use? >> >> Good question. The text in question uses the term "Diameter node", >> which is a computer actually running Diameter, so my take on it would be >> that the node might not support the option (in terms of actually using >> it)but that the option would nevertheless be available (i.e., >> implemented). It seems like the text could be clearer though -- any >> suggestions? > > How about: > > .. > discovery, the following mechanisms are described. These are based > on existing IETF standards. The first option (manual configuration) > MUST be implemented and supported by all Diameter nodes, while the > latter option (DNS) MAY be implemented and MAY be supported by > Diameter nodes. > > However, we could also try to make DNS option more widely used, since > every box in practice has to have some level of DNS resolver capability: > > .. > MUST be implemented and supported by all Diameter nodes, while the > latter option (DNS) SHOULD be implemented and if implemented MAY be > used by Diameter nodes. > > > Opinions? As I mentioned, I had always thought that it was a requirement of an implementation, just that you don't have support it in a deployment due to the use of the term "node". > > > - Jouni > > > >> >>> That would ensure that an operator had the >>> option to start using the DNS-based discovery mechanism when it was the >>> right thing to do. >>> >>> RjS >>> >>> _______________________________________________ >>> 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 glenzorn@gmail.com Fri Mar 9 00:34:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A6C21F85CC; Fri, 9 Mar 2012 00:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBGIhvu67Qgt; Fri, 9 Mar 2012 00:34:14 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE5C721F85C9; Fri, 9 Mar 2012 00:34:12 -0800 (PST) Received: by obbta4 with SMTP id ta4so2061279obb.31 for ; Fri, 09 Mar 2012 00:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=whPprKvySPJu83Ftc/cJ4Cg1eJtYS/K2Ud/3hYYOIHs=; b=Qth/7u/w+nI8fQS0AbD1/b3jknPWGEJyPxHuqD/RnQMng80NLiBYYQTp1U2abPxmzO lL4tYuMLAP/yCPRKntWRm/vqZM4Pa4q10DW1qWsrSnabZuWSc/8b7dzRSSeLhdwT+VGd FxFcMd+9gG1wHGRroGUTedTW7gYKuJfxiqKPTLK5WJg3Eg3SmPohDTmm/wIYaZuQ+al+ ml+lCEvNxlwXR99BD6soCnXOjLrBe8OrhO2hc7gZJ1AE8W/igJgHq4vDDBGCLAcWRG+4 SgosWwqlJP7IO0f7IEQ75p2vw6MhMPRcXN9E/0BLVmBZIHGiESR1iWMmLT168r40Ht31 fjlw== Received: by 10.60.12.231 with SMTP id b7mr540840oec.38.1331282052297; Fri, 09 Mar 2012 00:34:12 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-7-18.revip2.asianet.co.th. [124.120.7.18]) by mx.google.com with ESMTPS id yv3sm6478346obb.3.2012.03.09.00.34.08 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 00:34:11 -0800 (PST) Message-ID: <4F59C07E.2090009@gmail.com> Date: Fri, 09 Mar 2012 15:34:06 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F58D4E9.2070905@stpeter.im> In-Reply-To: <4F58D4E9.2070905@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jouni Korhonen , draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 08:34:15 -0000 On 3/8/2012 10:48 PM, Peter Saint-Andre wrote: > On 3/8/12 8:27 AM, Jouni Korhonen wrote: >> Peter, >> >> The text in recently submitted -30 Section 5.2 ( >> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-30#section-5.2) should >> also address your DISCUSS. > > Thanks for the pointer to a specific section. > > That change does address my primary concern, which was: > > RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV > Service of 'diameter'. 3588bis seems to add two more Proto values: > 'tls' and 'dtls'. However, RFC 6335, which defines updated rules > for the ports and services registry, allows only TCP, UDP, SCTP, > and DCCP as transport protocols. > > My secondary concern was this: > > Furthermore, this specification does not register the 'diameter' > SRV Service value in accordance with RFC 6335. Because these values > were not defined or registered by draft-ietf-dime-extended-naptr, I > think they need to be defined here. > > Please see Section 8.1 of RFC 6335 for the registration procedure: > > http://tools.ietf.org/html/rfc6335#section-8.1 > > I think you can add this quite easily in a revised I-D before the > deadline on Monday, or your AD can add an RFC Editor note. OK, what to do about the port number, etc.? Jouni, since you volunteered that we would do this, how about writing the section? > > Thanks! > > Peter > From jouni.nospam@gmail.com Fri Mar 9 00:35:24 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2721F85CC; Fri, 9 Mar 2012 00:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqxx36zVNvqI; Fri, 9 Mar 2012 00:35:24 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D53F121F85C9; Fri, 9 Mar 2012 00:35:23 -0800 (PST) Received: by lagj5 with SMTP id j5so1642897lag.31 for ; Fri, 09 Mar 2012 00:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mQVvkzOzVEE8lz0KKUGcOdZhDsfizubfaV+abCsXICg=; b=RSiI8ns/hPtSHOLlwQF3SgDtxEEIrd3nu8pdzHeERfDfqaOyLmUPmXa+bXpVAdUzdG hI3rXeBiL/Syl+iLC/rM7kV/RUgwg26g5Izi48A/lvcTkIKdfIDabh1sgPhnG+i6ucXz k1y0LR0ur9IKb40q1qCur8F8pB4a63gQkSoDX1Y8xV6KrV0JJ+I6OuiesetW7pEVvoau FyXbcjQpj1RWWZmbTqzW4NjbfzgH/kjCvRnD8qHwcQ/8aPygCh7JHOdVNmPMDrYrUEiV l4hNd/otet1csho02SgZOTGWs+1HrDvrsFSsMe0+I35WKlqbTZDsE/DJ+/JedGpRRm83 NRCw== Received: by 10.152.135.104 with SMTP id pr8mr952893lab.27.1331282122873; Fri, 09 Mar 2012 00:35:22 -0800 (PST) Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id c10sm5614423lbh.11.2012.03.09.00.35.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 00:35:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F59C07E.2090009@gmail.com> Date: Fri, 9 Mar 2012 10:35:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> References: <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Jouni Korhonen , "dime@ietf.org" , The IESG , Peter Saint-Andre Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 08:35:25 -0000 On Mar 9, 2012, at 10:34 AM, Glen Zorn wrote: > On 3/8/2012 10:48 PM, Peter Saint-Andre wrote: >> On 3/8/12 8:27 AM, Jouni Korhonen wrote: >>> Peter, >>>=20 >>> The text in recently submitted -30 Section 5.2 ( >>> = http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-30#section-5.2) = should >>> also address your DISCUSS. >>=20 >> Thanks for the pointer to a specific section. >>=20 >> That change does address my primary concern, which was: >>=20 >> RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV >> Service of 'diameter'. 3588bis seems to add two more Proto values: >> 'tls' and 'dtls'. However, RFC 6335, which defines updated rules >> for the ports and services registry, allows only TCP, UDP, SCTP, >> and DCCP as transport protocols. >>=20 >> My secondary concern was this: >>=20 >> Furthermore, this specification does not register the 'diameter' >> SRV Service value in accordance with RFC 6335. Because these values >> were not defined or registered by draft-ietf-dime-extended-naptr, I >> think they need to be defined here. >>=20 >> Please see Section 8.1 of RFC 6335 for the registration procedure: >>=20 >> http://tools.ietf.org/html/rfc6335#section-8.1 >>=20 >> I think you can add this quite easily in a revised I-D before the >> deadline on Monday, or your AD can add an RFC Editor note. >=20 > OK, what to do about the port number, etc.? Jouni, since you > volunteered that we would do this, how about writing the section? That's ok. - Jouni >=20 >>=20 >> Thanks! >>=20 >> Peter >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Mar 9 00:40:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA1521F85E6 for ; Fri, 9 Mar 2012 00:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfHrDhQEZt9D for ; Fri, 9 Mar 2012 00:40:50 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8CB21F85E5 for ; Fri, 9 Mar 2012 00:40:49 -0800 (PST) Received: by lbol12 with SMTP id l12so307446lbo.31 for ; Fri, 09 Mar 2012 00:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5qUG/2R3OPhOHtIOFVBYCx3gNITzUpcrZqakDwCM2gg=; b=H1y9Z5LbdYmsV1Evmza1vn3mg6fZc2XnYI2NxbKv9PQXwfITUWYlCoSf75Hj59tuX1 wgTulWvClxONcT1XDeJAkTCO+eE85rGDxoZSSEDy/Oe3x4DJlnNLdJMihQcn5uJZs3qY RKipuMkfgKHNVDtlCqBRTn0aONnDoadzgV9f+FbLgLUFcaqSTu5gwSuui87HhUOViVOA fvTZ0uzopaoFR1c+8Xo9Wdn6L4ICWuyVVCoxEsSFwPQ/qnlk30tcZ6ZEUoM5DsInzpyc Hl8kXbCnoatrf6v2ejdKQaI/IZVilz6HZMXsKlZokCnQzBlBp4JklsYyJ/iKwolZinHD /WEw== Received: by 10.152.132.104 with SMTP id ot8mr1005390lab.17.1331282448920; Fri, 09 Mar 2012 00:40:48 -0800 (PST) Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id jh4sm4008867lab.17.2012.03.09.00.40.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 00:40:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F59BF02.7060405@gmail.com> Date: Fri, 9 Mar 2012 10:40:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com> <19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> <4F59BF02.7060405@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 08:40:51 -0000 Glen, On Mar 9, 2012, at 10:27 AM, Glen Zorn wrote: > On 3/9/2012 3:17 PM, jouni korhonen wrote: >>=20 >> Hi, >>=20 >> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote: >>=20 >>> On 3/9/2012 3:02 AM, Robert Sparks wrote: >>>> Question: Is the DNS-based peer discovery mechanism mandatory to = implement? >>>>=20 >>>> The first paragraph of 5.2 speaks in terms of "supported" and if = you >>>> read that to mean "implemented" the answer is no, but after talking = to >>>> some folks I'm not sure that was the intent. Was the intent = mandatory to >>>> implement, optional to use?=20 >>>=20 >>> Good question. The text in question uses the term "Diameter node", >>> which is a computer actually running Diameter, so my take on it = would be >>> that the node might not support the option (in terms of actually = using >>> it)but that the option would nevertheless be available (i.e., >>> implemented). It seems like the text could be clearer though -- any >>> suggestions? >>=20 >> How about: >>=20 >> .. >> discovery, the following mechanisms are described. These are based >> on existing IETF standards. The first option (manual = configuration) >> MUST be implemented and supported by all Diameter nodes, while the >> latter option (DNS) MAY be implemented and MAY be supported by >> Diameter nodes. >>=20 >> However, we could also try to make DNS option more widely used, since >> every box in practice has to have some level of DNS resolver = capability: >>=20 >> .. >> MUST be implemented and supported by all Diameter nodes, while the >> latter option (DNS) SHOULD be implemented and if implemented MAY be >> used by Diameter nodes. >>=20 >>=20 >> Opinions? >=20 > As I mentioned, I had always thought that it was a requirement of an > implementation, just that you don't have support it in a deployment = due > to the use of the term "node". My interpretation has always been not mandatory/required to implement. What the others think? If folks think it has always been required we need to make the wording explicit. If there are others (apart from me and Lionel) who read it as not required to implement, I guess SHOULD is the strongest we can have here. - Jouni >=20 >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=20 >>>> That would ensure that an operator had the >>>> option to start using the DNS-based discovery mechanism when it was = the >>>> right thing to do. >>>>=20 >>>> RjS >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From kprasad@sandvine.com Fri Mar 9 00:46:28 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F128E21F85EE for ; Fri, 9 Mar 2012 00:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ehq8TgNnxNB for ; Fri, 9 Mar 2012 00:46:27 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4A53A21F85ED for ; Fri, 9 Mar 2012 00:46:27 -0800 (PST) Received: from blr-exch-1.sandvine.com (10.30.4.60) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 9 Mar 2012 03:46:26 -0500 Received: from BLR-EXCH-1.sandvine.com ([fe80::b896:bd62:3a8d:e51d]) by blr-exch-1.sandvine.com ([fe80::b896:bd62:3a8d:e51d%16]) with mapi id 14.01.0289.001; Fri, 9 Mar 2012 14:16:24 +0530 From: Krishna Prasad To: jouni korhonen , Glen Zorn Thread-Topic: [Dime] Is DNS-based diameter peer discovery mandatory to implement? Thread-Index: AQHM/aDrCTcyKAf0xkirV4fpmcN2h5ZhQqUAgAAC6ACAAAOiAIAAXLrQ Date: Fri, 9 Mar 2012 08:46:23 +0000 Message-ID: References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com> <19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> <4F59BF02.7060405@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.10.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 08:46:28 -0000 -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of jou= ni korhonen Sent: Friday, March 09, 2012 2:11 PM To: Glen Zorn Cc: dime@ietf.org Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to imple= ment? Glen, On Mar 9, 2012, at 10:27 AM, Glen Zorn wrote: > On 3/9/2012 3:17 PM, jouni korhonen wrote: >>=20 >> Hi, >>=20 >> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote: >>=20 >>> On 3/9/2012 3:02 AM, Robert Sparks wrote: >>>> Question: Is the DNS-based peer discovery mechanism mandatory to imple= ment? >>>>=20 >>>> The first paragraph of 5.2 speaks in terms of "supported" and if you >>>> read that to mean "implemented" the answer is no, but after talking to >>>> some folks I'm not sure that was the intent. Was the intent mandatory = to >>>> implement, optional to use?=20 >>>=20 >>> Good question. The text in question uses the term "Diameter node", >>> which is a computer actually running Diameter, so my take on it would b= e >>> that the node might not support the option (in terms of actually using >>> it)but that the option would nevertheless be available (i.e., >>> implemented). It seems like the text could be clearer though -- any >>> suggestions? >>=20 >> How about: >>=20 >> .. >> discovery, the following mechanisms are described. These are based >> on existing IETF standards. The first option (manual configuration) >> MUST be implemented and supported by all Diameter nodes, while the >> latter option (DNS) MAY be implemented and MAY be supported by >> Diameter nodes. >>=20 >> However, we could also try to make DNS option more widely used, since >> every box in practice has to have some level of DNS resolver capability: >>=20 >> .. >> MUST be implemented and supported by all Diameter nodes, while the >> latter option (DNS) SHOULD be implemented and if implemented MAY be >> used by Diameter nodes. >>=20 >>=20 >> Opinions? >=20 > As I mentioned, I had always thought that it was a requirement of an > implementation, just that you don't have support it in a deployment due > to the use of the term "node". My interpretation has always been not mandatory/required to implement. What the others think? If folks think it has always been required we need to make the wording explicit. If there are others (apart from me and Lionel) who read it as not required to implement, I guess SHOULD is the strongest we can have here. - Jouni I agree with Joni & Lionel, I never interpreted this as mandatory/required = and always thought it is optional.=20 -Prasad >=20 >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=20 >>>> That would ensure that an operator had the >>>> option to start using the DNS-based discovery mechanism when it was th= e >>>> right thing to do. >>>>=20 >>>> RjS >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Mar 9 00:49:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D610721F85FF; Fri, 9 Mar 2012 00:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayLLV8Jce80B; Fri, 9 Mar 2012 00:49:59 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9970B21F85FB; Fri, 9 Mar 2012 00:49:57 -0800 (PST) Received: by lbol12 with SMTP id l12so309401lbo.31 for ; Fri, 09 Mar 2012 00:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tmeK1lCGsVxIJMTfIl4UwgsagUyuUKvvbdJgyAVutd8=; b=lXGz7y0TUrIWmNlNZGwsuWkgXBZiiK7ZduXF4nagdn25IMX28PRQEVnbjjykOY0FAK cIsU41cQdQlJoKUVjHzDQFN5yNGC56HALYJEzm42hJWG0APXzypB69Qdt/AnnQha4ibo HOi+ghQD8wqSI8ctdlBfWnU+xRv5mZp0/LDAazRWbioa3SUQtLgr7I9jEbMY1aJ3e6eT 7Ywi9P3vYLy4nUYJb9viBOzsHjpftjsVnZQuLc6iVHzMhZ/54Lh4IZUI4YSOkmhNnpTy yjB4gLinXlwxijDlP8xw5MPhApnIKrIByJU20sjE0xrXZmk5hM7jwhaZr7vUTQwauMqx JmAg== Received: by 10.152.128.163 with SMTP id np3mr958650lab.51.1331282996500; Fri, 09 Mar 2012 00:49:56 -0800 (PST) Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id v4sm5646349lbx.13.2012.03.09.00.49.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 00:49:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F5990F2.1080807@net-zen.net> Date: Fri, 9 Mar 2012 10:49:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> <4F5990F2.1080807@net-zen.net> To: Glen Zorn , Robert Sparks X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 08:50:00 -0000 Glen, Robert, WG, On Mar 9, 2012, at 7:11 AM, Glen Zorn wrote: > On 3/9/2012 5:26 AM, Jouni wrote: >>=20 >> Robert, >>=20 >> On Mar 8, 2012, at 11:17 PM, Robert Sparks wrote: >>=20 >>>=20 >>>=20 >>> On 3/7/12 9:01 PM, Glen Zorn wrote: >>>> On 3/8/2012 3:05 AM, Robert Sparks wrote: >>>>> Thanks for the response Glen >>>>>=20 >>>>> Discussion inline. >>>>>=20 >>>> ... >>>>=20 >>>>>>> This sentence in section 2.1 is not clear: >>>>>>> For TLS [RFC5246] and DTLS [RFC4347], a Diameter >>>>>>> node that initiate a connection prior to any message exchanges = MUST >>>>>>> run on port [TBD]. >>>>>>> What was its intent? It could be misread to say that you cannot = establish >>>>>>> a connection on any other port than [TBD]. >>>>>> I'm not sure that that would be a mis-reading. >>>>> If that's the case, consider saying "run only on port". But = doesn't that >>>>> interact badly >>>>> with the peer discovery mechanism? Or are you saying it would be = an >>>>> error to create >>>>> an SRV record that pointed to any port other than TBD? >>>> Actually, I'm just not sure (I didn't write this part ;-). I'm = hoping >>>> that somebody else will chime in... >>> Who should be responding? >>>=20 >>> I think the right thing to do here is to change the MUST above to = "by default" and note that >>> the SRV-based peer discovery mechanism may specify other ports. >>=20 >> It actually looks fuzzy.. "run on port" intends to say that a = Diameter node >> must at least bind its listening socket to port [TBD]. When creating = a connection >> the source port can be other than [TBD] but should be the same = [TBD].. >>=20 >> The wording does not actually allow listening for incoming = connections on >> other ports that 3868 and [TBD], which effectively puts a restriction = on >> the use of SRV. >=20 > OK, so how to change it? I looked back to old archives back to early 2000 and there John Loughney said that NAPTR was introduced to allow flexibility on TLS ports i.e. = not only rely on fixed port numbers. So we probably then should make it = clear a DNS based peer discovery can override default ports. How about: ... The base Diameter protocol is run (i.e., listens for incoming = connections) on port 3868 for both TCP [RFC793] and SCTP [RFC4960]. It is assumed = that TLS [RFC5246] is run on top of TCP when it is used and DTLS [RFC6347] = is run on top of SCTP when it is used. If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP connections on port [TBD], i.e. the peer complies only with [RFC3588], then the initiator MAY revert to using TCP or SCTP and on port 3868. Note that this scheme is kept for the purpose of backwards compatibility only and that there are inherent security vulnerabilities when the initial CER/CEA messages are sent un- protected (see Section 5.6). Diameter clients MUST support either TCP or SCTP, while agents and servers SHOULD support both. A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and MUST always be prepared to receive connections on port 3868 for TCP = or SCTP and port [TBD] for TLS/TCP and DTLS/SCTP connections. When = DNS-based peer discovery is used, the port numbers received from SRV records take precedence over default ports 3868 and [TBD]. Comments? - Jouni >=20 > ... >=20 >>>>=20 >>>>>>> The note at the end of 6.1 is very ambiguous - does "this = section" mean >>>>>>> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include = those >>>>>>> subsections? Either way, it leaves the requirements language = very hard >>>>>>> to follow. Does this say certain implemenentations MAY ignore = some MUSTs? >>>>>>> If so, which ones? >>>>>> Again, I'm having trouble seeing any ambiguity here: the word = "this" >>>>>> very specific and the phrase "this section", if present in a = section, >>>>>> seems only to denote that section, not any sections that might = follow or >>>>>> precede it. Maybe cut down on the caffeine? ;-) >>>>> You didn't answer whether you believe 6.1.1 is part of, or = follows, 6.1. >>>> I think that 6.1.1 is not part of 6.1; the following subsection = _do_ >>>> contain RFC 2119 language, while 6.1 doesn't, so I would expect = that the >>>> broad outline of processing in 6.1 is descriptive while the = following >>>> subsections are prescriptive. >>> And when I read it, I don't. This still looks like a loophole for = people to avoid >>> implementing what the spec should be requiring. With these two = sentences: >>>=20 >>> " Note the processing rules contained in this section are intended = to >>> be used as general guidelines to Diameter developers. Certain >>> implementations MAY use different methods than the ones described >>> here, and still comply with the protocol specification." >>>=20 >>> and implementer could totally ignore the MUSTs in section 6.1.3: >>>=20 >>> "6.1.3. Receiving Requests >>>=20 >>> A relay or proxy agent MUST check for forwarding loops when = receiving >>> requests. A loop is detected if the server finds its own identity = in >>> a Route-Record AVP. When such an event occurs, the agent MUST = answer >>> with the Result-Code AVP set to DIAMETER_LOOP_DETECTED." >>>=20 >>> and still claim to comply with the protocol specification. >>>=20 >>> Would the following work for you: >>>=20 >>> "The overview contained in this section (6.1) are intended to be >>> used as general guidelines to Diameter developers. Implementations >>> are free to use different methods than the ones described here as = long >>> as they conform to the requirements in sections 6.1.1 through = 6.1.9". >>=20 >> Would work for me. >=20 > OK, this is what I have now: >=20 > The overview contained in this section (6.1) is intended to provide > general guidelines to Diameter developers. Implementations are free > to use different methods than the ones described here as long as = they > conform to the requirements specified in Sections 6.1.1 through > 6.1.9. See Section 7 for more detail on error handling. >=20 > ... > From rjsparks@nostrum.com Wed Mar 7 12:05:27 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0497D11E8097; Wed, 7 Mar 2012 12:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1otAXoChWQzS; Wed, 7 Mar 2012 12:05:25 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D8C4111E8094; Wed, 7 Mar 2012 12:05:24 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q27K5FXQ091114 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Mar 2012 14:05:18 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F57BF79.7060403@nostrum.com> Date: Wed, 07 Mar 2012 14:05:13 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Glen Zorn References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> In-Reply-To: <4F571650.5010103@gmail.com> Content-Type: multipart/alternative; boundary="------------070309020301060702060703" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Fri, 09 Mar 2012 01:07:59 -0800 Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG , dime-chairs@tools.ietf.org Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 20:05:27 -0000 This is a multi-part message in MIME format. --------------070309020301060702060703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks for the response Glen Discussion inline. On 3/7/12 2:03 AM, Glen Zorn wrote: > On 9/21/2011 4:17 AM, Robert Sparks wrote: September. Ouch. Swapping state back in... >> Robert Sparks has entered the following ballot position for >> draft-ietf-dime-rfc3588bis-29: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The document reflects the change of the name of the Well-Known >> IANA policy definition from "IETF Consensus" to "IETF Review", but >> seems to state that this is a change of policy rather than a change >> of the policy name (as explained in RFC5226). Specifically, it says >> "now only require IETF Review as opposed to an IETF Consensus". >> Has the working group captured what it intended? > I don't think so; how about this: > > OLD: > AVPs may be allocated following Expert Review (or Designated Expert) > with Specification Required [RFC5226]. As a change from RFC3588, a > block allocation (release of more than 3 at a time for a given > purpose) now only require IETF Review as opposed to an IETF Consensus > in RFC3588. > > NEW: > AVPs may be allocated following Expert Review (or Designated Expert) > with Specification Required [RFC5226]. A block allocation (release > of more than 3 AVPs at a time for a given purpose) requires IETF > Review. OK >> This sentence in section 2.1 is not clear: >> For TLS [RFC5246] and DTLS [RFC4347], a Diameter >> node that initiate a connection prior to any message exchanges MUST >> run on port [TBD]. >> What was its intent? It could be misread to say that you cannot establish >> a connection on any other port than [TBD]. > I'm not sure that that would be a mis-reading. If that's the case, consider saying "run only on port". But doesn't that interact badly with the peer discovery mechanism? Or are you saying it would be an error to create an SRV record that pointed to any port other than TBD? > >> In the new text on dynamic agent discovery, Section 5.2 part 3 - >> should an element that's looked up SRV records as specified in this >> item follow all of the requirements in RFC 2782 if multiple SRV records >> are returned (in particular, following the balancing algorithm over >> records with the same Priority)? Shouldn't this section reference RFC 2782? > Makes sense to me. How about this: > > OLD: > 3. If no NAPTR records are found, the requester directly queries for > SRV records '_diameter._sctp'.realm, '_diameter._dtls'.realm, > '_diameter._tcp'.realm and '_diameter._tls'.realm depending on > the requesters network protocol capabilities. If SRV records are > found then the requester can perform address record query (A RR's > and/or AAAA RR's) for the target hostname specified in the SRV > records. If no SRV records are found, the requester gives up. > > NEW: > 3. If no NAPTR records are found, the requester directly queries for > one of the following SRV records: for Diameter over TCP, use > "_diameter._tcp.realm"; for Diameter over TLS, use > "_diameters._tcp.realm"; for Diameter over SCTP, use > "_diameter._sctp.realm"; for Diameter over DTLS, use > "_diameters._sctp.realm". If SRV records are found then the > requester can perform address record query (A RR's and/or AAAA > RR's) for the target hostname specified in the SRV records > following the rules given in Gulbrandsen, et al. [RFC2782]. If > no SRV records are found, the requester gives up. OK >> In the new text on the Election Process, "lexicographically succeeds" needs >> additional description. > Not quite sure why: IIRC, the term was chosen because it precisely > states the desired operation and is well-understood (straight out of > Intro to CS, actually). Rereading this after several months, I think it's fine. My point was you need to specify the lexicon. You did (case-insensitive ASCII - so you know "A2"<"AA"). The way you point to Appendix D makes it seem that will affect ordering (it doesn't). Is there a place in the DNS specs you can point to that makes order comparisons explicit to remove all potential ambiguity? > >> The note at the end of 6.1 is very ambiguous - does "this section" mean >> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those >> subsections? Either way, it leaves the requirements language very hard >> to follow. Does this say certain implemenentations MAY ignore some MUSTs? >> If so, which ones? > Again, I'm having trouble seeing any ambiguity here: the word "this" > very specific and the phrase "this section", if present in a section, > seems only to denote that section, not any sections that might follow or > precede it. Maybe cut down on the caffeine? ;-) You didn't answer whether you believe 6.1.1 is part of, or follows, 6.1. > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> In section 1.3.1's second paragraph, starting the second sentence with >> "Typically," is likely to introduce confusion about the allocation policy. > How can it introduce confusion about allocation policy _in this > document_ when the whole paragraph is just suggesting policies for > _other documents_? > >> Why is the word needed in this sentence? > Because it's not specifying a rule, it's just making a suggestion. I don't know what potential confusion I saw at the time. I'll remove the comment, but consider changing "should" to "would" in that suggestion. > >> In section 2, 2nd to last paragraph before section 2.1: This edit (moving >> how tranparency is described) resulted in a sentence that says Diameter Relays >> and redirect agents MUST support all Diameter applications. Please consider >> touching it again to make it clearer that those elements MUST be transparent >> to the applications, and as a result trivially support them. > It's hard to see the difference. A clarification would make it more obvious that "support" in this circumstance means simply "be transparent". Encourage the focus of the implementer towards being transparent to an abstract thing rather than making sure they "support" whatever the current list of defined applications is. > >> In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP, >> please consider pointing out that section 2.2 still requires _SOME_ security >> mechanism be used. > The reason why the initiator reverts is that the peer only supports RFC > 3588, which requires some security mechanism to be used. It would hurt to point that out? > >> The edits to the first paragraph of the description of AVP flags left >> the sentence "Unrecognized bits SHOULD be considered an error." unsupported. >> It's not clear (without looking at the diff to 3588) what bits might >> possibly be unrecognized. > I think that this is correct: any unrecognized bit would have to be one > of the 'r' bits it seems& a sender MUST set all the r' bits to 0 so > this can never happen (with a conformant implementation. How about we > just remove that sentence? I think you still need it. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. The 3588bis text says this now: New Diameter applications SHOULD NOT define additional AVP Flag bits. The sender of the AVP MUST set 'r' (reserved) bits to 0 and the receiver SHOULD ignore all 'r' (reserved) bits. Unrecognized bits SHOULD be considered an error. The new text still leaves the possibility for additional (unrecognized) AVP bits to show up, defined by new applications. Maybe just swap the last two sentences in the new text? >> In section 6.1.2, can the document say why the hop-by-hop identifier >> SHOULD be locally unique rather than MUST be? > I don't know; anybody? > >> >> NITS: >> In section 1.3.1 paragraph 1, the reference to 11.4 should be 11.3. > Fixed. > >> Section 2.7 Realm Name: s/that is MUST/that MUST/ > Fixed > >> Section 6.1.9: s/list of commonly recommended/list of common recommendations/ >> > Fixed. > >> Something is wrong with this line in section 7.2 >> (The line is unchanged from 3588, but if this is a bug, it should be >> addressed at some point). >> ::=< Diameter Header: code, ERR [PXY]> >> That has either one too many or one too few commas in it. > I think that this should read > ::=< Diameter Header: code, ERR [, PXY]> > >> The following is a pedantic nit, but please consider addressing it. >> In several places (both in text from 3588 and new text introduced as >> part of this effort), the text refers to the definitions of commands >> in the representational language defined in section 3.2 as ABNF. For >> example: >> The Grouped Data field has the following ABNF grammar: >> >> Proxy-Info ::=< AVP Header: 284> >> { Proxy-Host } >> { Proxy-State } >> * [ AVP ] >> >> That is not ABNF. Instead, it is a well formed message in a language described >> by the ABNF in section 3.2. It would be better to say something like >> "The Grouped data field has the following Command Code specification:". > This particular pedantic nit seems very popular amongst the IESG ;-). I > would like it very much if you folks could come to a consensus as to > whether it must be changed and, if so, how to change it. TIA! Well, I put this in as a comment, not a blocking point. I think changing it would make the document more correct, and the suggestion I make above would fix it and doesn't look too hard to implement. Am I missing something? >> >> >> >> --------------070309020301060702060703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Thanks for the response Glen

Discussion inline.

On 3/7/12 2:03 AM, Glen Zorn wrote: 
On 9/21/2011 4:17 AM, Robert Sparks wrote:
September. Ouch.  Swapping state back in...

      

        
Robert Sparks has entered the following ballot position for
draft-ietf-dime-rfc3588bis-29: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The document reflects the change of the name of the Well-Known
IANA policy definition from "IETF Consensus" to "IETF Review", but
seems to state that this is a change of policy rather than a change
of the policy name (as explained in RFC5226).  Specifically, it says
"now only require IETF Review as opposed to an IETF Consensus".
Has the working group captured what it intended?


      

      
I don't think so; how about this:

OLD:
   AVPs may be allocated following Expert Review (or Designated Expert)
   with Specification Required [RFC5226].  As a change from RFC3588, a
   block allocation (release of more than 3 at a time for a given
   purpose) now only require IETF Review as opposed to an IETF Consensus
   in RFC3588.

NEW:
   AVPs may be allocated following Expert Review (or Designated Expert)
   with Specification Required [RFC5226].  A block allocation (release
   of more than 3 AVPs at a time for a given purpose) requires IETF
   Review.

    

    OK

    

      

      

        
This sentence in section 2.1 is not clear:
   For TLS [RFC5246] and DTLS [RFC4347], a Diameter
   node that initiate a connection prior to any message exchanges MUST
   run on port [TBD].
What was its intent? It could be misread to say that you cannot establish
a connection on any other port than [TBD].


      

      
I'm not sure that that would be a mis-reading.

    

    If that's the case, consider saying "run only on port". But doesn't
    that interact badly

    with the peer discovery mechanism? Or are you saying it would be an
    error to create

    an SRV record that pointed to any port other than TBD?

    

      



      

        
In the new text on dynamic agent discovery, Section 5.2 part 3 -
should an element that's looked up SRV records as specified in this
item follow all of the requirements in RFC 2782 if multiple SRV records
are returned (in particular, following the balancing algorithm over
records with the same Priority)? Shouldn't this section reference RFC 2782?


      

      
Makes sense to me.  How about this:

OLD:
   3.  If no NAPTR records are found, the requester directly queries for
       SRV records '_diameter._sctp'.realm, '_diameter._dtls'.realm,
       '_diameter._tcp'.realm and '_diameter._tls'.realm depending on
       the requesters network protocol capabilities.  If SRV records are
       found then the requester can perform address record query (A RR's
       and/or AAAA RR's) for the target hostname specified in the SRV
       records.  If no SRV records are found, the requester gives up.

NEW:
   3.  If no NAPTR records are found, the requester directly queries for
       one of the following SRV records: for Diameter over TCP, use
       "_diameter._tcp.realm"; for Diameter over TLS, use
       "_diameters._tcp.realm"; for Diameter over SCTP, use
       "_diameter._sctp.realm"; for Diameter over DTLS, use
       "_diameters._sctp.realm".  If SRV records are found then the
       requester can perform address record query (A RR's and/or AAAA
       RR's) for the target hostname specified in the SRV records
       following the rules given in Gulbrandsen, et al.  [RFC2782].  If
       no SRV records are found, the requester gives up.

    

    OK

    

      

      

        
In the new text on the Election Process, "lexicographically succeeds" needs
additional description.


      

      
Not quite sure why: IIRC, the term was chosen because it precisely
states the desired operation and is well-understood (straight out of
Intro to CS, actually).


    

    Rereading this after several months, I think it's fine. My point was
    you need to specify

    the lexicon. You did (case-insensitive ASCII - so you know
    "A2"<"AA"). The way you

    point to Appendix D makes it seem that will affect ordering (it
    doesn't). Is there a place

    in the DNS specs you can point to that makes order comparisons
    explicit to remove

    all potential ambiguity?

    

    

      



    

    

      

        
The note at the end of 6.1 is very ambiguous - does "this section" mean
just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those
subsections?  Either way, it leaves the requirements language very hard
to follow.  Does this say certain implemenentations MAY ignore some MUSTs?
If so, which ones?


      

      
Again, I'm having trouble seeing any ambiguity here: the word "this"
very specific and the phrase "this section", if present in a section,
seems only to denote that section, not any sections that might follow or
precede it.  Maybe cut down on the caffeine? ;-)

    

    You didn't answer whether you believe 6.1.1 is part of, or follows,
    6.1.

    

      



      

        


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In section 1.3.1's second paragraph, starting the second sentence with
"Typically," is likely to introduce confusion about the allocation policy.


      

      
How can it introduce confusion about allocation policy _in this
document_ when the whole paragraph is just suggesting policies for
_other documents_?



      

        
Why is the word needed in this sentence?


      

      
Because it's not specifying a rule, it's just making a suggestion.

    

    I don't know what potential confusion I saw at the time. I'll remove
    the comment,

    but consider changing "should" to "would" in that suggestion.

    

      



      

        
In section 2, 2nd to last paragraph before section 2.1: This edit (moving
how tranparency is described) resulted in a sentence that says Diameter Relays
and redirect agents MUST support all Diameter applications. Please consider
touching it again to make it clearer that those elements MUST be transparent
to the applications, and as a result trivially support them.


      

      
It's hard to see the difference.

    

    A clarification would make it more obvious that "support" in this
    circumstance

    means simply "be transparent". Encourage the focus of the
    implementer towards

    being transparent to an abstract thing rather than making sure they
    "support"

    whatever the current list of defined applications is.

    

    

      



      

        
In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP,
please consider pointing out that section 2.2 still requires _SOME_ security
mechanism be used.


      

      
The reason why the initiator reverts is that the peer only supports RFC
3588, which requires some security mechanism to be used.

    

    It would hurt to point that out?

    

      



      

        
The edits to the first paragraph of the description of AVP flags left
the sentence "Unrecognized bits SHOULD be considered an error." unsupported.
It's not clear (without looking at the diff to 3588) what bits might
possibly be unrecognized.


      

      
I think that this is correct: any unrecognized bit would have to be one
of the 'r' bits it seems & a sender MUST set all the r' bits to 0 so
this can never happen (with a conformant implementation.  How about we
just remove that sentence?

    

    I think you still need it.

    

    Note that subsequent Diameter applications MAY
      define  additional bits within the
      AVP Header, and an unrecognized bit 
      SHOULD be considered an error.

      

      The 3588bis text says this now:

    
    
    New Diameter applications SHOULD NOT define

          additional AVP Flag bits.  The sender of the AVP MUST set 'r'

          (reserved) bits to 0 and the receiver SHOULD ignore all 'r'

          (reserved) bits.  Unrecognized bits SHOULD be considered an
    error.

    

    The new text still leaves the possibility for additional
    (unrecognized) AVP bits to show up,

    defined by new applications.

    

    Maybe just swap the last two sentences in the new text?

    

      

        
In section 6.1.2, can the document say why the hop-by-hop identifier
SHOULD be locally unique rather than MUST be?


      

      
I don't know; anybody?



      

        

NITS:
In section 1.3.1 paragraph 1, the reference to 11.4 should be 11.3.


      

      
Fixed.



      

        
Section 2.7 Realm Name: s/that is MUST/that MUST/


      

      
Fixed



      

        
Section 6.1.9: s/list of commonly recommended/list of common recommendations/



      

      
Fixed.



      

        
Something is wrong with this line in section 7.2
(The line is unchanged from 3588, but if this is a bug, it should be
addressed at some point). 
      <answer-message> ::= < Diameter Header: code, ERR [PXY] >
That has either one too many or one too few commas in it.


      

      
I think that this should read
<answer-message> ::= < Diameter Header: code, ERR [, PXY] >



      

        
The following is a pedantic nit, but please consider addressing it.
In several places (both in text from 3588 and new text introduced as
part of this effort), the text refers to the definitions of commands
in the representational language defined in section 3.2 as ABNF. For
example:
   The Grouped Data field has the following ABNF grammar:

         Proxy-Info ::= < AVP Header: 284 >
                        { Proxy-Host }
                        { Proxy-State }
                      * [ AVP ]

That is not ABNF. Instead, it is a well formed message in a language described
by the ABNF in section 3.2. It would be better to say something like
"The Grouped data field has the following Command Code specification:".


      

      
This particular pedantic nit seems very popular amongst the IESG ;-).  I
would like it very much if you folks could come to a consensus as to
whether it must be changed and, if so, how to change it.  TIA!

    

    Well, I put this in as a comment, not a blocking point.

    

    I think changing it would make the document more correct, and the
    suggestion

    I make above would fix it and doesn't look too hard to implement. Am
    I missing something?

    

    

      

      

        






      

      

    

  


--------------070309020301060702060703--

From lionel.morand@orange.com  Fri Mar  9 01:34:35 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445E621F85FB for ; Fri,  9 Mar 2012 01:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.874
X-Spam-Level: 
X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojc1coaSPxDP for ; Fri,  9 Mar 2012 01:34:34 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 47CEB21F85E4 for ; Fri,  9 Mar 2012 01:34:34 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6A54216C004; Fri,  9 Mar 2012 10:34:33 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5D8A416C001; Fri,  9 Mar 2012 10:34:33 +0100 (CET)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 9 Mar 2012 10:34:33 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 9 Mar 2012 10:34:32 +0100
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Is DNS-based diameter peer discovery mandatoryto	implement?
Thread-Index: AQHM/aDrCTcyKAf0xkirV4fpmcN2h5ZhQqUAgAAC6ACAAAOiAIAAXLrQgAACZAA=
References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com><4F59BF02.7060405@gmail.com> 
From: 
To: , , 
X-OriginalArrivalTime: 09 Mar 2012 09:34:33.0383 (UTC) FILETIME=[D5CF4B70:01CCFDD7]
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatoryto	implement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 09:34:35 -0000

If it is only about the node, is there even any reason to "mandate" the =
implementation of DNS in a node?

What about:

"A Diameter implementation MUST include the first option (manual =
configuration) and MAY [or "SHOULD" if preferred] include the latter =
option (DNS)."

Regards,

Lionel

-----Message d'origine-----
De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part =
de Krishna Prasad
Envoy=E9=A0: vendredi 9 mars 2012 09:46
=C0=A0: jouni korhonen; Glen Zorn
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] Is DNS-based diameter peer discovery mandatoryto =
implement?



-----Original Message-----
From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of =
jouni korhonen
Sent: Friday, March 09, 2012 2:11 PM
To: Glen Zorn
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to =
implement?

Glen,

On Mar 9, 2012, at 10:27 AM, Glen Zorn wrote:

> On 3/9/2012 3:17 PM, jouni korhonen wrote:
>>=20
>> Hi,
>>=20
>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>>=20
>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>>> Question: Is the DNS-based peer discovery mechanism mandatory to =
implement?
>>>>=20
>>>> The first paragraph of 5.2 speaks in terms of "supported" and if =
you
>>>> read that to mean "implemented" the answer is no, but after talking =
to
>>>> some folks I'm not sure that was the intent. Was the intent =
mandatory to
>>>> implement, optional to use?=20
>>>=20
>>> Good question.  The text in question uses the term "Diameter node",
>>> which is a computer actually running Diameter, so my take on it =
would be
>>> that the node might not support the option (in terms of actually =
using
>>> it)but that the option would nevertheless be available (i.e.,
>>> implemented).  It seems like the text could be clearer though -- any
>>> suggestions?
>>=20
>> How about:
>>=20
>>   ..
>>   discovery, the following mechanisms are described.  These are based
>>   on existing IETF standards.  The first option (manual =
configuration)
>>   MUST be implemented and supported by all Diameter nodes, while the
>>   latter option (DNS) MAY be implemented and MAY be supported  by
>>   Diameter nodes.
>>=20
>> However, we could also try to make DNS option more widely used, since
>> every box in practice has to have some level of DNS resolver =
capability:
>>=20
>>   ..
>>   MUST be implemented and supported by all Diameter nodes, while the
>>   latter option (DNS) SHOULD be implemented and if implemented MAY be
>>   used by Diameter nodes.
>>=20
>>=20
>> Opinions?
>=20
> As I mentioned, I had always thought that it was a requirement of an
> implementation, just that you don't have support it in a deployment =
due
> to the use of the term "node".

My interpretation has always been not mandatory/required to implement.
What the others think? If folks think it has always been required we
need to make the wording explicit. If there are others (apart from me
and Lionel) who read it as not required to implement, I guess SHOULD
is the strongest we can have here.

- Jouni

I agree with Joni & Lionel, I never interpreted this as =
mandatory/required and always thought it is optional.=20

-Prasad

>=20
>>=20
>>=20
>> - Jouni
>>=20
>>=20
>>=20
>>>=20
>>>> That would ensure that an operator had the
>>>> option to start using the DNS-based discovery mechanism when it was =
the
>>>> right thing to do.
>>>>=20
>>>> RjS
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20

_______________________________________________
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 gwz@net-zen.net  Fri Mar  9 03:33:55 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCA821F85D1; Fri,  9 Mar 2012 03:33:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6Fr5WH+Yt85; Fri,  9 Mar 2012 03:33:54 -0800 (PST)
Received: from m1plsmtpa01-08.prod.mesa1.secureserver.net (m1plsmtpa01-08.prod.mesa1.secureserver.net [64.202.165.187]) by ietfa.amsl.com (Postfix) with ESMTP id 81FC921F8592; Fri,  9 Mar 2012 03:33:49 -0800 (PST)
Received: from [192.168.1.98] ([124.122.247.39]) by m1plsmtpa01-08.prod.mesa1.secureserver.net with  id jPZk1i0070rkJNs01PZmy7; Fri, 09 Mar 2012 04:33:48 -0700
Message-ID: <4F59EA98.8060106@net-zen.net>
Date: Fri, 09 Mar 2012 18:33:44 +0700
From: Glen Zorn 
Organization: Network Zen
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: jouni korhonen 
References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com>  <4F5990F2.1080807@net-zen.net> 
In-Reply-To: 
X-Enigmail-Version: 1.3.5
Content-Type: multipart/mixed; boundary="------------050404070405050702050409"
Cc: dime-chairs@tools.ietf.org, draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, The IESG 
Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 11:33:55 -0000

This is a multi-part message in MIME format.
--------------050404070405050702050409
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 3/9/2012 3:49 PM, jouni korhonen wrote:
> 
> Glen, Robert, WG,
> 
> On Mar 9, 2012, at 7:11 AM, Glen Zorn wrote:
> 
>> On 3/9/2012 5:26 AM, Jouni wrote:
>>>
>>> Robert,
>>>
>>> On Mar 8, 2012, at 11:17 PM, Robert Sparks wrote:
>>>
>>>>
>>>>
>>>> On 3/7/12 9:01 PM, Glen Zorn wrote:
>>>>> On 3/8/2012 3:05 AM, Robert Sparks wrote:
>>>>>> Thanks for the response Glen
>>>>>>
>>>>>> Discussion inline.
>>>>>>
>>>>> ...
>>>>>
>>>>>>>> This sentence in section 2.1 is not clear:
>>>>>>>>   For TLS [RFC5246] and DTLS [RFC4347], a Diameter
>>>>>>>>   node that initiate a connection prior to any message exchanges MUST
>>>>>>>>   run on port [TBD].
>>>>>>>> What was its intent? It could be misread to say that you cannot establish
>>>>>>>> a connection on any other port than [TBD].
>>>>>>> I'm not sure that that would be a mis-reading.
>>>>>> If that's the case, consider saying "run only on port". But doesn't that
>>>>>> interact badly
>>>>>> with the peer discovery mechanism? Or are you saying it would be an
>>>>>> error to create
>>>>>> an SRV record that pointed to any port other than TBD?
>>>>> Actually, I'm just not sure (I didn't write this part ;-).  I'm hoping
>>>>> that somebody else will chime in...
>>>> Who should be responding?
>>>>
>>>> I think the right thing to do here is to change the MUST above to "by default" and note that
>>>> the SRV-based peer discovery mechanism may specify other ports.
>>>
>>> It actually looks fuzzy.. "run on port" intends to say that a Diameter node
>>> must at least bind its listening socket to port [TBD]. When creating a connection
>>> the source port can be other than [TBD] but should be the same [TBD]..
>>>
>>> The wording does not actually allow listening for incoming connections on
>>> other ports that 3868 and [TBD], which effectively puts a restriction on
>>> the use of SRV.
>>
>> OK, so how to change it?
> 
> I looked back to old archives back to early 2000 and there John Loughney
> said that NAPTR was introduced to allow flexibility on TLS ports i.e. not
> only rely on fixed port numbers. So we probably then should make it clear
> a DNS based peer discovery can override default ports. How about:
> 
>    ...
> 
>    The base Diameter protocol is run (i.e., listens for incoming connections)
>    on port 3868 for both TCP [RFC793] and SCTP [RFC4960]. It is assumed that
>    TLS [RFC5246] is run on top of TCP when it is used and DTLS [RFC6347] is
>    run on top of SCTP when it is used.
> 
>    If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
>    connections on port [TBD], i.e. the peer complies only with
>    [RFC3588], then the initiator MAY revert to using TCP or SCTP and on
>    port 3868.  Note that this scheme is kept for the purpose of
>    backwards compatibility only and that there are inherent security
>    vulnerabilities when the initial CER/CEA messages are sent un-
>    protected (see Section 5.6).
> 
>    Diameter clients MUST support either TCP or SCTP, while agents and
>    servers SHOULD support both.
> 
>    A Diameter node MAY initiate connections from a source port other
>    than the one that it declares it accepts incoming connections on, and
>    MUST always be prepared to receive connections on port 3868 for TCP or
>    SCTP and port [TBD] for TLS/TCP and DTLS/SCTP connections. When DNS-based
>    peer discovery is used, the port numbers received from SRV records
>    take precedence over default ports 3868 and [TBD].
> 
> 
> Comments?

Fine with me.

...

--------------050404070405050702050409
Content-Type: text/x-vcard; charset=utf-8;
 name="gwz.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="gwz.vcf"

begin:vcard
fn:Glen Zorn
n:Zorn;Glen
org:Network Zen
adr:;;;Seattle;WA;;USA
email;internet:gwz@net-zen.net
tel;cell:+66 87 040 4617
note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C  2EE1 6E17 B5F6 5953 B45F 
version:2.1
end:vcard


--------------050404070405050702050409--

From emcmurry@estacado.net  Fri Mar  9 05:55:06 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E65F21F863F; Fri,  9 Mar 2012 05:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.452
X-Spam-Level: 
X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=1.148,  BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAO5w8YlIHM2; Fri,  9 Mar 2012 05:55:05 -0800 (PST)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 602C821F8606; Fri,  9 Mar 2012 05:55:05 -0800 (PST)
Received: from embp.mcmurry.home (cpe-76-184-255-34.tx.res.rr.com [76.184.255.34]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q29DsuWt050064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2012 07:55:00 -0600 (CST) (envelope-from emcmurry@estacado.net)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Eric McMurry 
In-Reply-To: <4F5983E0.6010400@net-zen.net>
Date: Fri, 9 Mar 2012 07:54:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <747670AF-F5E4-415B-AD12-037E8D6A7F95@estacado.net>
References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> <4F5983E0.6010400@net-zen.net>
To: Glen Zorn 
X-Mailer: Apple Mail (2.1257)
Cc: dime-chairs@tools.ietf.org, draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , The IESG 
Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 13:55:06 -0000

On Mar 8, 2012, at 22:15 , Glen Zorn wrote:

> On 3/9/2012 4:17 AM, Robert Sparks wrote:
>=20
>> On 3/7/12 9:01 PM, Glen Zorn wrote:
>>> On 3/8/2012 3:05 AM, Robert Sparks wrote:
>>>> Thanks for the response Glen
>>>>=20
>>>> Discussion inline.
>>>>=20
>>>=20
[...]
>=20
>>>=20
>>>>>> In section 2, 2nd to last paragraph before section 2.1: This edit
>>>>>> (moving
>>>>>> how tranparency is described) resulted in a sentence that says
>>>>>> Diameter Relays
>>>>>> and redirect agents MUST support all Diameter applications. =
Please
>>>>>> consider
>>>>>> touching it again to make it clearer that those elements MUST be
>>>>>> transparent
>>>>>> to the applications, and as a result trivially support them.
>>>>> It's hard to see the difference.
>>>> A clarification would make it more obvious that "support" in this
>>>> circumstance
>>>> means simply "be transparent". Encourage the focus of the =
implementer
>>>> towards
>>>> being transparent to an abstract thing rather than making sure they
>>>> "support"
>>>> whatever the current list of defined applications is.
>>> I think we may be talking about two different kinds of transparency. =
 I
>>> don't think that redirect agents, in particular, can actually be
>>> transparent to the endpoint nodes (since they actually return a =
message
>>> telling where to send the original message) ;
>> Sure, but the redirect mechanics are general, not application =
specific.
>>>  relays can probably be
>>> transparent, but they need to recognize, at least, any Diameter =
message
>>> that comes to them so that it can be forwarded correctly.
>> Fair enough. The end goal is to make sure redirect agents and relays =
don't
>> necessarily have to be touched in order to deploy new applications. =
The
>> behavior I'm hoping most  to not encourage is a relay keeping a list =
of
>> applications
>> that it checks each message against before forwarding it.
>=20
> Because Diameter messages are outed by app ID & realm, I'm not sure =
how
> that can be avoided.
>=20
>>=20
>> That said, I don't have text to propose, and you've done what I asked
>> (which was to consider
>> a clarification). I'm willing to let this go.
>=20
> OK, thanks.

The difference is wether the list of applications considered for routing =
is static or dynamic at compile time for a given implementation.  I =
think the push for language that included "transparent" was intended to =
suggest to implementors that the list of applications not be compiled =
in, which would result in compliance with the letter, but not the spirit =
of the current requirement language.


From barryleiba@gmail.com  Fri Mar  9 05:49:39 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3BB21F85FC; Fri,  9 Mar 2012 05:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.985
X-Spam-Level: 
X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw8Q7ochSXNA; Fri,  9 Mar 2012 05:49:38 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8104921F85EA; Fri,  9 Mar 2012 05:49:38 -0800 (PST)
Received: by obbta4 with SMTP id ta4so2475962obb.31 for ; Fri, 09 Mar 2012 05:49:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EjI6I2RkjYjPiulx3raN19ko6Sk8awDqIJg5sjcDfIk=; b=EsCOroeuBUNR71L8EKvD4JLb5TFCf7m2SxW0Q5ZDNWDoOTAaYvjo+0HL3yeGoY/WmJ /nGQ7NjSU9z83S1mZf2G7bcRs4PXxGi2ok1G8Ky+hw58xTdIX+Q5G+o/433AyNFYoOu6 nClKZTv8cxIVJ7P5eVTKur2k0MJ4R+jUdZIn5JpsAAdZ7XroikkAvuM9p+PFYV+evAcJ 8K2Y9jZnKyRyy5qm5uoUrrotKMrhvicmkIg8KhHYbIlxKjnYaZhsNWLVcE37hVLxmPZm JEY0WMsykd0wTZNxTjGWS9b9JnROsH62PYxVMJ2x8ZvmGDNgxfL+p1+ycvRT+UOGi9qu rUJA==
MIME-Version: 1.0
Received: by 10.182.75.103 with SMTP id b7mr873981obw.54.1331300978161; Fri, 09 Mar 2012 05:49:38 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.60.125.37 with HTTP; Fri, 9 Mar 2012 05:49:37 -0800 (PST)
In-Reply-To: <4F59AEF2.8040008@gmail.com>
References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> <4F5927D1.6020907@nostrum.com> <4F59AEF2.8040008@gmail.com>
Date: Fri, 9 Mar 2012 08:49:37 -0500
X-Google-Sender-Auth: zKNLDAB-BQKHg5iHcXE3bUS8fOw
Message-ID: 
From: Barry Leiba 
To: Glen Zorn 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 09 Mar 2012 06:03:27 -0800
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Glen Zorn , "dime@ietf.org" , The IESG 
Subject: Re: [Dime] Command Code syntax vs ABNF
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 13:49:39 -0000

>> That isn't ABNF, it's an expression in the command code grammar defined
>> by the ABNF in section 3.2.
>> An ABNF parser would reject it if you provided it as input. A diameter
>> command code syntax parser would
>> accept it.
...
>> Would anyone object to changing the places where ABNF is misused to
>> variants of "command code specification"?
>
> I would: there are at least 50 of those places in the draft and each
> would require individualized wordsmithing. =A0If it really needs to be
> changed, I would prefer to have an acronym with which I could just
> globally replace "ABNF", saving hours of work.

Fair enough.  How about this suggestion, then?

3588bis, section 3.2:
OLD
   Every Command Code defined MUST include a corresponding ABNF
   specification, which is used to define the AVPs that MUST or MAY be
   present when sending the message.  The following format is used in
   the definition:
NEW
   Every Command Code defined MUST include a corresponding
   Command Code Format (CCF) specification, which is used to define
   the AVPs that MUST or MAY be present when sending the message.
   The following ABNF specifies the CCF used in the definition:

Then you replace "ABNF" with "CCF":

>> For instance, the errant sentence in 4.4.1 would become "The Grouped
>> Data field has the following command code specification". In section
>> 6.6, "An ABNF for a request message" would be come "The command code
>> specification for a request message". And so on.

Now that becomes this:

"The Grouped Data field has the following CCF grammar:"
"The CCF for a request message"

It's a LITTLE more than just replacing "ABNF" with "CCF", because you
may have to change "an" to "a" or "the", but it should be quite easy.
(I suppose we could call it "Augmented Command Code Format", and get
around even that.)  Any document that cites 3588bis can put CCF (with
a citation) into its terminology section, and use "CCF" as well.

Barry

From rjsparks@nostrum.com  Fri Mar  9 07:19:44 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E639721F851B for ; Fri,  9 Mar 2012 07:19:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.245
X-Spam-Level: 
X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AWw4xjPc5Ik for ; Fri,  9 Mar 2012 07:19:44 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4066E21F8518 for ; Fri,  9 Mar 2012 07:19:44 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q29FJfrN012717 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 09:19:42 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <4F5A1F8D.4010607@nostrum.com>
Date: Fri, 09 Mar 2012 09:19:41 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: jouni korhonen 
References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com> <19E9D894-679C-437A-93EF-11629C0D4453@gmail.com>
In-Reply-To: <19E9D894-679C-437A-93EF-11629C0D4453@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 15:19:45 -0000

On 3/9/12 2:17 AM, jouni korhonen wrote:
> Hi,
>
> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>
>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>> Question: Is the DNS-based peer discovery mechanism mandatory to implement?
>>>
>>> The first paragraph of 5.2 speaks in terms of "supported" and if you
>>> read that to mean "implemented" the answer is no, but after talking to
>>> some folks I'm not sure that was the intent. Was the intent mandatory to
>>> implement, optional to use?
>> Good question.  The text in question uses the term "Diameter node",
>> which is a computer actually running Diameter, so my take on it would be
>> that the node might not support the option (in terms of actually using
>> it)but that the option would nevertheless be available (i.e.,
>> implemented).  It seems like the text could be clearer though -- any
>> suggestions?

It's not sufficient to rely on the underlying computer having DNS libraries.
You specified DIAMETER specific logic - the person that wrote the 
diameter code
is going to have to write code - it might _use_ a DNS library on an 
underlying
OS, but it's the DIAMETER code that's going to have to provide the 
inputs to the
NAPTR queries, (or SRV queries, if starting at that level), and follow 
the rules in
this document on interpreting the results. _Thats_ the code that needs 
to be mandatory
to implement.
> How about:
>
>     ..
>     discovery, the following mechanisms are described.  These are based
>     on existing IETF standards.  The first option (manual configuration)
>     MUST be implemented and supported by all Diameter nodes, while the
>     latter option (DNS) MAY be implemented and MAY be supported  by
>     Diameter nodes.
>
> However, we could also try to make DNS option more widely used, since
> every box in practice has to have some level of DNS resolver capability:
>
>     ..
>     MUST be implemented and supported by all Diameter nodes, while the
>     latter option (DNS) SHOULD be implemented and if implemented MAY be
>     used by Diameter nodes.
>
>
> Opinions?
>
>
> - Jouni
>
>
>
>>> That would ensure that an operator had the
>>> option to start using the DNS-based discovery mechanism when it was the
>>> right thing to do.
>>>
>>> RjS
>>>
>>> _______________________________________________
>>> 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 rjsparks@nostrum.com  Fri Mar  9 07:27:47 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39F621F86C7; Fri,  9 Mar 2012 07:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meS4VhUP6QAi; Fri,  9 Mar 2012 07:27:47 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 28D2B21F86C9; Fri,  9 Mar 2012 07:27:47 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q29FRiKE014176 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 09:27:45 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <4F5A2170.4010101@nostrum.com>
Date: Fri, 09 Mar 2012 09:27:44 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Glen Zorn 
References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com>  <4F5990F2.1080807@net-zen.net>  <4F59EA98.8060106@net-zen.net>
In-Reply-To: <4F59EA98.8060106@net-zen.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, dime-chairs@tools.ietf.org, The IESG 
Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 15:27:48 -0000

wfm

On 3/9/12 5:33 AM, Glen Zorn wrote:
> On 3/9/2012 3:49 PM, jouni korhonen wrote:
>> Glen, Robert, WG,
>>
>> On Mar 9, 2012, at 7:11 AM, Glen Zorn wrote:
>>
>>> On 3/9/2012 5:26 AM, Jouni wrote:
>>>> Robert,
>>>>
>>>> On Mar 8, 2012, at 11:17 PM, Robert Sparks wrote:
>>>>
>>>>>
>>>>> On 3/7/12 9:01 PM, Glen Zorn wrote:
>>>>>> On 3/8/2012 3:05 AM, Robert Sparks wrote:
>>>>>>> Thanks for the response Glen
>>>>>>>
>>>>>>> Discussion inline.
>>>>>>>
>>>>>> ...
>>>>>>
>>>>>>>>> This sentence in section 2.1 is not clear:
>>>>>>>>>    For TLS [RFC5246] and DTLS [RFC4347], a Diameter
>>>>>>>>>    node that initiate a connection prior to any message exchanges MUST
>>>>>>>>>    run on port [TBD].
>>>>>>>>> What was its intent? It could be misread to say that you cannot establish
>>>>>>>>> a connection on any other port than [TBD].
>>>>>>>> I'm not sure that that would be a mis-reading.
>>>>>>> If that's the case, consider saying "run only on port". But doesn't that
>>>>>>> interact badly
>>>>>>> with the peer discovery mechanism? Or are you saying it would be an
>>>>>>> error to create
>>>>>>> an SRV record that pointed to any port other than TBD?
>>>>>> Actually, I'm just not sure (I didn't write this part ;-).  I'm hoping
>>>>>> that somebody else will chime in...
>>>>> Who should be responding?
>>>>>
>>>>> I think the right thing to do here is to change the MUST above to "by default" and note that
>>>>> the SRV-based peer discovery mechanism may specify other ports.
>>>> It actually looks fuzzy.. "run on port" intends to say that a Diameter node
>>>> must at least bind its listening socket to port [TBD]. When creating a connection
>>>> the source port can be other than [TBD] but should be the same [TBD]..
>>>>
>>>> The wording does not actually allow listening for incoming connections on
>>>> other ports that 3868 and [TBD], which effectively puts a restriction on
>>>> the use of SRV.
>>> OK, so how to change it?
>> I looked back to old archives back to early 2000 and there John Loughney
>> said that NAPTR was introduced to allow flexibility on TLS ports i.e. not
>> only rely on fixed port numbers. So we probably then should make it clear
>> a DNS based peer discovery can override default ports. How about:
>>
>>     ...
>>
>>     The base Diameter protocol is run (i.e., listens for incoming connections)
>>     on port 3868 for both TCP [RFC793] and SCTP [RFC4960]. It is assumed that
>>     TLS [RFC5246] is run on top of TCP when it is used and DTLS [RFC6347] is
>>     run on top of SCTP when it is used.
>>
>>     If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
>>     connections on port [TBD], i.e. the peer complies only with
>>     [RFC3588], then the initiator MAY revert to using TCP or SCTP and on
>>     port 3868.  Note that this scheme is kept for the purpose of
>>     backwards compatibility only and that there are inherent security
>>     vulnerabilities when the initial CER/CEA messages are sent un-
>>     protected (see Section 5.6).
>>
>>     Diameter clients MUST support either TCP or SCTP, while agents and
>>     servers SHOULD support both.
>>
>>     A Diameter node MAY initiate connections from a source port other
>>     than the one that it declares it accepts incoming connections on, and
>>     MUST always be prepared to receive connections on port 3868 for TCP or
>>     SCTP and port [TBD] for TLS/TCP and DTLS/SCTP connections. When DNS-based
>>     peer discovery is used, the port numbers received from SRV records
>>     take precedence over default ports 3868 and [TBD].
>>
>>
>> Comments?
> Fine with me.
>
> ...

From rjsparks@nostrum.com  Fri Mar  9 07:28:27 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DD821F86AF; Fri,  9 Mar 2012 07:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.541
X-Spam-Level: 
X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vruyhNcPEwI7; Fri,  9 Mar 2012 07:28:26 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8942121F86D0; Fri,  9 Mar 2012 07:28:26 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q29FSO4o014268 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 09:28:25 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <4F5A2198.7090101@nostrum.com>
Date: Fri, 09 Mar 2012 09:28:24 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Glen Zorn 
References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com>  <4F5990F2.1080807@net-zen.net>
In-Reply-To: <4F5990F2.1080807@net-zen.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, "dime@ietf.org" , dime-chairs@tools.ietf.org, The IESG 
Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 15:28:27 -0000

Thanks Glen!

On 3/8/12 11:11 PM, Glen Zorn wrote:
> OK, this is what I have now:
>
>     The overview contained in this section (6.1) is intended to provide
>     general guidelines to Diameter developers.  Implementations are free
>     to use different methods than the ones described here as long as they
>     conform to the requirements specified in Sections 6.1.1 through
>     6.1.9.  See Section 7 for more detail on error handling.

From lionel.morand@orange.com  Fri Mar  9 09:12:43 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2B121F869F for ; Fri,  9 Mar 2012 09:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Level: 
X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk87Lx+dOzee for ; Fri,  9 Mar 2012 09:12:41 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7AF21F8697 for ; Fri,  9 Mar 2012 09:12:41 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D6192E3039F; Fri,  9 Mar 2012 18:13:51 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id CE66CE302E3; Fri,  9 Mar 2012 18:13:51 +0100 (CET)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 9 Mar 2012 18:12:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 9 Mar 2012 18:12:39 +0100
Message-ID: 
In-Reply-To: <4F5A1F8D.4010607@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
Thread-Index: Acz+CBE9i2rh8swTRM+cN66xEyEF9AAD6Rqg
References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> <4F5A1F8D.4010607@nostrum.com>
From: 
To: , 
X-OriginalArrivalTime: 09 Mar 2012 17:12:40.0604 (UTC) FILETIME=[D5785DC0:01CCFE17]
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 17:12:43 -0000

What about:

"A Diameter implementation MUST include the first option (manual =
configuration) and MAY [or "SHOULD" if preferred] include the latter =
option (DNS)."

Lionel

-----Message d'origine-----
De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part =
de Robert Sparks
Envoy=E9=A0: vendredi 9 mars 2012 16:20
=C0=A0: jouni korhonen
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] Is DNS-based diameter peer discovery mandatory =
toimplement?



On 3/9/12 2:17 AM, jouni korhonen wrote:
> Hi,
>
> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>
>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>> Question: Is the DNS-based peer discovery mechanism mandatory to =
implement?
>>>
>>> The first paragraph of 5.2 speaks in terms of "supported" and if you
>>> read that to mean "implemented" the answer is no, but after talking =
to
>>> some folks I'm not sure that was the intent. Was the intent =
mandatory to
>>> implement, optional to use?
>> Good question.  The text in question uses the term "Diameter node",
>> which is a computer actually running Diameter, so my take on it would =
be
>> that the node might not support the option (in terms of actually =
using
>> it)but that the option would nevertheless be available (i.e.,
>> implemented).  It seems like the text could be clearer though -- any
>> suggestions?

It's not sufficient to rely on the underlying computer having DNS =
libraries.
You specified DIAMETER specific logic - the person that wrote the=20
diameter code
is going to have to write code - it might _use_ a DNS library on an=20
underlying
OS, but it's the DIAMETER code that's going to have to provide the=20
inputs to the
NAPTR queries, (or SRV queries, if starting at that level), and follow=20
the rules in
this document on interpreting the results. _Thats_ the code that needs=20
to be mandatory
to implement.
> How about:
>
>     ..
>     discovery, the following mechanisms are described.  These are =
based
>     on existing IETF standards.  The first option (manual =
configuration)
>     MUST be implemented and supported by all Diameter nodes, while the
>     latter option (DNS) MAY be implemented and MAY be supported  by
>     Diameter nodes.
>
> However, we could also try to make DNS option more widely used, since
> every box in practice has to have some level of DNS resolver =
capability:
>
>     ..
>     MUST be implemented and supported by all Diameter nodes, while the
>     latter option (DNS) SHOULD be implemented and if implemented MAY =
be
>     used by Diameter nodes.
>
>
> Opinions?
>
>
> - Jouni
>
>
>
>>> That would ensure that an operator had the
>>> option to start using the DNS-based discovery mechanism when it was =
the
>>> right thing to do.
>>>
>>> RjS
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

From rjsparks@nostrum.com  Fri Mar  9 10:52:14 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD37821E808D for ; Fri,  9 Mar 2012 10:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.243
X-Spam-Level: 
X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnryvNXBy0hc for ; Fri,  9 Mar 2012 10:52:14 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 325CD21E8081 for ; Fri,  9 Mar 2012 10:52:13 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q29Iq9tl046371 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 12:52:10 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <4F5A5158.90402@nostrum.com>
Date: Fri, 09 Mar 2012 12:52:08 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: lionel.morand@orange.com
References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> <4F5A1F8D.4010607@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 18:52:14 -0000

I think we must be talking past each other. That suggestion doesn't look 
different than what's in -30, and
doesn't address the point I made in the message you responded to.

Let me try this a different way. The text in -30 and the text you 
propose below say that it's OK for
an operator to have deployed a "conformant" diameter implementation and 
later discover that he
can't use the DNS-based peer discovery mechanism without acquiring 
another one (or going back to
the original provider for a code change). Is that really what the group 
concluded? That would surprise me,
and I'd like to read the discussion so I can see how the group landed there.

I could see a decision that would say that manual configuration still 
needs to be an option available to the operator.

RjS

On 3/9/12 11:12 AM, lionel.morand@orange.com wrote:
> What about:
>
> "A Diameter implementation MUST include the first option (manual configuration) and MAY [or "SHOULD" if preferred] include the latter option (DNS)."
>
> Lionel
>
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Robert Sparks
> Envoyé : vendredi 9 mars 2012 16:20
> À : jouni korhonen
> Cc : dime@ietf.org
> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
>
>
>
> On 3/9/12 2:17 AM, jouni korhonen wrote:
>> Hi,
>>
>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>>
>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>>> Question: Is the DNS-based peer discovery mechanism mandatory to implement?
>>>>
>>>> The first paragraph of 5.2 speaks in terms of "supported" and if you
>>>> read that to mean "implemented" the answer is no, but after talking to
>>>> some folks I'm not sure that was the intent. Was the intent mandatory to
>>>> implement, optional to use?
>>> Good question.  The text in question uses the term "Diameter node",
>>> which is a computer actually running Diameter, so my take on it would be
>>> that the node might not support the option (in terms of actually using
>>> it)but that the option would nevertheless be available (i.e.,
>>> implemented).  It seems like the text could be clearer though -- any
>>> suggestions?
> It's not sufficient to rely on the underlying computer having DNS libraries.
> You specified DIAMETER specific logic - the person that wrote the
> diameter code
> is going to have to write code - it might _use_ a DNS library on an
> underlying
> OS, but it's the DIAMETER code that's going to have to provide the
> inputs to the
> NAPTR queries, (or SRV queries, if starting at that level), and follow
> the rules in
> this document on interpreting the results. _Thats_ the code that needs
> to be mandatory
> to implement.
>> How about:
>>
>>      ..
>>      discovery, the following mechanisms are described.  These are based
>>      on existing IETF standards.  The first option (manual configuration)
>>      MUST be implemented and supported by all Diameter nodes, while the
>>      latter option (DNS) MAY be implemented and MAY be supported  by
>>      Diameter nodes.
>>
>> However, we could also try to make DNS option more widely used, since
>> every box in practice has to have some level of DNS resolver capability:
>>
>>      ..
>>      MUST be implemented and supported by all Diameter nodes, while the
>>      latter option (DNS) SHOULD be implemented and if implemented MAY be
>>      used by Diameter nodes.
>>
>>
>> Opinions?
>>
>>
>> - Jouni
>>
>>
>>
>>>> That would ensure that an operator had the
>>>> option to start using the DNS-based discovery mechanism when it was the
>>>> right thing to do.
>>>>
>>>> RjS
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

From gwz@net-zen.net  Sat Mar 10 08:12:18 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D9421F85F2 for ; Sat, 10 Mar 2012 08:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.2
X-Spam-Level: 
X-Spam-Status: No, score=-101.2 tagged_above=-999 required=5 tests=[AWL=1.399,  BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqhdGyINLDXm for ; Sat, 10 Mar 2012 08:12:17 -0800 (PST)
Received: from p3plsmtpa06-08.prod.phx3.secureserver.net (p3plsmtpa06-08.prod.phx3.secureserver.net [173.201.192.109]) by ietfa.amsl.com (Postfix) with SMTP id 8D79E21F85F0 for ; Sat, 10 Mar 2012 08:12:17 -0800 (PST)
Received: (qmail 31563 invoked from network); 10 Mar 2012 16:12:17 -0000
Received: from unknown (124.120.132.29) by p3plsmtpa06-08.prod.phx3.secureserver.net (173.201.192.109) with ESMTP; 10 Mar 2012 16:12:16 -0000
Message-ID: <4F5B7D49.9060902@net-zen.net>
Date: Sat, 10 Mar 2012 23:11:53 +0700
From: Glen Zorn 
Organization: Network Zen
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Barry Leiba 
References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com> <4F5927D1.6020907@nostrum.com> <4F59AEF2.8040008@gmail.com> 
In-Reply-To: 
X-Enigmail-Version: 1.3.5
Content-Type: multipart/mixed; boundary="------------010800040607060303020204"
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, "dime@ietf.org" , The IESG 
Subject: Re: [Dime] Command Code syntax vs ABNF
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Mar 2012 16:12:18 -0000

This is a multi-part message in MIME format.
--------------010800040607060303020204
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 3/9/2012 8:49 PM, Barry Leiba wrote:
>>> That isn't ABNF, it's an expression in the command code grammar defined
>>> by the ABNF in section 3.2.
>>> An ABNF parser would reject it if you provided it as input. A diameter
>>> command code syntax parser would
>>> accept it.
> ...
>>> Would anyone object to changing the places where ABNF is misused to
>>> variants of "command code specification"?
>>
>> I would: there are at least 50 of those places in the draft and each
>> would require individualized wordsmithing.  If it really needs to be
>> changed, I would prefer to have an acronym with which I could just
>> globally replace "ABNF", saving hours of work.
> 
> Fair enough.  How about this suggestion, then?
> 
> 3588bis, section 3.2:
> OLD
>    Every Command Code defined MUST include a corresponding ABNF
>    specification, which is used to define the AVPs that MUST or MAY be
>    present when sending the message.  The following format is used in
>    the definition:
> NEW
>    Every Command Code defined MUST include a corresponding
>    Command Code Format (CCF) specification, which is used to define
>    the AVPs that MUST or MAY be present when sending the message.
>    The following ABNF specifies the CCF used in the definition:
> 
> Then you replace "ABNF" with "CCF":
> 
>>> For instance, the errant sentence in 4.4.1 would become "The Grouped
>>> Data field has the following command code specification". In section
>>> 6.6, "An ABNF for a request message" would be come "The command code
>>> specification for a request message". And so on.
> 
> Now that becomes this:
> 
> "The Grouped Data field has the following CCF grammar:"
> "The CCF for a request message"
> 
> It's a LITTLE more than just replacing "ABNF" with "CCF", because you
> may have to change "an" to "a" or "the", but it should be quite easy.
> (I suppose we could call it "Augmented Command Code Format", and get
> around even that.)  Any document that cites 3588bis can put CCF (with
> a citation) into its terminology section, and use "CCF" as well.
> 

Much Better, thanks!

> Barry
> 
> 

--------------010800040607060303020204
Content-Type: text/x-vcard; charset=utf-8;
 name="gwz.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="gwz.vcf"

begin:vcard
fn:Glen Zorn
n:Zorn;Glen
org:Network Zen
adr:;;;Seattle;WA;;USA
email;internet:gwz@net-zen.net
tel;cell:+66 87 040 4617
note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C  2EE1 6E17 B5F6 5953 B45F 
version:2.1
end:vcard


--------------010800040607060303020204--

From internet-drafts@ietf.org  Sat Mar 10 18:44:43 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ED321F8550; Sat, 10 Mar 2012 18:44:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EWTe2WqvDqB; Sat, 10 Mar 2012 18:44:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC4221F84F7; Sat, 10 Mar 2012 18:44:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120311024442.9458.81060.idtracker@ietfa.amsl.com>
Date: Sat, 10 Mar 2012 18:44:42 -0800
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-14.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 02:44:43 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Diameter Maintenance and Extensions W=
orking Group of the IETF.

	Title           : Diameter Network Address and Port Translation Control Ap=
plication
	Author(s)       : Frank Brockners
                          Shwetha Bhandari
                          Vaneeta Singh
                          Victor Fajardo
	Filename        : draft-ietf-dime-nat-control-14.txt
	Pages           : 60
	Date            : 2012-03-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 networks to cope with IPv4-address
   space depletion.  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-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-14.txt


From glenzorn@gmail.com  Sat Mar 10 23:07:27 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0B121F85EE; Sat, 10 Mar 2012 23:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Level: 
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=0.298,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmWuQsoqYWzf; Sat, 10 Mar 2012 23:07:26 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 793F121F85EA; Sat, 10 Mar 2012 23:07:26 -0800 (PST)
Received: by iazz13 with SMTP id z13so5361116iaz.31 for ; Sat, 10 Mar 2012 23:07:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C440LLcHZyO+WVdtZtUuZ/zhENPsiyvLUEYSfT4k2cg=; b=We4fbxCjxdmmKp+ecUnDO7CfqB2SePcopEcrnqzWQbETorjc9HWuKSW8TU8NxyzAOz yBnSG9MHA0TFFxmrds5YO4b2hVnaIghvVqX/cUt2FCJmFdf0HWHHxyIs8/qU8AznYgaz EyVKeRIY9rpyKcQB5aPZSDk0s0p0qbUpU32ghdc8y6cWuqytN1zLCjERw8X/BuNo994n RDNQLgxLxpMG/m9G6kecpRImS/OxXF9GCVLttaO4tde5MQTx6Wp+E3L/82mQbgSyj/aZ IlTXGwZKBx1U9P9uwujpbVSG93YDERFUuBXgbUXw9GUwhqgay8iHnTDqadzsE58mBlfS s++A==
Received: by 10.42.138.9 with SMTP id a9mr10295578icu.14.1331449646070; Sat, 10 Mar 2012 23:07:26 -0800 (PST)
Received: from [192.168.1.98] (ppp-124-120-28-217.revip2.asianet.co.th. [124.120.28.217]) by mx.google.com with ESMTPS id wp4sm4668471igc.3.2012.03.10.23.07.21 (version=SSLv3 cipher=OTHER); Sat, 10 Mar 2012 23:07:24 -0800 (PST)
Message-ID: <4F5C4F27.5020905@gmail.com>
Date: Sun, 11 Mar 2012 14:07:19 +0700
From: Glen Zorn 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Peter Saint-Andre 
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> <4F5A26A8.9090004@stpeter.im>
In-Reply-To: <4F5A26A8.9090004@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Jouni Korhonen , "dime@ietf.org" , The IESG 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 07:07:27 -0000

On 3/9/2012 10:50 PM, Peter Saint-Andre wrote:

...

>>>> My secondary concern was this:
>>>>
>>>>   Furthermore, this specification does not register the 'diameter'
>>>>   SRV Service value in accordance with RFC 6335. 

And yet, "diameter" already is shown in the IANA registry with SCTP, TCP
and UDP as protocols.

>>>>   Because these values
>>>>   were not defined or registered by draft-ietf-dime-extended-naptr, I
>>>>   think they need to be defined here.
>>>>
>>>> Please see Section 8.1 of RFC 6335 for the registration procedure:
>>>>
>>>> http://tools.ietf.org/html/rfc6335#section-8.1
>>>>
>>>> I think you can add this quite easily in a revised I-D before the
>>>> deadline on Monday, or your AD can add an RFC Editor note.
>>>
>>> OK, what to do about the port number, etc.?  Jouni, since you
>>> volunteered that we would do this, how about writing the section?
>>
>> That's ok.

Can this be done before the deadline Monday?

> 
> Thanks, Jouni. I think it should be easy, because RFC 6335 asks for:
> 
>       Service Name (REQUIRED)
>       Transport Protocol(s) (REQUIRED)
>       Assignee (REQUIRED)
>       Contact (REQUIRED)
>       Description (REQUIRED)
>       Reference (REQUIRED)
>       Port Number (OPTIONAL)
>       Service Code (REQUIRED for DCCP only)
>       Known Unauthorized Uses (OPTIONAL)
>       Assignment Notes (OPTIONAL)
> 


From glenzorn@gmail.com  Sat Mar 10 23:10:32 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709E521F85EE for ; Sat, 10 Mar 2012 23:10:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.012
X-Spam-Level: 
X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI7YQDVIQOdq for ; Sat, 10 Mar 2012 23:10:31 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7D7521F85AE for ; Sat, 10 Mar 2012 23:10:31 -0800 (PST)
Received: by iazz13 with SMTP id z13so5364954iaz.31 for ; Sat, 10 Mar 2012 23:10:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BB3UwwnKlyjZZgZtuzo3UVuKSokiJ76IKivlTWwjKwc=; b=eMicpJcBSwAkuATxvr5SpgcpqI/2R80rtAcPnG/QD9Cu3KbLgzOK4jQJdLgoKR+l6+ i/+PBTZOC3bSWsx+vm8skq9JtWYuvkZ9VdRUbuX1fHYRniW8YaBgFHFRNNVnKbXMNQ7X HcDqrf8U04SkXaY9DNywD+DvSyAFUeBK+UpuW47UyOD7mAVKG0C7RhH4/qIoBWIcEUtl o8UtDlcPgJVMkHtJFuhXKxQ1OTAqpAdoeizZ/kiedFOO4LrcMqWnhEAVZUPN6JvtYbKC ElhylY63eqv6RCVQ69kz0j+Umm6OnRX8CGQiedWAxt89litVszouDPx5+cNcdCpCfN8W wmMg==
Received: by 10.50.179.106 with SMTP id df10mr12545513igc.6.1331449831423; Sat, 10 Mar 2012 23:10:31 -0800 (PST)
Received: from [192.168.1.98] (ppp-124-120-28-217.revip2.asianet.co.th. [124.120.28.217]) by mx.google.com with ESMTPS id rd7sm4014642igb.14.2012.03.10.23.10.28 (version=SSLv3 cipher=OTHER); Sat, 10 Mar 2012 23:10:30 -0800 (PST)
Message-ID: <4F5C4FE2.2010804@gmail.com>
Date: Sun, 11 Mar 2012 14:10:26 +0700
From: Glen Zorn 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: lionel.morand@orange.com
References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> <4F5A1F8D.4010607@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 07:10:32 -0000

On 3/10/2012 12:12 AM, lionel.morand@orange.com wrote:
> What about:
> 
> "A Diameter implementation MUST include the first option (manual configuration) and MAY [or "SHOULD" if preferred] include the latter option (DNS)."
> 

I see know reason for this: we're talking about writing code here, not
forcing deployment of an option; by requiring implementations to include
DNS as running code we may make developers' lives a bit more stressful
but ease that of their customers.

> Lionel
> 
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Robert Sparks
> Envoyé : vendredi 9 mars 2012 16:20
> À : jouni korhonen
> Cc : dime@ietf.org
> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
> 
> 
> 
> On 3/9/12 2:17 AM, jouni korhonen wrote:
>> Hi,
>>
>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>>
>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>>> Question: Is the DNS-based peer discovery mechanism mandatory to implement?
>>>>
>>>> The first paragraph of 5.2 speaks in terms of "supported" and if you
>>>> read that to mean "implemented" the answer is no, but after talking to
>>>> some folks I'm not sure that was the intent. Was the intent mandatory to
>>>> implement, optional to use?
>>> Good question.  The text in question uses the term "Diameter node",
>>> which is a computer actually running Diameter, so my take on it would be
>>> that the node might not support the option (in terms of actually using
>>> it)but that the option would nevertheless be available (i.e.,
>>> implemented).  It seems like the text could be clearer though -- any
>>> suggestions?
> 
> It's not sufficient to rely on the underlying computer having DNS libraries.
> You specified DIAMETER specific logic - the person that wrote the 
> diameter code
> is going to have to write code - it might _use_ a DNS library on an 
> underlying
> OS, but it's the DIAMETER code that's going to have to provide the 
> inputs to the
> NAPTR queries, (or SRV queries, if starting at that level), and follow 
> the rules in
> this document on interpreting the results. _Thats_ the code that needs 
> to be mandatory
> to implement.
>> How about:
>>
>>     ..
>>     discovery, the following mechanisms are described.  These are based
>>     on existing IETF standards.  The first option (manual configuration)
>>     MUST be implemented and supported by all Diameter nodes, while the
>>     latter option (DNS) MAY be implemented and MAY be supported  by
>>     Diameter nodes.
>>
>> However, we could also try to make DNS option more widely used, since
>> every box in practice has to have some level of DNS resolver capability:
>>
>>     ..
>>     MUST be implemented and supported by all Diameter nodes, while the
>>     latter option (DNS) SHOULD be implemented and if implemented MAY be
>>     used by Diameter nodes.
>>
>>
>> Opinions?
>>
>>
>> - Jouni
>>
>>
>>
>>>> That would ensure that an operator had the
>>>> option to start using the DNS-based discovery mechanism when it was the
>>>> right thing to do.
>>>>
>>>> RjS
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From glenzorn@gmail.com  Sun Mar 11 00:17:23 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81F721F85F8; Sun, 11 Mar 2012 00:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.311
X-Spam-Level: 
X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=0.288,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bERsPDQzcdyA; Sun, 11 Mar 2012 00:17:23 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB61B21F8584; Sun, 11 Mar 2012 00:16:57 -0800 (PST)
Received: by iazz13 with SMTP id z13so5439836iaz.31 for ; Sun, 11 Mar 2012 00:16:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mPP3N9CL4QWhIWQs1DxCZPTissWpjnwTcFmhjNlBo7o=; b=D/z8V1gVnSYuhYT4s83X//oY3NHnEsVrEPZnXLEl2Wr1XANvBOXratp2CBQoV+LN0b /7h+K7jSIHtypjnVBDxcSSeSF3WPZyN6GNPvy5CExLOmdM6O4dAYzKXbiU+4ZpIgcw0E IS2psmpfZiN5mUWnVVJCztTOpqN73LiTCuh7LnW0ewaUesk93fHmhA+lCRe1GQ/995f+ rBMgjf9clkNbUw8VvjX7+0dicXItGvq9Jms/ujIgG6YdlACv/iC4tcGErM7mq4/BPKzu AbSTZSaRLmdqbqXBLe1nTFF6Jt8IX7MNqtFQc/w+gQT4HubwguGmkJis6jGz8kD3NBYh 80pQ==
Received: by 10.50.51.169 with SMTP id l9mr12981519igo.4.1331453817140; Sun, 11 Mar 2012 00:16:57 -0800 (PST)
Received: from [192.168.1.98] (ppp-124-120-28-217.revip2.asianet.co.th. [124.120.28.217]) by mx.google.com with ESMTPS id vw3sm6178213igb.9.2012.03.11.00.16.52 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 00:16:55 -0800 (PST)
Message-ID: <4F5C5F72.8060106@gmail.com>
Date: Sun, 11 Mar 2012 15:16:50 +0700
From: Glen Zorn 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Glen Zorn 
References: <20110920211706.1986.88800.idtracker@ietfa.amsl.com> <4F571650.5010103@gmail.com> <4F57BF79.7060403@nostrum.com> <4F5820EC.5080907@net-zen.net> <4F5921D1.4030804@nostrum.com>  <4F5990F2.1080807@net-zen.net>  <4F59EA98.8060106@net-zen.net>
In-Reply-To: <4F59EA98.8060106@net-zen.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, dime-chairs@tools.ietf.org, The IESG 
Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 08:17:24 -0000

On 3/9/2012 6:33 PM, Glen Zorn wrote:

> On 3/9/2012 3:49 PM, jouni korhonen wrote:
>>
>> Glen, Robert, WG,
>>
>> On Mar 9, 2012, at 7:11 AM, Glen Zorn wrote:
>>
>>> On 3/9/2012 5:26 AM, Jouni wrote:
>>>>
>>>> Robert,
>>>>
>>>> On Mar 8, 2012, at 11:17 PM, Robert Sparks wrote:
>>>>
>>>>>
>>>>>
>>>>> On 3/7/12 9:01 PM, Glen Zorn wrote:
>>>>>> On 3/8/2012 3:05 AM, Robert Sparks wrote:
>>>>>>> Thanks for the response Glen
>>>>>>>
>>>>>>> Discussion inline.
>>>>>>>
>>>>>> ...
>>>>>>
>>>>>>>>> This sentence in section 2.1 is not clear:
>>>>>>>>>   For TLS [RFC5246] and DTLS [RFC4347], a Diameter
>>>>>>>>>   node that initiate a connection prior to any message exchanges MUST
>>>>>>>>>   run on port [TBD].
>>>>>>>>> What was its intent? It could be misread to say that you cannot establish
>>>>>>>>> a connection on any other port than [TBD].
>>>>>>>> I'm not sure that that would be a mis-reading.
>>>>>>> If that's the case, consider saying "run only on port". But doesn't that
>>>>>>> interact badly
>>>>>>> with the peer discovery mechanism? Or are you saying it would be an
>>>>>>> error to create
>>>>>>> an SRV record that pointed to any port other than TBD?
>>>>>> Actually, I'm just not sure (I didn't write this part ;-).  I'm hoping
>>>>>> that somebody else will chime in...
>>>>> Who should be responding?
>>>>>
>>>>> I think the right thing to do here is to change the MUST above to "by default" and note that
>>>>> the SRV-based peer discovery mechanism may specify other ports.
>>>>
>>>> It actually looks fuzzy.. "run on port" intends to say that a Diameter node
>>>> must at least bind its listening socket to port [TBD]. When creating a connection
>>>> the source port can be other than [TBD] but should be the same [TBD]..
>>>>
>>>> The wording does not actually allow listening for incoming connections on
>>>> other ports that 3868 and [TBD], which effectively puts a restriction on
>>>> the use of SRV.
>>>
>>> OK, so how to change it?
>>
>> I looked back to old archives back to early 2000 and there John Loughney
>> said that NAPTR was introduced to allow flexibility on TLS ports i.e. not
>> only rely on fixed port numbers. So we probably then should make it clear
>> a DNS based peer discovery can override default ports. How about:
>>
>>    ...
>>
>>    The base Diameter protocol is run (i.e., listens for incoming connections)
>>    on port 3868 for both TCP [RFC793] and SCTP [RFC4960]. It is assumed that
>>    TLS [RFC5246] is run on top of TCP when it is used and DTLS [RFC6347] is
>>    run on top of SCTP when it is used.
>>
>>    If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
>>    connections on port [TBD], i.e. the peer complies only with
>>    [RFC3588], then the initiator MAY revert to using TCP or SCTP and on
>>    port 3868.  Note that this scheme is kept for the purpose of
>>    backwards compatibility only and that there are inherent security
>>    vulnerabilities when the initial CER/CEA messages are sent un-
>>    protected (see Section 5.6).
>>
>>    Diameter clients MUST support either TCP or SCTP, while agents and
>>    servers SHOULD support both.
>>
>>    A Diameter node MAY initiate connections from a source port other
>>    than the one that it declares it accepts incoming connections on, and
>>    MUST always be prepared to receive connections on port 3868 for TCP or
>>    SCTP and port [TBD] for TLS/TCP and DTLS/SCTP connections. When DNS-based
>>    peer discovery is used, the port numbers received from SRV records
>>    take precedence over default ports 3868 and [TBD].
>>
>>
>> Comments?
> 
> Fine with me.

This is what I have now:

OLD:
2.1.  Transport

   The Diameter Transport profile is defined in [RFC3539].

   The base Diameter protocol is run on port 3868 for both TCP [RFC793]
   and SCTP [RFC4960].  For TLS [RFC5246] and DTLS [RFC6347], a Diameter
   node that initiate a connection prior to any message exchanges MUST
   run on port [TBD].  It is assumed that TLS is run on top of TCP when
   it is used and DTLS is run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port [TBD], i.e. the peer complies only with
   [RFC3588], then the initiator MAY revert to using TCP or SCTP and on
   port 3868.  Note that this scheme is kept for the purpose of
   backwards compatibility only and that there are inherent security
   vulnerabilities when the initial CER/CEA messages are sent un-
   protected (see Section 5.6).

   Diameter clients MUST support either TCP or SCTP, while agents and
   servers SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   MUST be prepared to receive connections on port 3868 for TCP or SCTP
   and port [TBD] for TLS/TCP and DTLS/SCTP connections.  A given
   Diameter instance of the peer state machine MUST NOT use more than
   one transport connection to communicate with a given peer, unless
   multiple instances exist on the peer in which case a separate
   connection per process is allowed.

NEW:
2.1.  Transport

   The Diameter Transport profile is defined in [RFC3539].

   The base Diameter protocol is run on port 3868 for both TCP [RFC793]
   and SCTP [RFC4960].  For TLS [RFC5246] and DTLS [RFC6347], a Diameter
   node that initiate a connection prior to any message exchanges MUST
   run on port [TBD].  It is assumed that TLS is run on top of TCP when
   it is used and DTLS is run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port [TBD] (i.e., the peer complies only with
   [RFC3588]), then the initiator MAY revert to using TCP or SCTP on
   port 3868.  Note that this scheme is kept only for the purpose of
   backward compatibility and that there are inherent security
   vulnerabilities when the initial CER/CEA messages are sent
   unprotected (see Section 5.6).

   Diameter clients MUST support either TCP or SCTP; agents and servers
   SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   MUST always be prepared to receive connections on port 3868 for TCP
   or SCTP and port [TBD] for TLS/TCP and DTLS/SCTP connections.  When
   DNS-based peer discovery (Section 5.2) is used, the port numbers
   received from SRV records take precedence over the default ports
   (3868 and [TBD]).

   A given Diameter instance of the peer state machine MUST NOT use more
   than one transport connection to communicate with a given peer,
   unless multiple instances exist on the peer in which case a separate
   connection per process is allowed.
> 
> ...
> 
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Sun Mar 11 01:59:18 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46BF21F84DC; Sun, 11 Mar 2012 01:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.444
X-Spam-Level: 
X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzAimehMueCc; Sun, 11 Mar 2012 01:59:18 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEA221F84B9; Sun, 11 Mar 2012 01:59:17 -0800 (PST)
Received: by lagj5 with SMTP id j5so3368456lag.31 for ; Sun, 11 Mar 2012 01:59:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yGEAuQ/W8jJ1z8oBe0hIqlRAA+HdNlnjfH6C7q9AVGM=; b=FNzreV6wKXuViv+PnOS2LtOHDvPXY9IKPWCmjajCVpV3rePr/v647pN+xGJjN1IJdy 5yFsuzTPiy+asRkBAv6NwSeAIflWfuO3bsn8AsaDg3AzWmmDsiwiAMph+GJUijRM0y/c hROY7zK9UeVAsEUQkXMCKTbaBz6dl7/Lcvi0diMhBhBDJRPxsVX4xWuYI6LmzbmXQhE4 CCjq4ANqoFsGnPVDSq03iaWFySgXFaL4Mw0CIaTSxo4+skF1QSctT5GvivJ3WcaHzy0s 1HZ3GLM1mv4iAYgAGt/TVlx+SuXs3/Stwp/ceuBfScWw/+VVDEWgUBIEEdn/1vet3lZx ukJg==
Received: by 10.152.114.35 with SMTP id jd3mr6286588lab.18.1331459956142; Sun, 11 Mar 2012 01:59:16 -0800 (PST)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id u4sm1481845lad.5.2012.03.11.01.59.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 01:59:15 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <4F5C4F27.5020905@gmail.com>
Date: Sun, 11 Mar 2012 11:59:12 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> <4F5A26A8.9090004@stpeter.im> <4F5C4F27.5020905@gmail.com>
To: Glen Zorn 
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Jouni Korhonen , "dime@ietf.org" , The IESG , Peter Saint-Andre 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 09:59:19 -0000

On Mar 11, 2012, at 9:07 AM, Glen Zorn wrote:

> On 3/9/2012 10:50 PM, Peter Saint-Andre wrote:
> 
> ...
> 
>>>>> My secondary concern was this:
>>>>> 
>>>>>  Furthermore, this specification does not register the 'diameter'
>>>>>  SRV Service value in accordance with RFC 6335. 
> 
> And yet, "diameter" already is shown in the IANA registry with SCTP, TCP
> and UDP as protocols.
> 
>>>>>  Because these values
>>>>>  were not defined or registered by draft-ietf-dime-extended-naptr, I
>>>>>  think they need to be defined here.
>>>>> 
>>>>> Please see Section 8.1 of RFC 6335 for the registration procedure:
>>>>> 
>>>>> http://tools.ietf.org/html/rfc6335#section-8.1
>>>>> 
>>>>> I think you can add this quite easily in a revised I-D before the
>>>>> deadline on Monday, or your AD can add an RFC Editor note.
>>>> 
>>>> OK, what to do about the port number, etc.?  Jouni, since you
>>>> volunteered that we would do this, how about writing the section?
>>> 
>>> That's ok.
> 
> Can this be done before the deadline Monday?

I try to get this done tonight.

- Jouni


> 
>> 
>> Thanks, Jouni. I think it should be easy, because RFC 6335 asks for:
>> 
>>      Service Name (REQUIRED)
>>      Transport Protocol(s) (REQUIRED)
>>      Assignee (REQUIRED)
>>      Contact (REQUIRED)
>>      Description (REQUIRED)
>>      Reference (REQUIRED)
>>      Port Number (OPTIONAL)
>>      Service Code (REQUIRED for DCCP only)
>>      Known Unauthorized Uses (OPTIONAL)
>>      Assignment Notes (OPTIONAL)
>> 
> 


From internet-drafts@ietf.org  Sun Mar 11 04:10:58 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDDA21F85C5; Sun, 11 Mar 2012 04:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Level: 
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IawkmMvoBhl5; Sun, 11 Mar 2012 04:10:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D96C21F847A; Sun, 11 Mar 2012 04:10:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120311111058.20459.60004.idtracker@ietfa.amsl.com>
Date: Sun, 11 Mar 2012 04:10:58 -0700
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-rfc3588bis-31.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 11:10:58 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Diameter Maintenance and Extensions W=
orking Group of the IETF.

	Title           : Diameter Base Protocol
	Author(s)       : Victor Fajardo
                          Jari Arkko
                          John Loughney
                          Glen Zorn
	Filename        : draft-ietf-dime-rfc3588bis-31.txt
	Pages           : 153
	Date            : 2012-03-11

   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
   obsoletes RFC 3588 and RFC 5719 and must be supported by all new
   Diameter implementations.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-31.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-31.txt


From glenzorn@gmail.com  Sun Mar 11 04:15:42 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB15921F8549; Sun, 11 Mar 2012 04:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Level: 
X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.278,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWZWJG5IhBuU; Sun, 11 Mar 2012 04:15:42 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 204FE21F8542; Sun, 11 Mar 2012 04:15:42 -0700 (PDT)
Received: by iazz13 with SMTP id z13so5652392iaz.31 for ; Sun, 11 Mar 2012 04:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6gWGbSoyvNPaKvlRVpw/pL3mIY/HRgp5Hgksm8Kcl6M=; b=aJqKDH6z1Ty+jxdPNDQo7fz4BujlSsmR9EVVSOs0yAZ/EdfxZMldDEvLLlJBaUa3Lc PkXPn8NYkUgD5BzqBSvgx263OP8UWLlp9lwHl0hgebBdHg86lIpNqxdszlDOVW/ieikQ /3A0SzamIMnmGt3w7ySA0Ao+4IuV5gAJ1J0DYDb7GB/NJd7hB4bbT3RxKqVuvukcoRMj qb6jroRURFnLx+k8VM4rzaLqP0ecBLvEEN/iL5MuItZ+xmGGnCrzZEjtRm86aqpdiAgX scgvRRD6S2Nc0b0AptVaOQjzqUSd7B/d/2CDMTsoyp/ac2CdpZhuPlpVimGdGg74uj+P xdQQ==
Received: by 10.50.194.163 with SMTP id hx3mr13490098igc.49.1331464541682; Sun, 11 Mar 2012 04:15:41 -0700 (PDT)
Received: from [192.168.1.98] (ppp-124-120-28-217.revip2.asianet.co.th. [124.120.28.217]) by mx.google.com with ESMTPS id b11sm8695153igq.7.2012.03.11.04.15.34 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 04:15:40 -0700 (PDT)
Message-ID: <4F5C8951.4040503@gmail.com>
Date: Sun, 11 Mar 2012 18:15:29 +0700
From: Glen Zorn 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: jouni korhonen 
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> <4F5A26A8.9090004@stpeter.im> <4F5C4F27.5020905@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Jouni Korhonen , "dime@ietf.org" , The IESG , Peter Saint-Andre 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 11:15:42 -0000

On 3/11/2012 4:59 PM, jouni korhonen wrote:

...

>>>>> OK, what to do about the port number, etc.?  Jouni, since you
>>>>> volunteered that we would do this, how about writing the section?
>>>>
>>>> That's ok.
>>
>> Can this be done before the deadline Monday?
> 
> I try to get this done tonight.

Never mind, I gave it a shot myself; but please take a look at
http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-31#section-11.4 to
see if I got it right :-).

...

From jouni.nospam@gmail.com  Sun Mar 11 05:15:39 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FE121F864D; Sun, 11 Mar 2012 05:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.457
X-Spam-Level: 
X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGcs5oIVtl6J; Sun, 11 Mar 2012 05:15:39 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75B4521F85A2; Sun, 11 Mar 2012 05:15:38 -0700 (PDT)
Received: by lagj5 with SMTP id j5so3414983lag.31 for ; Sun, 11 Mar 2012 05:15:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JVM8sZkpx+SGbjLd1ir6eyGY8WrxGuZheaVijSY6iG8=; b=B7EPu1uu5Vhg9V8Lwc2hK0utdGu4iLhrpVZq2S8mNjGeJouwdFr3uoCaHDfI8jQGnj GrYbPLHpdrC8SKsegnWYJXS/IMtAtVQODbU+EhDg649OC/swrqxLhKRfHCHLZq0kdlsp MSXKJbD0VkeChjqgP91wETJ9BOcOvhyhE/jxHpg31OORoQGFpgOvY2UVBtwxPhB4M9bO 40/EsTYZZZowkngKIF33D0XOc9nLZtIXO+YtzbrzkQfeugqUjSD1RPQAUmesW9NGbkQw XV9/RyVIkf++IIpuHxMBRaxO1JyjSyKwbmM3jCQ5f4eczJKY/kScYPsh58PqRTf/qqNs BDuA==
Received: by 10.152.105.241 with SMTP id gp17mr7150397lab.21.1331468137496; Sun, 11 Mar 2012 05:15:37 -0700 (PDT)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id v4sm14181151lbx.13.2012.03.11.05.15.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 05:15:36 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <4F5C8951.4040503@gmail.com>
Date: Sun, 11 Mar 2012 14:15:34 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <737722A5-9078-4890-9F9F-7FA93ADB85A5@gmail.com>
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> <4F5A26A8.9090004@stpeter.im> <4F5C4F27.5020905@gmail.com>  <4F5C8951.4040503@gmail.com>
To: Glen Zorn 
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Jouni Korhonen , "dime@ietf.org" , The IESG , Peter Saint-Andre 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 12:15:39 -0000

Hi,

On Mar 11, 2012, at 1:15 PM, Glen Zorn wrote:

> On 3/11/2012 4:59 PM, jouni korhonen wrote:
> 
> ...
> 
>>>>>> OK, what to do about the port number, etc.?  Jouni, since you
>>>>>> volunteered that we would do this, how about writing the section?
>>>>> 
>>>>> That's ok.
>>> 
>>> Can this be done before the deadline Monday?
>> 
>> I try to get this done tonight.
> 
> Never mind, I gave it a shot myself; but please take a look at

Thanks :)

> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-31#section-11.4 to
> see if I got it right :-).

Don't we also need an entry for "_diameters"?

The Port  Number should probably be "TBD, from the User Ports".

Not sure about IESG and IETF chair as assignees and contact point.. Since
User Ports are assigned by IANA maybe we could put IANA as the contact
and the assignee ? Don't have a preference though :)

Otherwise looked ok to me.

- Jouni



> 
> ...


From stpeter@stpeter.im  Fri Mar  9 07:50:03 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE8E21F8642; Fri,  9 Mar 2012 07:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.733
X-Spam-Level: 
X-Spam-Status: No, score=-102.733 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0xCIcRdsvID; Fri,  9 Mar 2012 07:50:03 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E158421F84DF; Fri,  9 Mar 2012 07:50:02 -0800 (PST)
Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C31E84005B; Fri,  9 Mar 2012 09:02:07 -0700 (MST)
Message-ID: <4F5A26A8.9090004@stpeter.im>
Date: Fri, 09 Mar 2012 08:50:00 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: jouni korhonen 
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com>
In-Reply-To: <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com>
X-Enigmail-Version: 1.3.5
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 11 Mar 2012 08:25:29 -0700
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Jouni Korhonen , "dime@ietf.org" , The IESG 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 09 Mar 2012 15:50:04 -0000

On 3/9/12 1:35 AM, jouni korhonen wrote:
> 
> On Mar 9, 2012, at 10:34 AM, Glen Zorn wrote:
> 
>> On 3/8/2012 10:48 PM, Peter Saint-Andre wrote:
>>> On 3/8/12 8:27 AM, Jouni Korhonen wrote:
>>>> Peter,
>>>>
>>>> The text in recently submitted -30 Section 5.2 (
>>>> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-30#section-5.2) should
>>>> also address your DISCUSS.
>>>
>>> Thanks for the pointer to a specific section.
>>>
>>> That change does address my primary concern, which was:
>>>
>>>   RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV
>>>   Service of 'diameter'. 3588bis seems to add two more Proto values:
>>>   'tls' and 'dtls'.  However, RFC 6335, which defines updated rules
>>>   for the ports and services registry, allows only TCP, UDP, SCTP,
>>>   and DCCP as transport protocols.
>>>
>>> My secondary concern was this:
>>>
>>>   Furthermore, this specification does not register the 'diameter'
>>>   SRV Service value in accordance with RFC 6335. Because these values
>>>   were not defined or registered by draft-ietf-dime-extended-naptr, I
>>>   think they need to be defined here.
>>>
>>> Please see Section 8.1 of RFC 6335 for the registration procedure:
>>>
>>> http://tools.ietf.org/html/rfc6335#section-8.1
>>>
>>> I think you can add this quite easily in a revised I-D before the
>>> deadline on Monday, or your AD can add an RFC Editor note.
>>
>> OK, what to do about the port number, etc.?  Jouni, since you
>> volunteered that we would do this, how about writing the section?
> 
> That's ok.

Thanks, Jouni. I think it should be easy, because RFC 6335 asks for:

      Service Name (REQUIRED)
      Transport Protocol(s) (REQUIRED)
      Assignee (REQUIRED)
      Contact (REQUIRED)
      Description (REQUIRED)
      Reference (REQUIRED)
      Port Number (OPTIONAL)
      Service Code (REQUIRED for DCCP only)
      Known Unauthorized Uses (OPTIONAL)
      Assignment Notes (OPTIONAL)


From jouni.nospam@gmail.com  Sun Mar 11 11:58:07 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCC021F864D; Sun, 11 Mar 2012 11:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level: 
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyBZaJz4n075; Sun, 11 Mar 2012 11:58:06 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59A4321F8568; Sun, 11 Mar 2012 11:58:06 -0700 (PDT)
Received: by lbol12 with SMTP id l12so882748lbo.31 for ; Sun, 11 Mar 2012 11:58:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1WJYANczzF82S/FIWD6lhxVxs4EpputCK5J43maz4a8=; b=j9Sb/ynEHrE5gyjukeFZBD03ZNg8i/NlRT/3j80JLepcI5jTKpFAO0gycrlaq6MERp MN2MWmfb4Ilu/j+j68GU926sDrGgOiwImY5h6y99s5hJXFnz7loRuVxRcF+Ajdx4dk91 kvnbXJebC2JoHRd2l3zurUnwflKTqmd6rRsx9kcLEyU30WZ4FeJwDVdHJpc+YXILXBlF vFFUUmvCYgwFcAlBileqLT+E8WdBMPnn5T0uiDF5+XaR0Y41wGLhjVPKCiNqPGPM9fKD VAiGIFV3Mrs20lb4wrxmjFyzdxu2nuC5nOnBnMcgbz5EXyMFQM7mTV6ppAF7MJTt5kPZ rNYg==
Received: by 10.112.84.195 with SMTP id b3mr3609322lbz.107.1331492285307; Sun, 11 Mar 2012 11:58:05 -0700 (PDT)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id f2sm15328994lbw.5.2012.03.11.11.58.02 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 11:58:04 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <737722A5-9078-4890-9F9F-7FA93ADB85A5@gmail.com>
Date: Sun, 11 Mar 2012 20:58:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> <4F5A26A8.9090004@stpeter.im> <4F5C4F27.5020905@gmail.com>  <4F5C8951.4040503@gmail.com> <737722A5-9078-4890-9F9F-7FA93ADB85A5@gmail.com>
To: Glen Zorn , Peter Saint-Andre 
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, dime-chairs@tools.ietf.org, The IESG 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 18:58:07 -0000

>=20
> Don't we also need an entry for "_diameters"?
>=20
> The Port  Number should probably be "TBD, from the User Ports".
>=20
> Not sure about IESG and IETF chair as assignees and contact point.. =
Since
> User Ports are assigned by IANA maybe we could put IANA as the contact
> and the assignee ? Don't have a preference though :)

Ok. Some foofoo stated by me here regarding the contacts ;)

This would be the registry entry with corrected service name and missing =
UDP protocol:

11.4.  "diameters" Service Name and Port Number Registration

   This section requests the IANA to register the "diameters" service
   name and assign port numbers for TLS/TCP and DTLS/SCTP according to
   the guidelines given in Cotton, et al.  [RFC6335].
  =20
      Service Name:         diameters
      Transport Protocols:  TCP, SCTP, UDP (reserved)
      Assignee:             IESG 
      Contact:              IETF Chair 
      Description:          Diameter over TLS/TCP and DTLS/SCTP
      Reference:            draft-ietf-dime-rfc3588bis
      Port  Number:         TBD, from the User Ports range

- Jouni

>=20
> Otherwise looked ok to me.
>=20
> - Jouni
>=20
>=20
>=20
>>=20
>> ...
>=20


From jouni.nospam@gmail.com  Sun Mar 11 13:04:48 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4831421F85A4 for ; Sun, 11 Mar 2012 13:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.178
X-Spam-Level: 
X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU5Z9D7P1hPW for ; Sun, 11 Mar 2012 13:04:47 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEC7121F85A3 for ; Sun, 11 Mar 2012 13:04:46 -0700 (PDT)
Received: by lbol12 with SMTP id l12so894499lbo.31 for ; Sun, 11 Mar 2012 13:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nky2JJ6IR/SvGGa/UtKcyPu++FQ3VeWJNoUFQ+Futw0=; b=TZX767vl6UGiVDfszlQGF3PKNz5otemj3c/HBa/h7XCWpoWobEARIvF7kgOPZPMe4V LAFO1YcDHHqBY0laRD1psFcQXRnnQXLiN7IQVCgPlyRXNaO+Vf3LLr/0V2S0U1iNbHC1 fLIGnTtNPeo2RaK94obYKVMdzU34QPldm07hUnkymxTA/48MkenAoGPrZ7MmijAG6lJl AkNf20m/nKIG+ak1gDpr4sqKyFOGp3X8Wht+qUdETuFDcxqRP2wW7RckJXDB1kmpEJ2N 2OxYgmTds8W5oDHHDIHCPjtkEp+eh5tIW5o/gkwe2TjibhleD1uPMnjnJPLaSA6CZVC7 JOPA==
Received: by 10.112.48.74 with SMTP id j10mr3687732lbn.106.1331496285856; Sun, 11 Mar 2012 13:04:45 -0700 (PDT)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id f2sm15513638lbw.5.2012.03.11.13.04.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 13:04:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: jouni korhonen 
In-Reply-To: <4F5A5158.90402@nostrum.com>
Date: Sun, 11 Mar 2012 22:04:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> <4F5A1F8D.4010607@nostrum.com>  <4F5A5158.90402@nostrum.com>
To: Robert Sparks 
X-Mailer: Apple Mail (2.1084)
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Mar 2012 20:04:48 -0000

Hi,

On Mar 9, 2012, at 8:52 PM, Robert Sparks wrote:

> I think we must be talking past each other. That suggestion doesn't =
look different than what's in -30, and
> doesn't address the point I made in the message you responded to.
>=20
> Let me try this a different way. The text in -30 and the text you =
propose below say that it's OK for
> an operator to have deployed a "conformant" diameter implementation =
and later discover that he
> can't use the DNS-based peer discovery mechanism without acquiring =
another one (or going back to
> the original provider for a code change). Is that really what the =
group concluded? That would surprise me,

Vendors can always build a nice licensing scheme around this ;-)

I could be OK with "MUST implement, MAY use" for DNS-based peer =
discovery
if that is what WG wants. The issue I have in general with "MUST" in =
current
DNS-based peer discovery is its limited usability in deployments. A peer =
does
(S-)NAPTR/SRV query for another domain (realm) and finds an address etc =
of
its node representing the entire realm. However, this does not help me =
if
there are intermediates that my requests must go through e.g. before =
leaving
my own realm. It then ends up only specific type of nodes (like edge =
agents
of some administrative domain) even needing DNS functionality for =
DNS-based
dynamic peer discovery.

Anyway, as said, I am mostly open for anything.


> and I'd like to read the discussion so I can see how the group landed =
there.
>=20
> I could see a decision that would say that manual configuration still =
needs to be an option available to the operator.

Yes. Manual is must.

- Jouni

>=20
> RjS
>=20
> On 3/9/12 11:12 AM, lionel.morand@orange.com wrote:
>> What about:
>>=20
>> "A Diameter implementation MUST include the first option (manual =
configuration) and MAY [or "SHOULD" if preferred] include the latter =
option (DNS)."
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part =
de Robert Sparks
>> Envoy=E9 : vendredi 9 mars 2012 16:20
>> =C0 : jouni korhonen
>> Cc : dime@ietf.org
>> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory =
toimplement?
>>=20
>>=20
>>=20
>> On 3/9/12 2:17 AM, jouni korhonen wrote:
>>> Hi,
>>>=20
>>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>>>=20
>>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>>>> Question: Is the DNS-based peer discovery mechanism mandatory to =
implement?
>>>>>=20
>>>>> The first paragraph of 5.2 speaks in terms of "supported" and if =
you
>>>>> read that to mean "implemented" the answer is no, but after =
talking to
>>>>> some folks I'm not sure that was the intent. Was the intent =
mandatory to
>>>>> implement, optional to use?
>>>> Good question.  The text in question uses the term "Diameter node",
>>>> which is a computer actually running Diameter, so my take on it =
would be
>>>> that the node might not support the option (in terms of actually =
using
>>>> it)but that the option would nevertheless be available (i.e.,
>>>> implemented).  It seems like the text could be clearer though -- =
any
>>>> suggestions?
>> It's not sufficient to rely on the underlying computer having DNS =
libraries.
>> You specified DIAMETER specific logic - the person that wrote the
>> diameter code
>> is going to have to write code - it might _use_ a DNS library on an
>> underlying
>> OS, but it's the DIAMETER code that's going to have to provide the
>> inputs to the
>> NAPTR queries, (or SRV queries, if starting at that level), and =
follow
>> the rules in
>> this document on interpreting the results. _Thats_ the code that =
needs
>> to be mandatory
>> to implement.
>>> How about:
>>>=20
>>>     ..
>>>     discovery, the following mechanisms are described.  These are =
based
>>>     on existing IETF standards.  The first option (manual =
configuration)
>>>     MUST be implemented and supported by all Diameter nodes, while =
the
>>>     latter option (DNS) MAY be implemented and MAY be supported  by
>>>     Diameter nodes.
>>>=20
>>> However, we could also try to make DNS option more widely used, =
since
>>> every box in practice has to have some level of DNS resolver =
capability:
>>>=20
>>>     ..
>>>     MUST be implemented and supported by all Diameter nodes, while =
the
>>>     latter option (DNS) SHOULD be implemented and if implemented MAY =
be
>>>     used by Diameter nodes.
>>>=20
>>>=20
>>> Opinions?
>>>=20
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>=20
>>>>> That would ensure that an operator had the
>>>>> option to start using the DNS-based discovery mechanism when it =
was the
>>>>> right thing to do.
>>>>>=20
>>>>> RjS
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime


From lionel.morand@orange.com  Mon Mar 12 01:29:05 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F64221F856A for ; Mon, 12 Mar 2012 01:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.778
X-Spam-Level: 
X-Spam-Status: No, score=-5.778 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA1mzXYXexdC for ; Mon, 12 Mar 2012 01:29:04 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id D288F21F8528 for ; Mon, 12 Mar 2012 01:29:03 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 95049E302E3; Mon, 12 Mar 2012 09:30:16 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8D6E1E302B6; Mon, 12 Mar 2012 09:30:16 +0100 (CET)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Mar 2012 09:29:02 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Mar 2012 09:29:01 +0100
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
Thread-Index: Acz/wjXuvDgp0ZCnR2Gkd1OqHKptZQAZ4bsw
References: <4F591045.6010601@nostrum.com> <4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com> <4F5A1F8D.4010607@nostrum.com>  <4F5A5158.90402@nostrum.com> 
From: 
To: , 
X-OriginalArrivalTime: 12 Mar 2012 08:29:02.0326 (UTC) FILETIME=[2DF4D960:01CD002A]
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2012 08:29:05 -0000

Hi,

I could also agree on the "MUST implement/MAY use" but would it mean =
that existing Diameter implementations that do not provide DNS-based =
discovery mechanism would be not anymore compliant with the Base =
protocol and would have to be upgraded?

Regards,

Lionel

-----Message d'origine-----
De=A0: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
Envoy=E9=A0: dimanche 11 mars 2012 21:05
=C0=A0: Robert Sparks
Cc=A0: MORAND Lionel RD-CORE-ISS; dime@ietf.org
Objet=A0: Re: [Dime] Is DNS-based diameter peer discovery mandatory =
toimplement?

Hi,

On Mar 9, 2012, at 8:52 PM, Robert Sparks wrote:

> I think we must be talking past each other. That suggestion doesn't =
look different than what's in -30, and
> doesn't address the point I made in the message you responded to.
>=20
> Let me try this a different way. The text in -30 and the text you =
propose below say that it's OK for
> an operator to have deployed a "conformant" diameter implementation =
and later discover that he
> can't use the DNS-based peer discovery mechanism without acquiring =
another one (or going back to
> the original provider for a code change). Is that really what the =
group concluded? That would surprise me,

Vendors can always build a nice licensing scheme around this ;-)

I could be OK with "MUST implement, MAY use" for DNS-based peer =
discovery
if that is what WG wants. The issue I have in general with "MUST" in =
current
DNS-based peer discovery is its limited usability in deployments. A peer =
does
(S-)NAPTR/SRV query for another domain (realm) and finds an address etc =
of
its node representing the entire realm. However, this does not help me =
if
there are intermediates that my requests must go through e.g. before =
leaving
my own realm. It then ends up only specific type of nodes (like edge =
agents
of some administrative domain) even needing DNS functionality for =
DNS-based
dynamic peer discovery.

Anyway, as said, I am mostly open for anything.


> and I'd like to read the discussion so I can see how the group landed =
there.
>=20
> I could see a decision that would say that manual configuration still =
needs to be an option available to the operator.

Yes. Manual is must.

- Jouni

>=20
> RjS
>=20
> On 3/9/12 11:12 AM, lionel.morand@orange.com wrote:
>> What about:
>>=20
>> "A Diameter implementation MUST include the first option (manual =
configuration) and MAY [or "SHOULD" if preferred] include the latter =
option (DNS)."
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part =
de Robert Sparks
>> Envoy=E9 : vendredi 9 mars 2012 16:20
>> =C0 : jouni korhonen
>> Cc : dime@ietf.org
>> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory =
toimplement?
>>=20
>>=20
>>=20
>> On 3/9/12 2:17 AM, jouni korhonen wrote:
>>> Hi,
>>>=20
>>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>>>=20
>>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>>>> Question: Is the DNS-based peer discovery mechanism mandatory to =
implement?
>>>>>=20
>>>>> The first paragraph of 5.2 speaks in terms of "supported" and if =
you
>>>>> read that to mean "implemented" the answer is no, but after =
talking to
>>>>> some folks I'm not sure that was the intent. Was the intent =
mandatory to
>>>>> implement, optional to use?
>>>> Good question.  The text in question uses the term "Diameter node",
>>>> which is a computer actually running Diameter, so my take on it =
would be
>>>> that the node might not support the option (in terms of actually =
using
>>>> it)but that the option would nevertheless be available (i.e.,
>>>> implemented).  It seems like the text could be clearer though -- =
any
>>>> suggestions?
>> It's not sufficient to rely on the underlying computer having DNS =
libraries.
>> You specified DIAMETER specific logic - the person that wrote the
>> diameter code
>> is going to have to write code - it might _use_ a DNS library on an
>> underlying
>> OS, but it's the DIAMETER code that's going to have to provide the
>> inputs to the
>> NAPTR queries, (or SRV queries, if starting at that level), and =
follow
>> the rules in
>> this document on interpreting the results. _Thats_ the code that =
needs
>> to be mandatory
>> to implement.
>>> How about:
>>>=20
>>>     ..
>>>     discovery, the following mechanisms are described.  These are =
based
>>>     on existing IETF standards.  The first option (manual =
configuration)
>>>     MUST be implemented and supported by all Diameter nodes, while =
the
>>>     latter option (DNS) MAY be implemented and MAY be supported  by
>>>     Diameter nodes.
>>>=20
>>> However, we could also try to make DNS option more widely used, =
since
>>> every box in practice has to have some level of DNS resolver =
capability:
>>>=20
>>>     ..
>>>     MUST be implemented and supported by all Diameter nodes, while =
the
>>>     latter option (DNS) SHOULD be implemented and if implemented MAY =
be
>>>     used by Diameter nodes.
>>>=20
>>>=20
>>> Opinions?
>>>=20
>>>=20
>>> - Jouni
>>>=20
>>>=20
>>>=20
>>>>> That would ensure that an operator had the
>>>>> option to start using the DNS-based discovery mechanism when it =
was the
>>>>> right thing to do.
>>>>>=20
>>>>> RjS
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime


From glenzorn@gmail.com  Mon Mar 12 03:37:23 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6F221F8636; Mon, 12 Mar 2012 03:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.329
X-Spam-Level: 
X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=0.270,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFHJay-rJmc5; Mon, 12 Mar 2012 03:37:21 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA57221F861D; Mon, 12 Mar 2012 03:37:21 -0700 (PDT)
Received: by yhpp34 with SMTP id p34so2694464yhp.31 for ; Mon, 12 Mar 2012 03:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BGvUAl284sCvqmi7dwksTHfU3C6ClpLoOXakUSwFG/8=; b=UnL91VbmfXotzj1bMSsnMMRUdFiNs8JriL2aqbB3PAgqdWmu1qjH7xzI6cL9muiCOn V7y8WZuJz97BApMy9U7GwC/qwMj6Qu+yu0spTBf4ZAHURefa0ObDeoXdVo8retK8wYAW COPBs2gqIuvtnz/CG+s6QxtDzLVg7GPcabSrJhwF1UzOHMFnWwgqUdpdZizTcrF3MzRU vXqpd/at3avYbBzncs4gglUnXBAayJXpFaaIptZmfJrWId7gJigLH5H07Fk6/RTl1YzO 1nErPAa2OikfblzlZHTSkO0Dk3ORIZCaEWNF7SaGp4ZsLNBj0B185LkXK7XMCSPVfU57 Dehw==
Received: by 10.60.25.41 with SMTP id z9mr7357152oef.70.1331548641268; Mon, 12 Mar 2012 03:37:21 -0700 (PDT)
Received: from [192.168.1.98] (ppp-124-120-28-217.revip2.asianet.co.th. [124.120.28.217]) by mx.google.com with ESMTPS id yv3sm19928984obb.3.2012.03.12.03.37.16 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 03:37:19 -0700 (PDT)
Message-ID: <4F5DD1D9.1000404@gmail.com>
Date: Mon, 12 Mar 2012 17:37:13 +0700
From: Glen Zorn 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: jouni korhonen 
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> <4F5A26A8.9090004@stpeter.im> <4F5C4F27.5020905@gmail.com>  <4F5C8951.4040503@gmail.com> <737722A5-9078-4890-9F9F-7FA93ADB85A5@gmail.com>
In-Reply-To: <737722A5-9078-4890-9F9F-7FA93ADB85A5@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, Jouni Korhonen , "dime@ietf.org" , The IESG , Peter Saint-Andre 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2012 10:37:23 -0000

On 3/11/2012 7:15 PM, jouni korhonen wrote:
> Hi,
> 
> On Mar 11, 2012, at 1:15 PM, Glen Zorn wrote:
> 
>> On 3/11/2012 4:59 PM, jouni korhonen wrote:
>>
>> ...
>>
>>>>>>> OK, what to do about the port number, etc.?  Jouni, since you
>>>>>>> volunteered that we would do this, how about writing the section?
>>>>>>
>>>>>> That's ok.
>>>>
>>>> Can this be done before the deadline Monday?
>>>
>>> I try to get this done tonight.
>>
>> Never mind, I gave it a shot myself; but please take a look at
> 
> Thanks :)
> 
>> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-31#section-11.4 to
>> see if I got it right :-).
> 
> Don't we also need an entry for "_diameters"?

OK, so "diameter" is already in the IANA service name registry; what do
we need _diameter for?

> 
> The Port  Number should probably be "TBD, from the User Ports".

Fine.

> 
> Not sure about IESG and IETF chair as assignees and contact point.. 

RFC 6335 says

      For assignments done through RFCs published via the "IETF
      Document Stream" [RFC4844], the Assignee will be the IESG
      .
and
      For assignments done through RFCs published via the "IETF
      Document Stream" [RFC4844], the Contact will be the IETF Chair
      .

Isn't this draft being published via the IETF Document Stream?

> Since
> User Ports are assigned by IANA maybe we could put IANA as the contact
> and the assignee ? Don't have a preference though :)
> 
> Otherwise looked ok to me.
> 
> - Jouni
> 
> 
> 
>>
>> ...
> 


From glenzorn@gmail.com  Mon Mar 12 03:40:22 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F2D21F8636; Mon, 12 Mar 2012 03:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.337
X-Spam-Level: 
X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.262,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z2UPM5LSWfb; Mon, 12 Mar 2012 03:40:10 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99AD721F8628; Mon, 12 Mar 2012 03:40:10 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so2718898ggm.31 for ; Mon, 12 Mar 2012 03:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4gX/vQWZNl6Rpilrsjl45LV0I32vfCJMi/VpOC7dUQ4=; b=ME5LZEAK9XsGIJWnTxWyeCN6MC3V6ijrdCTyXuROdiHYtY1jA8x+phC1KT55LVquCl MjD+Cp8z/VDs3luxNCslN5IjWZU60IRvbwwJzm9YSxzRXPBYilKECIne7YKLCl5pI3pS Tgn9YIuQ0bBsbG7BHUJWZp37MqzGm8ms3gVbNwfh1WlO/YeedFlYavwy8+iwl7GIGTUS Qs//KkmNYCkf5JSVb8v6k/udPtLXzALmUFncZ9Z04ZIhgE1nrXE78mcUf4lrcKd5Xfoj Swty3gXfW85H0GeiLG6QnAx+8lvv11rkhjMEslObTp7vfJnHDbOXtyP0xJx0gnkC8Lzh vIdg==
Received: by 10.182.16.65 with SMTP id e1mr7016658obd.26.1331548810168; Mon, 12 Mar 2012 03:40:10 -0700 (PDT)
Received: from [192.168.1.98] (ppp-124-120-28-217.revip2.asianet.co.th. [124.120.28.217]) by mx.google.com with ESMTPS id g4sm10386965oeg.5.2012.03.12.03.40.05 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 03:40:09 -0700 (PDT)
Message-ID: <4F5DD283.5070403@gmail.com>
Date: Mon, 12 Mar 2012 17:40:03 +0700
From: Glen Zorn 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: jouni korhonen 
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> <4F5A26A8.9090004@stpeter.im> <4F5C4F27.5020905@gmail.com>  <4F5C8951.4040503@gmail.com> <737722A5-9078-4890-9F9F-7FA93ADB85A5@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime-chairs@tools.ietf.org, dime@ietf.org, The IESG , Peter Saint-Andre 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2012 10:40:22 -0000

On 3/12/2012 1:58 AM, jouni korhonen wrote:
> 
>>
>> Don't we also need an entry for "_diameters"?
>>
>> The Port  Number should probably be "TBD, from the User Ports".
>>
>> Not sure about IESG and IETF chair as assignees and contact point.. Since
>> User Ports are assigned by IANA maybe we could put IANA as the contact
>> and the assignee ? Don't have a preference though :)
> 
> Ok. Some foofoo stated by me here regarding the contacts ;)
> 
> This would be the registry entry with corrected service name 
> and missing UDP protocol:

I'm pretty sure that Diameter doesn't run over UDP; why is it "missing"?

> 
> 11.4.  "diameters" Service Name and Port Number Registration
> 
>    This section requests the IANA to register the "diameters" service
>    name and assign port numbers for TLS/TCP and DTLS/SCTP according to
>    the guidelines given in Cotton, et al.  [RFC6335].
>    
>       Service Name:         diameters
>       Transport Protocols:  TCP, SCTP, UDP (reserved)
>       Assignee:             IESG 
>       Contact:              IETF Chair 
>       Description:          Diameter over TLS/TCP and DTLS/SCTP
>       Reference:            draft-ietf-dime-rfc3588bis
>       Port  Number:         TBD, from the User Ports range
> 
> - Jouni
> 
>>
>> Otherwise looked ok to me.
>>
>> - Jouni
>>
>>
>>
>>>
>>> ...
>>
> 


From jouni.nospam@gmail.com  Mon Mar 12 03:55:03 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A389221F8694; Mon, 12 Mar 2012 03:55:03 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM0qgHlvleRG; Mon, 12 Mar 2012 03:55:03 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF5D21F86E1; Mon, 12 Mar 2012 03:55:02 -0700 (PDT)
Received: by lbol12 with SMTP id l12so1115066lbo.31 for ; Mon, 12 Mar 2012 03:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Pg6eFexczrIt56i4mQSuVQWR2L9P71IkEVn2p9EUwog=; b=X6x44V+IWC0JjzgRA4/OJti3L2jpJW1r/zz+3WerguXwYLkiqX40EJISO9bj2rEFPQ fG1d7L86CJkWb4Owef4EeLaYBJwKwX5fFY/R91XxQ2zxh3sAVeHKOQENaaBXRKConSOy pvZ6mBXEcyGQIVPCyDI5VHGXnuPts4jiZ0EvU6FYfWUopjQvKY/gaQm3xht0Ifg4qDNh QXgdcFe3huiRjGpaxaTia+jqlr+yu0yoEgEIKgwWebfnXdOHN/kzrBao5mYdeRATRm7K xx3pjyX6LxTtwxWISNXJe2/hXzwNtjQlJQcVLiW5ZG776vRBDN9Zdhv8cIB6C3Eocwkt NRZQ==
Received: by 10.152.130.167 with SMTP id of7mr8656922lab.36.1331549701494; Mon, 12 Mar 2012 03:55:01 -0700 (PDT)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id gw17sm13598906lab.11.2012.03.12.03.54.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 03:55:00 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <4F5DD283.5070403@gmail.com>
Date: Mon, 12 Mar 2012 12:54:58 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <4F58D4E9.2070905@stpeter.im> <4F59C07E.2090009@gmail.com> <056DAD37-4800-49B3-BA0B-2F86AF3C9139@gmail.com> <4F5A26A8.9090004@stpeter.im> <4F5C4F27.5020905@gmail.com>  <4F5C8951.4040503@gmail.com> <737722A5-9078-4890-9F9F-7FA93ADB85A5@gmail.com>  <4F5DD283.5070403@gmail.com>
To: Glen Zorn 
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, dime-chairs@tools.ietf.org, Peter Saint-Andre , The IESG 
Subject: Re: [Dime] Peter Saint-Andre's Discuss on draft-ietf-dime-rfc3588bis-29: (withDISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2012 10:55:03 -0000

On Mar 12, 2012, at 12:40 PM, Glen Zorn wrote:

> On 3/12/2012 1:58 AM, jouni korhonen wrote:
>> 
>>> 
>>> Don't we also need an entry for "_diameters"?
>>> 
>>> The Port  Number should probably be "TBD, from the User Ports".
>>> 
>>> Not sure about IESG and IETF chair as assignees and contact point.. Since
>>> User Ports are assigned by IANA maybe we could put IANA as the contact
>>> and the assignee ? Don't have a preference though :)
>> 
>> Ok. Some foofoo stated by me here regarding the contacts ;)
>> 
>> This would be the registry entry with corrected service name 
>> and missing UDP protocol:
> 
> I'm pretty sure that Diameter doesn't run over UDP; why is it "missing"?

The existing registry entry also listed UDP as reserved. That's why I added
it here as well as "reserved".

- Jouni


> 
>> 
>> 11.4.  "diameters" Service Name and Port Number Registration
>> 
>>   This section requests the IANA to register the "diameters" service
>>   name and assign port numbers for TLS/TCP and DTLS/SCTP according to
>>   the guidelines given in Cotton, et al.  [RFC6335].
>> 
>>      Service Name:         diameters
>>      Transport Protocols:  TCP, SCTP, UDP (reserved)
>>      Assignee:             IESG 
>>      Contact:              IETF Chair 
>>      Description:          Diameter over TLS/TCP and DTLS/SCTP
>>      Reference:            draft-ietf-dime-rfc3588bis
>>      Port  Number:         TBD, from the User Ports range
>> 
>> - Jouni
>> 
>>> 
>>> Otherwise looked ok to me.
>>> 
>>> - Jouni
>>> 
>>> 
>>> 
>>>> 
>>>> ...
>>> 
>> 
> 


From dromasca@avaya.com  Mon Mar 12 05:59:29 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD36221F8700 for ; Mon, 12 Mar 2012 05:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.074
X-Spam-Level: 
X-Spam-Status: No, score=-103.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDSsBebBp3pW for ; Mon, 12 Mar 2012 05:59:28 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA2321F872D for ; Mon, 12 Mar 2012 05:59:28 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAIHxXU+HCzI1/2dsb2JhbABBqEaNEoEHggkBAQEBAwEBAQ8ePgsMBAIBCA0EBAEBAQoGDAsBBgEgBh8JCAEBBAESCBqHaAuibpNyBIlEbBCFXmMEiCGTNoUghHiCZIFTAg
X-IronPort-AV: E=Sophos;i="4.73,571,1325480400"; d="scan'208";a="296499450"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Mar 2012 08:59:24 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Mar 2012 08:44:06 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Mar 2012 13:59:18 +0100
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Is DNS-based diameter peer discovery mandatorytoimplement?
Thread-Index: Acz/wjXuvDgp0ZCnR2Gkd1OqHKptZQAZ4bswAAmH9mA=
References: <4F591045.6010601@nostrum.com><4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com><4F5A1F8D.4010607@nostrum.com><4F5A5158.90402@nostrum.com> 
From: "Romascanu, Dan (Dan)" 
To: , , 
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatorytoimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2012 12:59:29 -0000

This would be my reading.=20

Regards,

Dan




> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf =
Of
> lionel.morand@orange.com
> Sent: Monday, March 12, 2012 10:29 AM
> To: jouni.nospam@gmail.com; rjsparks@nostrum.com
> Cc: dime@ietf.org
> Subject: Re: [Dime] Is DNS-based diameter peer discovery
> mandatorytoimplement?
>=20
> Hi,
>=20
> I could also agree on the "MUST implement/MAY use" but would it mean
> that existing Diameter implementations that do not provide DNS-based
> discovery mechanism would be not anymore compliant with the Base
> protocol and would have to be upgraded?
>=20
> Regards,
>=20
> Lionel
>=20
> -----Message d'origine-----
> De=A0: jouni korhonen [mailto:jouni.nospam@gmail.com]
> Envoy=E9=A0: dimanche 11 mars 2012 21:05
> =C0=A0: Robert Sparks
> Cc=A0: MORAND Lionel RD-CORE-ISS; dime@ietf.org
> Objet=A0: Re: [Dime] Is DNS-based diameter peer discovery mandatory
> toimplement?
>=20
> Hi,
>=20
> On Mar 9, 2012, at 8:52 PM, Robert Sparks wrote:
>=20
> > I think we must be talking past each other. That suggestion doesn't
> look different than what's in -30, and
> > doesn't address the point I made in the message you responded to.
> >
> > Let me try this a different way. The text in -30 and the text you
> propose below say that it's OK for
> > an operator to have deployed a "conformant" diameter implementation
> and later discover that he
> > can't use the DNS-based peer discovery mechanism without acquiring
> another one (or going back to
> > the original provider for a code change). Is that really what the
> group concluded? That would surprise me,
>=20
> Vendors can always build a nice licensing scheme around this ;-)
>=20
> I could be OK with "MUST implement, MAY use" for DNS-based peer
> discovery
> if that is what WG wants. The issue I have in general with "MUST" in
> current
> DNS-based peer discovery is its limited usability in deployments. A
> peer does
> (S-)NAPTR/SRV query for another domain (realm) and finds an address =
etc
> of
> its node representing the entire realm. However, this does not help me
> if
> there are intermediates that my requests must go through e.g. before
> leaving
> my own realm. It then ends up only specific type of nodes (like edge
> agents
> of some administrative domain) even needing DNS functionality for DNS-
> based
> dynamic peer discovery.
>=20
> Anyway, as said, I am mostly open for anything.
>=20
>=20
> > and I'd like to read the discussion so I can see how the group =
landed
> there.
> >
> > I could see a decision that would say that manual configuration =
still
> needs to be an option available to the operator.
>=20
> Yes. Manual is must.
>=20
> - Jouni
>=20
> >
> > RjS
> >
> > On 3/9/12 11:12 AM, lionel.morand@orange.com wrote:
> >> What about:
> >>
> >> "A Diameter implementation MUST include the first option (manual
> configuration) and MAY [or "SHOULD" if preferred] include the latter
> option (DNS)."
> >>
> >> Lionel
> >>
> >> -----Message d'origine-----
> >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la =
part
> de Robert Sparks
> >> Envoy=E9 : vendredi 9 mars 2012 16:20
> >> =C0 : jouni korhonen
> >> Cc : dime@ietf.org
> >> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory
> toimplement?
> >>
> >>
> >>
> >> On 3/9/12 2:17 AM, jouni korhonen wrote:
> >>> Hi,
> >>>
> >>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
> >>>
> >>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
> >>>>> Question: Is the DNS-based peer discovery mechanism mandatory to
> implement?
> >>>>>
> >>>>> The first paragraph of 5.2 speaks in terms of "supported" and if
> you
> >>>>> read that to mean "implemented" the answer is no, but after
> talking to
> >>>>> some folks I'm not sure that was the intent. Was the intent
> mandatory to
> >>>>> implement, optional to use?
> >>>> Good question.  The text in question uses the term "Diameter
> node",
> >>>> which is a computer actually running Diameter, so my take on it
> would be
> >>>> that the node might not support the option (in terms of actually
> using
> >>>> it)but that the option would nevertheless be available (i.e.,
> >>>> implemented).  It seems like the text could be clearer though --
> any
> >>>> suggestions?
> >> It's not sufficient to rely on the underlying computer having DNS
> libraries.
> >> You specified DIAMETER specific logic - the person that wrote the
> >> diameter code
> >> is going to have to write code - it might _use_ a DNS library on an
> >> underlying
> >> OS, but it's the DIAMETER code that's going to have to provide the
> >> inputs to the
> >> NAPTR queries, (or SRV queries, if starting at that level), and
> follow
> >> the rules in
> >> this document on interpreting the results. _Thats_ the code that
> needs
> >> to be mandatory
> >> to implement.
> >>> How about:
> >>>
> >>>     ..
> >>>     discovery, the following mechanisms are described.  These are
> based
> >>>     on existing IETF standards.  The first option (manual
> configuration)
> >>>     MUST be implemented and supported by all Diameter nodes, while
> the
> >>>     latter option (DNS) MAY be implemented and MAY be supported  =
by
> >>>     Diameter nodes.
> >>>
> >>> However, we could also try to make DNS option more widely used,
> since
> >>> every box in practice has to have some level of DNS resolver
> capability:
> >>>
> >>>     ..
> >>>     MUST be implemented and supported by all Diameter nodes, while
> the
> >>>     latter option (DNS) SHOULD be implemented and if implemented
> MAY be
> >>>     used by Diameter nodes.
> >>>
> >>>
> >>> Opinions?
> >>>
> >>>
> >>> - Jouni
> >>>
> >>>
> >>>
> >>>>> That would ensure that an operator had the
> >>>>> option to start using the DNS-based discovery mechanism when it
> was the
> >>>>> right thing to do.
> >>>>>
> >>>>> RjS
> >>>>>
> >>>>> _______________________________________________
> >>>>> DiME mailing list
> >>>>> DiME@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/dime
> >>>> _______________________________________________
> >>>> DiME mailing list
> >>>> DiME@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/dime
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

From jouni.nospam@gmail.com  Mon Mar 12 12:51:03 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393D421F85AD for ; Mon, 12 Mar 2012 12:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.481
X-Spam-Level: 
X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNUKRN5CttBg for ; Mon, 12 Mar 2012 12:51:02 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33E5521E80A5 for ; Mon, 12 Mar 2012 12:51:02 -0700 (PDT)
Received: by lagj5 with SMTP id j5so4718070lag.31 for ; Mon, 12 Mar 2012 12:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xGjatXce0vAg50RKQ0LNCRTZHwxmlE1KuZcv0m0GiPE=; b=cp6faRviIygsdpSTVdzKqNWTwDUPTQ0VsHrrtiimze5J6Cm4JxUivFeOXKqkLKkV1a odk6CPwVYd95FIu/fwTM1H1Np5/f8p2Xnzz0kFgC316XFVL7IQTGZgDqGg3scB8CU3GE B1f8ktBJ7oJo2rpeiyeYU9GuOjKLNW8Ff5Y0sgnK5krM1Q4Itcem8A8J5eKbW+1eV2l4 xbD7NIg4nnF30lIzXf+t/klhNG+Q0QxLvCC4uDBM8uuCyQb78BwA+Ov72Qe00QIzGx78 edWLVbL/vFOTHAp0NcCxAR/EX0gLD87I6nhGxjgXfzT72kqy5tw71c79b2EVbicI4F5O Nhbw==
Received: by 10.152.112.132 with SMTP id iq4mr9893889lab.28.1331581861188; Mon, 12 Mar 2012 12:51:01 -0700 (PDT)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id ny9sm14803267lab.6.2012.03.12.12.50.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 12:50:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: jouni korhonen 
In-Reply-To: 
Date: Mon, 12 Mar 2012 21:50:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com>
References: 
To: Ben Campbell 
X-Mailer: Apple Mail (2.1084)
Cc: dime@ietf.org
Subject: Re: [Dime] 3588bis Peer Discovery Questions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2012 19:51:03 -0000

Ben,

Normal "Dime lag" added to the response ;) See inline.

On Feb 4, 2012, at 12:36 AM, Ben Campbell wrote:

> Hi All,
>=20
> I'm digesting the Peer Discovery section of 3588bis-29 (Section 5.2), =
and have some questions. I apologize in advance if these have been =
covered in past discussion.
>=20
> 1) paragraph 1 says that "=85 the later option (DNS) MAY be supported:
>=20
> Does that mean supported "by the software implementation", or =
supported "by the network deployment"? That is, is the intent to say =
that DNS based peer discovery MAY be implemented, vs MAY be used?

This is currently under a debate.. as you probably have seen.

> 2) Paragraph 2 talks about peer discovery by a client to find a next =
hop agent, or an agent to find another (next hop) agent. Is peer =
discovery limited to finding Diameter Agents? That is, can a Diameter =
client discover a Diameter server? (Perhaps the word "node" was intended =
rather than "agent"?)

It entirely depends what the domain owner populates into its DNS. If =
he/she puts there RRs for a relay, then the DNS-based discovery =
discovers it. If he/she puts there RRs for a server, then server gets =
discovered. There is no strict rule about that.

> 3) The 4th paragraph from the end says that, when using a site =
certificate, _both_ the domain name in the initial query and the name in =
the replacement field must match the site certificate. Is that just the =
for initial query and the final result, or does it cover any =
intermediate steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does =
the SRV step also need to match?) Is there an expectation that the =
client will actually validate against both the queried name and the =
resulting name, or is the point merely that the cert should include them =
because different clients may start their initial query at different =
places in the DDDS sequence?

As far as I understand it, all domain names used for the query: the one =
for querying NAPTR, possible A/AAAA replacement from NAPTR, or =
replacement to query a SRV and finally the A/AAAAs in the SRV; must be =
in the cert. The client can check any of those.. it does not need to =
check whole chain but it probably should. The reason is stated in the =
same paragraph:

   MUST both be valid based on the same site certificate.  Otherwise, an
   attacker could modify the DNS records to contain replacement values
   in a different domain, and the client could not validate that this
   was the desired behavior, or the result of an attack.

- Jouni


>=20
> Thanks!
>=20
> Ben.
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Mon Mar 12 13:20:00 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B170921F88EE for ; Mon, 12 Mar 2012 13:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FBrZ8B4M9hF for ; Mon, 12 Mar 2012 13:20:00 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id F227C21F8893 for ; Mon, 12 Mar 2012 13:19:59 -0700 (PDT)
Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2CKJvZi038708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Mar 2012 15:19:58 -0500 (CDT) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Ben Campbell 
In-Reply-To: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com>
Date: Mon, 12 Mar 2012 15:20:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com>
References:  <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com>
To: jouni korhonen 
X-Mailer: Apple Mail (2.1257)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: dime@ietf.org
Subject: Re: [Dime] 3588bis Peer Discovery Questions
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Mar 2012 20:20:00 -0000

On Mar 12, 2012, at 2:50 PM, jouni korhonen wrote:

> Ben,
>=20
> Normal "Dime lag" added to the response ;) See inline.

Thanks, also see inline:

>=20
> On Feb 4, 2012, at 12:36 AM, Ben Campbell wrote:
>=20
>> Hi All,
>>=20
>> I'm digesting the Peer Discovery section of 3588bis-29 (Section 5.2), =
and have some questions. I apologize in advance if these have been =
covered in past discussion.
>>=20
>> 1) paragraph 1 says that "=85 the later option (DNS) MAY be =
supported:
>>=20
>> Does that mean supported "by the software implementation", or =
supported "by the network deployment"? That is, is the intent to say =
that DNS based peer discovery MAY be implemented, vs MAY be used?
>=20
> This is currently under a debate.. as you probably have seen.

Yes, thanks.  Put me in the "prefer MUST implement" camp. I've seen too =
many situations where management is harder than it needs to be because =
people are pre-provisioning every possible peer, often by IP address. =
While you can't make them stop doing that if they _want_ to, it would be =
nice if vendors gave them the option to not.

>=20
>> 2) Paragraph 2 talks about peer discovery by a client to find a next =
hop agent, or an agent to find another (next hop) agent. Is peer =
discovery limited to finding Diameter Agents? That is, can a Diameter =
client discover a Diameter server? (Perhaps the word "node" was intended =
rather than "agent"?)
>=20
> It entirely depends what the domain owner populates into its DNS. If =
he/she puts there RRs for a relay, then the DNS-based discovery =
discovers it. If he/she puts there RRs for a server, then server gets =
discovered. There is no strict rule about that.

That's what I hoped the answer was--but the text is confusing on that =
point.


>=20
>> 3) The 4th paragraph from the end says that, when using a site =
certificate, _both_ the domain name in the initial query and the name in =
the replacement field must match the site certificate. Is that just the =
for initial query and the final result, or does it cover any =
intermediate steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does =
the SRV step also need to match?) Is there an expectation that the =
client will actually validate against both the queried name and the =
resulting name, or is the point merely that the cert should include them =
because different clients may start their initial query at different =
places in the DDDS sequence?
>=20
> As far as I understand it, all domain names used for the query: the =
one for querying NAPTR, possible A/AAAA replacement from NAPTR, or =
replacement to query a SRV and finally the A/AAAAs in the SRV; must be =
in the cert. The client can check any of those.. it does not need to =
check whole chain but it probably should. The reason is stated in the =
same paragraph:
>=20
>   MUST both be valid based on the same site certificate.  Otherwise, =
an
>   attacker could modify the DNS records to contain replacement values
>   in a different domain, and the client could not validate that this
>   was the desired behavior, or the result of an attack.

It's not clear to me what the attack is where a cert that contains the =
initial name but not the derived names but not where the cert also =
contains all the derived names. Unless I'm reading it wrong, the =
security considerations for DDDS (RFC3958) only require the server to =
supply a certificate that matches the _original_ name.

>=20
> - Jouni
>=20
>=20
>>=20
>> Thanks!
>>=20
>> Ben.
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From glenzorn@gmail.com  Mon Mar 12 23:12:24 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FA721F88D5 for ; Mon, 12 Mar 2012 23:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.195
X-Spam-Level: 
X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, MANGLED_SFTWRE=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MxuwZFGi+07 for ; Mon, 12 Mar 2012 23:12:23 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB1D21F88D4 for ; Mon, 12 Mar 2012 23:12:23 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so199738ghb.31 for ; Mon, 12 Mar 2012 23:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=o920DkSCq2ynONOk0PQmimfo1Bi6NHykzg/XJl6Ijso=; b=ZkwxBazWQ9yxGkiu5kDR7EzA4EC6PZn5PCIghAYNZynLoqXQopAZNFdsi8/XIIDHBm LqCopTqoIJGs5MX0ZztwVgPlxHEersf6Pbi/emJUEQzk6NwxASwzAqPu/cvaqZKtzlsz vDNi+2xTJ4vMGWKFXFaIGJHiO8oSYhu0HTU91aYfQFtrK/nBnRQYw6Nl/OkpVvXmhAlC suE8wbDJQ2VXFCo8MprE/Ej2UPqCWeg4U5cklkzLg2c8BP910EnipcxgvkwROGkIHVIq 6GM9fGx/7VLFSvU0nrhT4xzkG+8cG1JUamgzICBGxyDfRAnFA1vf4yqUMY7UW93VkKOd CM2Q==
Received: by 10.60.13.132 with SMTP id h4mr10092566oec.62.1331619139846; Mon, 12 Mar 2012 23:12:19 -0700 (PDT)
Received: from [192.168.1.98] (ppp-124-120-240-174.revip2.asianet.co.th. [124.120.240.174]) by mx.google.com with ESMTPS id b3sm24618357obp.6.2012.03.12.23.12.15 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 23:12:18 -0700 (PDT)
Message-ID: <4F5EE53B.3090106@gmail.com>
Date: Tue, 13 Mar 2012 13:12:11 +0700
From: Glen Zorn 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" 
References: <4F591045.6010601@nostrum.com><4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com><4F5A1F8D.4010607@nostrum.com><4F5A5158.90402@nostrum.com>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatorytoimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Mar 2012 06:12:24 -0000

On 3/12/2012 7:59 PM, Romascanu, Dan (Dan) wrote:
> This would be my reading.

Not mine: implementations that are RFC 3588 compliant would remain so.
We even specifically call out various conditions under which
implementations that only comply with RFC 3588 can interoperate with
this version.  In any case, who cares?  there is a reason why it's
called "soft" ware...

> 
> Regards,
> 
> Dan
> 
> 
> 
> 
>> -----Original Message-----
>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of
>> lionel.morand@orange.com
>> Sent: Monday, March 12, 2012 10:29 AM
>> To: jouni.nospam@gmail.com; rjsparks@nostrum.com
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Is DNS-based diameter peer discovery
>> mandatorytoimplement?
>>
>> Hi,
>>
>> I could also agree on the "MUST implement/MAY use" but would it mean
>> that existing Diameter implementations that do not provide DNS-based
>> discovery mechanism would be not anymore compliant with the Base
>> protocol and would have to be upgraded?
>>
>> Regards,
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : jouni korhonen [mailto:jouni.nospam@gmail.com]
>> Envoyé : dimanche 11 mars 2012 21:05
>> À : Robert Sparks
>> Cc : MORAND Lionel RD-CORE-ISS; dime@ietf.org
>> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory
>> toimplement?
>>
>> Hi,
>>
>> On Mar 9, 2012, at 8:52 PM, Robert Sparks wrote:
>>
>>> I think we must be talking past each other. That suggestion doesn't
>> look different than what's in -30, and
>>> doesn't address the point I made in the message you responded to.
>>>
>>> Let me try this a different way. The text in -30 and the text you
>> propose below say that it's OK for
>>> an operator to have deployed a "conformant" diameter implementation
>> and later discover that he
>>> can't use the DNS-based peer discovery mechanism without acquiring
>> another one (or going back to
>>> the original provider for a code change). Is that really what the
>> group concluded? That would surprise me,
>>
>> Vendors can always build a nice licensing scheme around this ;-)
>>
>> I could be OK with "MUST implement, MAY use" for DNS-based peer
>> discovery
>> if that is what WG wants. The issue I have in general with "MUST" in
>> current
>> DNS-based peer discovery is its limited usability in deployments. A
>> peer does
>> (S-)NAPTR/SRV query for another domain (realm) and finds an address etc
>> of
>> its node representing the entire realm. However, this does not help me
>> if
>> there are intermediates that my requests must go through e.g. before
>> leaving
>> my own realm. It then ends up only specific type of nodes (like edge
>> agents
>> of some administrative domain) even needing DNS functionality for DNS-
>> based
>> dynamic peer discovery.
>>
>> Anyway, as said, I am mostly open for anything.
>>
>>
>>> and I'd like to read the discussion so I can see how the group landed
>> there.
>>>
>>> I could see a decision that would say that manual configuration still
>> needs to be an option available to the operator.
>>
>> Yes. Manual is must.
>>
>> - Jouni
>>
>>>
>>> RjS
>>>
>>> On 3/9/12 11:12 AM, lionel.morand@orange.com wrote:
>>>> What about:
>>>>
>>>> "A Diameter implementation MUST include the first option (manual
>> configuration) and MAY [or "SHOULD" if preferred] include the latter
>> option (DNS)."
>>>>
>>>> Lionel
>>>>
>>>> -----Message d'origine-----
>>>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part
>> de Robert Sparks
>>>> Envoyé : vendredi 9 mars 2012 16:20
>>>> À : jouni korhonen
>>>> Cc : dime@ietf.org
>>>> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory
>> toimplement?
>>>>
>>>>
>>>>
>>>> On 3/9/12 2:17 AM, jouni korhonen wrote:
>>>>> Hi,
>>>>>
>>>>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>>>>>
>>>>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>>>>>> Question: Is the DNS-based peer discovery mechanism mandatory to
>> implement?
>>>>>>>
>>>>>>> The first paragraph of 5.2 speaks in terms of "supported" and if
>> you
>>>>>>> read that to mean "implemented" the answer is no, but after
>> talking to
>>>>>>> some folks I'm not sure that was the intent. Was the intent
>> mandatory to
>>>>>>> implement, optional to use?
>>>>>> Good question.  The text in question uses the term "Diameter
>> node",
>>>>>> which is a computer actually running Diameter, so my take on it
>> would be
>>>>>> that the node might not support the option (in terms of actually
>> using
>>>>>> it)but that the option would nevertheless be available (i.e.,
>>>>>> implemented).  It seems like the text could be clearer though --
>> any
>>>>>> suggestions?
>>>> It's not sufficient to rely on the underlying computer having DNS
>> libraries.
>>>> You specified DIAMETER specific logic - the person that wrote the
>>>> diameter code
>>>> is going to have to write code - it might _use_ a DNS library on an
>>>> underlying
>>>> OS, but it's the DIAMETER code that's going to have to provide the
>>>> inputs to the
>>>> NAPTR queries, (or SRV queries, if starting at that level), and
>> follow
>>>> the rules in
>>>> this document on interpreting the results. _Thats_ the code that
>> needs
>>>> to be mandatory
>>>> to implement.
>>>>> How about:
>>>>>
>>>>>     ..
>>>>>     discovery, the following mechanisms are described.  These are
>> based
>>>>>     on existing IETF standards.  The first option (manual
>> configuration)
>>>>>     MUST be implemented and supported by all Diameter nodes, while
>> the
>>>>>     latter option (DNS) MAY be implemented and MAY be supported  by
>>>>>     Diameter nodes.
>>>>>
>>>>> However, we could also try to make DNS option more widely used,
>> since
>>>>> every box in practice has to have some level of DNS resolver
>> capability:
>>>>>
>>>>>     ..
>>>>>     MUST be implemented and supported by all Diameter nodes, while
>> the
>>>>>     latter option (DNS) SHOULD be implemented and if implemented
>> MAY be
>>>>>     used by Diameter nodes.
>>>>>
>>>>>
>>>>> Opinions?
>>>>>
>>>>>
>>>>> - Jouni
>>>>>
>>>>>
>>>>>
>>>>>>> That would ensure that an operator had the
>>>>>>> option to start using the DNS-based discovery mechanism when it
>> was the
>>>>>>> right thing to do.
>>>>>>>
>>>>>>> RjS
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> DiME mailing list
>>>>>>> DiME@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From dromasca@avaya.com  Tue Mar 13 03:45:54 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276C721F8781 for ; Tue, 13 Mar 2012 03:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.423
X-Spam-Level: 
X-Spam-Status: No, score=-101.423 tagged_above=-999 required=5 tests=[AWL=-1.724, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MANGLED_SFTWRE=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4N1E8gZ0VQYv for ; Tue, 13 Mar 2012 03:45:53 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 339C221F877D for ; Tue, 13 Mar 2012 03:45:53 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJIkX0/GmAcF/2dsb2JhbABDqECNIIEHggkBAQEBAwEBAQ8ePgsMBAIBCA0EBAEBAQoGDAsBBgEgBh8JCAEBBBMIGodoC6BmnBkEiUJqEIVGYwSIIpM4hSCEeIJmgVMC
X-IronPort-AV: E=Sophos;i="4.73,576,1325480400"; d="scan'208";a="237598602"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Mar 2012 06:45:52 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Mar 2012 06:38:00 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Mar 2012 11:45:49 +0100
Message-ID: 
In-Reply-To: <4F5EE53B.3090106@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Is DNS-based diameter peer discovery mandatorytoimplement?
Thread-Index: Ac0A4EDm5/IxdZzcS1m9pvYTo5jdNAAJZaQw
References: <4F591045.6010601@nostrum.com><4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com><4F5A1F8D.4010607@nostrum.com><4F5A5158.90402@nostrum.com>   <4F5EE53B.3090106@gmail.com>
From: "Romascanu, Dan (Dan)" 
To: "Glen Zorn" 
Cc: dime@ietf.org
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatorytoimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Mar 2012 10:45:54 -0000

Sure - implementations that are RFC 3588 compliant would remain so (i.e. =
compliant to RFC 3588). It is just that RFC 3588 will not be any longer =
the latest standards track RFC for Diameter after rfc3588bis is =
published and obsoletes it.=20

Regards,

Dan


> -----Original Message-----
> From: Glen Zorn [mailto:glenzorn@gmail.com]
> Sent: Tuesday, March 13, 2012 8:12 AM
> To: Romascanu, Dan (Dan)
> Cc: lionel.morand@orange.com; jouni.nospam@gmail.com;
> rjsparks@nostrum.com; dime@ietf.org
> Subject: Re: [Dime] Is DNS-based diameter peer discovery
> mandatorytoimplement?
>=20
> On 3/12/2012 7:59 PM, Romascanu, Dan (Dan) wrote:
> > This would be my reading.
>=20
> Not mine: implementations that are RFC 3588 compliant would remain so.
> We even specifically call out various conditions under which
> implementations that only comply with RFC 3588 can interoperate with
> this version.  In any case, who cares?  there is a reason why it's
> called "soft" ware...
>=20
> >
> > Regards,
> >
> > Dan
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On =
Behalf
> Of
> >> lionel.morand@orange.com
> >> Sent: Monday, March 12, 2012 10:29 AM
> >> To: jouni.nospam@gmail.com; rjsparks@nostrum.com
> >> Cc: dime@ietf.org
> >> Subject: Re: [Dime] Is DNS-based diameter peer discovery
> >> mandatorytoimplement?
> >>
> >> Hi,
> >>
> >> I could also agree on the "MUST implement/MAY use" but would it =
mean
> >> that existing Diameter implementations that do not provide =
DNS-based
> >> discovery mechanism would be not anymore compliant with the Base
> >> protocol and would have to be upgraded?
> >>
> >> Regards,
> >>
> >> Lionel
> >>
> >> -----Message d'origine-----
> >> De : jouni korhonen [mailto:jouni.nospam@gmail.com]
> >> Envoy=E9 : dimanche 11 mars 2012 21:05
> >> =C0 : Robert Sparks
> >> Cc : MORAND Lionel RD-CORE-ISS; dime@ietf.org
> >> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory
> >> toimplement?
> >>
> >> Hi,
> >>
> >> On Mar 9, 2012, at 8:52 PM, Robert Sparks wrote:
> >>
> >>> I think we must be talking past each other. That suggestion =
doesn't
> >> look different than what's in -30, and
> >>> doesn't address the point I made in the message you responded to.
> >>>
> >>> Let me try this a different way. The text in -30 and the text you
> >> propose below say that it's OK for
> >>> an operator to have deployed a "conformant" diameter =
implementation
> >> and later discover that he
> >>> can't use the DNS-based peer discovery mechanism without acquiring
> >> another one (or going back to
> >>> the original provider for a code change). Is that really what the
> >> group concluded? That would surprise me,
> >>
> >> Vendors can always build a nice licensing scheme around this ;-)
> >>
> >> I could be OK with "MUST implement, MAY use" for DNS-based peer
> >> discovery
> >> if that is what WG wants. The issue I have in general with "MUST" =
in
> >> current
> >> DNS-based peer discovery is its limited usability in deployments. A
> >> peer does
> >> (S-)NAPTR/SRV query for another domain (realm) and finds an address
> etc
> >> of
> >> its node representing the entire realm. However, this does not help
> me
> >> if
> >> there are intermediates that my requests must go through e.g. =
before
> >> leaving
> >> my own realm. It then ends up only specific type of nodes (like =
edge
> >> agents
> >> of some administrative domain) even needing DNS functionality for
> DNS-
> >> based
> >> dynamic peer discovery.
> >>
> >> Anyway, as said, I am mostly open for anything.
> >>
> >>
> >>> and I'd like to read the discussion so I can see how the group
> landed
> >> there.
> >>>
> >>> I could see a decision that would say that manual configuration
> still
> >> needs to be an option available to the operator.
> >>
> >> Yes. Manual is must.
> >>
> >> - Jouni
> >>
> >>>
> >>> RjS
> >>>
> >>> On 3/9/12 11:12 AM, lionel.morand@orange.com wrote:
> >>>> What about:
> >>>>
> >>>> "A Diameter implementation MUST include the first option (manual
> >> configuration) and MAY [or "SHOULD" if preferred] include the =
latter
> >> option (DNS)."
> >>>>
> >>>> Lionel
> >>>>
> >>>> -----Message d'origine-----
> >>>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la
> part
> >> de Robert Sparks
> >>>> Envoy=E9 : vendredi 9 mars 2012 16:20
> >>>> =C0 : jouni korhonen
> >>>> Cc : dime@ietf.org
> >>>> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory
> >> toimplement?
> >>>>
> >>>>
> >>>>
> >>>> On 3/9/12 2:17 AM, jouni korhonen wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
> >>>>>
> >>>>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
> >>>>>>> Question: Is the DNS-based peer discovery mechanism mandatory
> to
> >> implement?
> >>>>>>>
> >>>>>>> The first paragraph of 5.2 speaks in terms of "supported" and
> if
> >> you
> >>>>>>> read that to mean "implemented" the answer is no, but after
> >> talking to
> >>>>>>> some folks I'm not sure that was the intent. Was the intent
> >> mandatory to
> >>>>>>> implement, optional to use?
> >>>>>> Good question.  The text in question uses the term "Diameter
> >> node",
> >>>>>> which is a computer actually running Diameter, so my take on it
> >> would be
> >>>>>> that the node might not support the option (in terms of =
actually
> >> using
> >>>>>> it)but that the option would nevertheless be available (i.e.,
> >>>>>> implemented).  It seems like the text could be clearer though =
--
> >> any
> >>>>>> suggestions?
> >>>> It's not sufficient to rely on the underlying computer having DNS
> >> libraries.
> >>>> You specified DIAMETER specific logic - the person that wrote the
> >>>> diameter code
> >>>> is going to have to write code - it might _use_ a DNS library on
> an
> >>>> underlying
> >>>> OS, but it's the DIAMETER code that's going to have to provide =
the
> >>>> inputs to the
> >>>> NAPTR queries, (or SRV queries, if starting at that level), and
> >> follow
> >>>> the rules in
> >>>> this document on interpreting the results. _Thats_ the code that
> >> needs
> >>>> to be mandatory
> >>>> to implement.
> >>>>> How about:
> >>>>>
> >>>>>     ..
> >>>>>     discovery, the following mechanisms are described.  These =
are
> >> based
> >>>>>     on existing IETF standards.  The first option (manual
> >> configuration)
> >>>>>     MUST be implemented and supported by all Diameter nodes,
> while
> >> the
> >>>>>     latter option (DNS) MAY be implemented and MAY be supported
> by
> >>>>>     Diameter nodes.
> >>>>>
> >>>>> However, we could also try to make DNS option more widely used,
> >> since
> >>>>> every box in practice has to have some level of DNS resolver
> >> capability:
> >>>>>
> >>>>>     ..
> >>>>>     MUST be implemented and supported by all Diameter nodes,
> while
> >> the
> >>>>>     latter option (DNS) SHOULD be implemented and if implemented
> >> MAY be
> >>>>>     used by Diameter nodes.
> >>>>>
> >>>>>
> >>>>> Opinions?
> >>>>>
> >>>>>
> >>>>> - Jouni
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> That would ensure that an operator had the
> >>>>>>> option to start using the DNS-based discovery mechanism when =
it
> >> was the
> >>>>>>> right thing to do.
> >>>>>>>
> >>>>>>> RjS
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> DiME mailing list
> >>>>>>> DiME@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/dime
> >>>>>> _______________________________________________
> >>>>>> DiME mailing list
> >>>>>> DiME@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/dime
> >>>> _______________________________________________
> >>>> DiME mailing list
> >>>> DiME@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/dime
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dime
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Tue Mar 13 04:15:28 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B3F21F876E for ; Tue, 13 Mar 2012 04:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.038
X-Spam-Level: 
X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=-1.339, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MANGLED_SFTWRE=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvfhFRMcQl6W for ; Tue, 13 Mar 2012 04:15:28 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD4E21F876A for ; Tue, 13 Mar 2012 04:15:21 -0700 (PDT)
Received: by lagj5 with SMTP id j5so404453lag.31 for ; Tue, 13 Mar 2012 04:15:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RsxnGbScz3L2cfaNCea2HOXzlhRI0sD5BdFZ6D/8tt8=; b=RUMuZ7GqaF7JbLMYttAqUS1znUyurMNbJhbRKlz7ZuxCTU2rhkcl6QJf5yocq/Q8RU jMwJIZ1ykLp2r0SpNTAd+dGlDcEXP9qS1BKVaxXq/SOJiBmS2DGHqXh0s/xrTZhBiQ8t SFuo0H43Bq0kt/hs+Cf1N3F115PP7nMXB7Id+nAShx/fhED72212GMgOhv+j8YVZqsp7 35ESisRbDb4gyR8C4tHzTmN0bzPO4yYYHXd2QVHDHQpAqKU89u5LzmX2QBWvuSN89PoB iVgL0irE7iGG4Idom+BqXqtdaSlXuPJpE1kGH+ZLSIhprzucwvALeb5p4mVcFRctMPtC Q/qg==
Received: by 10.112.40.72 with SMTP id v8mr6093367lbk.49.1331637320161; Tue, 13 Mar 2012 04:15:20 -0700 (PDT)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id k10sm267779lbu.1.2012.03.13.04.15.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 04:15:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: jouni korhonen 
In-Reply-To: 
Date: Tue, 13 Mar 2012 13:15:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4F591045.6010601@nostrum.com><4F59726D.5070106@gmail.com><19E9D894-679C-437A-93EF-11629C0D4453@gmail.com><4F5A1F8D.4010607@nostrum.com><4F5A5158.90402@nostrum.com>   <4F5EE53B.3090106@gmail.com> 
To: "Romascanu, Dan (Dan)" , dime@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatorytoimplement?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Mar 2012 11:15:29 -0000

We'll discuss this during the Dime meeting for sure if there
is no clear consensus before that.

As an individual I tend to belong to "SHOULD/MAY" implement
camp for the reason stated earlier.

- Jouni



On Mar 13, 2012, at 12:45 PM, Romascanu, Dan (Dan) wrote:

> Sure - implementations that are RFC 3588 compliant would remain so =
(i.e. compliant to RFC 3588). It is just that RFC 3588 will not be any =
longer the latest standards track RFC for Diameter after rfc3588bis is =
published and obsoletes it.=20
>=20
> Regards,
>=20
> Dan
>=20
>=20
>> -----Original Message-----
>> From: Glen Zorn [mailto:glenzorn@gmail.com]
>> Sent: Tuesday, March 13, 2012 8:12 AM
>> To: Romascanu, Dan (Dan)
>> Cc: lionel.morand@orange.com; jouni.nospam@gmail.com;
>> rjsparks@nostrum.com; dime@ietf.org
>> Subject: Re: [Dime] Is DNS-based diameter peer discovery
>> mandatorytoimplement?
>>=20
>> On 3/12/2012 7:59 PM, Romascanu, Dan (Dan) wrote:
>>> This would be my reading.
>>=20
>> Not mine: implementations that are RFC 3588 compliant would remain =
so.
>> We even specifically call out various conditions under which
>> implementations that only comply with RFC 3588 can interoperate with
>> this version.  In any case, who cares?  there is a reason why it's
>> called "soft" ware...
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Dan
>>>=20
>>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On =
Behalf
>> Of
>>>> lionel.morand@orange.com
>>>> Sent: Monday, March 12, 2012 10:29 AM
>>>> To: jouni.nospam@gmail.com; rjsparks@nostrum.com
>>>> Cc: dime@ietf.org
>>>> Subject: Re: [Dime] Is DNS-based diameter peer discovery
>>>> mandatorytoimplement?
>>>>=20
>>>> Hi,
>>>>=20
>>>> I could also agree on the "MUST implement/MAY use" but would it =
mean
>>>> that existing Diameter implementations that do not provide =
DNS-based
>>>> discovery mechanism would be not anymore compliant with the Base
>>>> protocol and would have to be upgraded?
>>>>=20
>>>> Regards,
>>>>=20
>>>> Lionel
>>>>=20
>>>> -----Message d'origine-----
>>>> De : jouni korhonen [mailto:jouni.nospam@gmail.com]
>>>> Envoy=E9 : dimanche 11 mars 2012 21:05
>>>> =C0 : Robert Sparks
>>>> Cc : MORAND Lionel RD-CORE-ISS; dime@ietf.org
>>>> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory
>>>> toimplement?
>>>>=20
>>>> Hi,
>>>>=20
>>>> On Mar 9, 2012, at 8:52 PM, Robert Sparks wrote:
>>>>=20
>>>>> I think we must be talking past each other. That suggestion =
doesn't
>>>> look different than what's in -30, and
>>>>> doesn't address the point I made in the message you responded to.
>>>>>=20
>>>>> Let me try this a different way. The text in -30 and the text you
>>>> propose below say that it's OK for
>>>>> an operator to have deployed a "conformant" diameter =
implementation
>>>> and later discover that he
>>>>> can't use the DNS-based peer discovery mechanism without acquiring
>>>> another one (or going back to
>>>>> the original provider for a code change). Is that really what the
>>>> group concluded? That would surprise me,
>>>>=20
>>>> Vendors can always build a nice licensing scheme around this ;-)
>>>>=20
>>>> I could be OK with "MUST implement, MAY use" for DNS-based peer
>>>> discovery
>>>> if that is what WG wants. The issue I have in general with "MUST" =
in
>>>> current
>>>> DNS-based peer discovery is its limited usability in deployments. A
>>>> peer does
>>>> (S-)NAPTR/SRV query for another domain (realm) and finds an address
>> etc
>>>> of
>>>> its node representing the entire realm. However, this does not help
>> me
>>>> if
>>>> there are intermediates that my requests must go through e.g. =
before
>>>> leaving
>>>> my own realm. It then ends up only specific type of nodes (like =
edge
>>>> agents
>>>> of some administrative domain) even needing DNS functionality for
>> DNS-
>>>> based
>>>> dynamic peer discovery.
>>>>=20
>>>> Anyway, as said, I am mostly open for anything.
>>>>=20
>>>>=20
>>>>> and I'd like to read the discussion so I can see how the group
>> landed
>>>> there.
>>>>>=20
>>>>> I could see a decision that would say that manual configuration
>> still
>>>> needs to be an option available to the operator.
>>>>=20
>>>> Yes. Manual is must.
>>>>=20
>>>> - Jouni
>>>>=20
>>>>>=20
>>>>> RjS
>>>>>=20
>>>>> On 3/9/12 11:12 AM, lionel.morand@orange.com wrote:
>>>>>> What about:
>>>>>>=20
>>>>>> "A Diameter implementation MUST include the first option (manual
>>>> configuration) and MAY [or "SHOULD" if preferred] include the =
latter
>>>> option (DNS)."
>>>>>>=20
>>>>>> Lionel
>>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la
>> part
>>>> de Robert Sparks
>>>>>> Envoy=E9 : vendredi 9 mars 2012 16:20
>>>>>> =C0 : jouni korhonen
>>>>>> Cc : dime@ietf.org
>>>>>> Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory
>>>> toimplement?
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 3/9/12 2:17 AM, jouni korhonen wrote:
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> On Mar 9, 2012, at 5:01 AM, Glen Zorn wrote:
>>>>>>>=20
>>>>>>>> On 3/9/2012 3:02 AM, Robert Sparks wrote:
>>>>>>>>> Question: Is the DNS-based peer discovery mechanism mandatory
>> to
>>>> implement?
>>>>>>>>>=20
>>>>>>>>> The first paragraph of 5.2 speaks in terms of "supported" and
>> if
>>>> you
>>>>>>>>> read that to mean "implemented" the answer is no, but after
>>>> talking to
>>>>>>>>> some folks I'm not sure that was the intent. Was the intent
>>>> mandatory to
>>>>>>>>> implement, optional to use?
>>>>>>>> Good question.  The text in question uses the term "Diameter
>>>> node",
>>>>>>>> which is a computer actually running Diameter, so my take on it
>>>> would be
>>>>>>>> that the node might not support the option (in terms of =
actually
>>>> using
>>>>>>>> it)but that the option would nevertheless be available (i.e.,
>>>>>>>> implemented).  It seems like the text could be clearer though =
--
>>>> any
>>>>>>>> suggestions?
>>>>>> It's not sufficient to rely on the underlying computer having DNS
>>>> libraries.
>>>>>> You specified DIAMETER specific logic - the person that wrote the
>>>>>> diameter code
>>>>>> is going to have to write code - it might _use_ a DNS library on
>> an
>>>>>> underlying
>>>>>> OS, but it's the DIAMETER code that's going to have to provide =
the
>>>>>> inputs to the
>>>>>> NAPTR queries, (or SRV queries, if starting at that level), and
>>>> follow
>>>>>> the rules in
>>>>>> this document on interpreting the results. _Thats_ the code that
>>>> needs
>>>>>> to be mandatory
>>>>>> to implement.
>>>>>>> How about:
>>>>>>>=20
>>>>>>>    ..
>>>>>>>    discovery, the following mechanisms are described.  These are
>>>> based
>>>>>>>    on existing IETF standards.  The first option (manual
>>>> configuration)
>>>>>>>    MUST be implemented and supported by all Diameter nodes,
>> while
>>>> the
>>>>>>>    latter option (DNS) MAY be implemented and MAY be supported
>> by
>>>>>>>    Diameter nodes.
>>>>>>>=20
>>>>>>> However, we could also try to make DNS option more widely used,
>>>> since
>>>>>>> every box in practice has to have some level of DNS resolver
>>>> capability:
>>>>>>>=20
>>>>>>>    ..
>>>>>>>    MUST be implemented and supported by all Diameter nodes,
>> while
>>>> the
>>>>>>>    latter option (DNS) SHOULD be implemented and if implemented
>>>> MAY be
>>>>>>>    used by Diameter nodes.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Opinions?
>>>>>>>=20
>>>>>>>=20
>>>>>>> - Jouni
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> That would ensure that an operator had the
>>>>>>>>> option to start using the DNS-based discovery mechanism when =
it
>>>> was the
>>>>>>>>> right thing to do.
>>>>>>>>>=20
>>>>>>>>> RjS
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> DiME mailing list
>>>>>>>>> DiME@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>>> _______________________________________________
>>>>>>>> DiME mailing list
>>>>>>>> DiME@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>> _______________________________________________
>>>> 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
>=20


From jouni.nospam@gmail.com  Tue Mar 13 12:05:26 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D6B21E8069 for ; Tue, 13 Mar 2012 12:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.417
X-Spam-Level: 
X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.182,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h10MLTMip+pG for ; Tue, 13 Mar 2012 12:05:25 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E64921E8064 for ; Tue, 13 Mar 2012 12:05:24 -0700 (PDT)
Received: by lagj5 with SMTP id j5so923371lag.31 for ; Tue, 13 Mar 2012 12:05:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=G6xGvJ+E5cbNGEHZqNWweVrKCV2zdKsR991Mp/8lz8U=; b=eGmb/SMRPfy9N+q/V3IHw3kWH++ID1pyYBPNNQEKv/5tV3G9fA7r60zFfFnEMTmTFx wBSUghFHzlD3z9lOahKtI2DlgAUOaRBm/XHBeV3zjwUa/uDCVgjO2BYOZiUkUMSJx9T4 mhnbOwEnu1LMjpeAxxEB/ysCI7GaeSXZOpQWB6dHOZ7fb3m2PQ0U0fgs8/BYv2Tjv2BN U7v15jo4LborsCOPPwFH9P/T5sXYVdmuOYRkLDbjtVHRlRqXgoQisKXY4j5xHVkwR5Q/ Mg+Ye95uEiBrtyI6a6XuI5xgHMeWR0urxgaXkWh9yqu5Oa2qN5vNHMMP49E4g+5dQGra jNqg==
Received: by 10.112.37.195 with SMTP id a3mr6850471lbk.18.1331665524012; Tue, 13 Mar 2012 12:05:24 -0700 (PDT)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id n6sm1528028lbn.11.2012.03.13.12.05.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 12:05:23 -0700 (PDT)
From: jouni korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 13 Mar 2012 21:05:21 +0200
Message-Id: <3CF6925D-3566-44C8-BEC3-51038735D088@gmail.com>
To: dime@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Dime] Paris meeting logistics
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Mar 2012 19:05:26 -0000

Folks,

In order to make the meeting start smoothly and in a timely manner
we solicit for note takers and a jabber scribe already now. If you
feel like volunteering just drop a mail to chairs.

- Jouni & Lionel

From jouni.nospam@gmail.com  Tue Mar 13 12:29:30 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F340221F8688 for ; Tue, 13 Mar 2012 12:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uwzDOzp51UE for ; Tue, 13 Mar 2012 12:29:29 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12A0721F8683 for ; Tue, 13 Mar 2012 12:29:28 -0700 (PDT)
Received: by lbol12 with SMTP id l12so506934lbo.31 for ; Tue, 13 Mar 2012 12:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=MZTBkxBEfNp0WznDb2NfBSW7R4PHfMvN2sM7bi3KvHU=; b=bGR3+oe3Q2QeSQLu2TtllQj1oQm9FfK7rN2OadBs48U7pKi6E9Eb+fNo/EwXfElkv0 tvmDeZFKIBxw013gL13AjCS61reWBx8rcz5ZQR1LCvPe8pmn3F8jULQJ05aNVNEJFkHx zBycAMQZJuofhCFbKd+yEgW3HvgKFzPDC6Z422bAHyrlqO2oZ64/wn6gr+s2GlzcEfJW y3ljP2P1SIcVqquIM0tPMfN3+2Q9JuP24MN0qkE3V1eKXw77Cd8BJpe6rTUV5VCYlIzp RX0OezwOWI61n05HJnuf3wyPrcN8qtvM4j1FqarvaamXFUV6V5YShBw2xyN1XgDxyn5n Pz7Q==
Received: by 10.112.29.200 with SMTP id m8mr6662075lbh.44.1331666968025; Tue, 13 Mar 2012 12:29:28 -0700 (PDT)
Received: from a88-114-7-204.elisa-laajakaista.fi (a88-114-7-204.elisa-laajakaista.fi. [88.114.7.204]) by mx.google.com with ESMTPS id b3sm1612265lby.7.2012.03.13.12.29.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 12:29:27 -0700 (PDT)
From: jouni korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 13 Mar 2012 21:29:23 +0200
Message-Id: <86BA4C87-FB21-4A54-9908-0A95A0066377@gmail.com>
To: dime@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Dime] draft agenda uploaded
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Mar 2012 19:29:30 -0000

Folks,

Draft agenda is now available:
http://www.ietf.org/proceedings/83/agenda/agenda-83-dime.txt

- Jouni & Lionel

From internet-drafts@ietf.org  Mon Mar 26 01:34:29 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7638621F8596; Mon, 26 Mar 2012 01:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.48
X-Spam-Level: 
X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOCGxy+r4BJG; Mon, 26 Mar 2012 01:34:28 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBE221F8437; Mon, 26 Mar 2012 01:34:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120326083428.9875.61128.idtracker@ietfa.amsl.com>
Date: Mon, 26 Mar 2012 01:34:28 -0700
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-15.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Mar 2012 08:34:29 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Diameter Maintenance and Extensions W=
orking Group of the IETF.

	Title           : Diameter Network Address and Port Translation Control Ap=
plication
	Author(s)       : Frank Brockners
                          Shwetha Bhandari
                          Vaneeta Singh
                          Victor Fajardo
	Filename        : draft-ietf-dime-nat-control-15.txt
	Pages           : 61
	Date            : 2012-03-26

   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 networks to cope with IPv4-address
   space depletion.  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-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-15.txt


From deepu000@gmail.com  Mon Mar 26 10:33:25 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D6621E8101 for ; Mon, 26 Mar 2012 10:33:25 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV+etP+uxw4p for ; Mon, 26 Mar 2012 10:33:25 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 175AC21E8100 for ; Mon, 26 Mar 2012 10:33:21 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so4476401ghb.31 for ; Mon, 26 Mar 2012 10:33:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=8bBNSi6nqb3k/V+/SBKq9rRpOb1ktFNLxmC7vKoX+kk=; b=fsuLESRLDI47n7g6SkKmli5bqKSC5+7GqaL+FKBI/rmYAbVRHIoG9fOKWlKpLiXmhL Z3QJeTDrMqEBmVXNhiW2U+R6R5gLmRnyJmbETMaSyXNkSG9NS5e8GSgngoKc3wpp9jpZ 6uTiDsccQusrZCmmeQ4U5RqPeJIrFNUSU3J32OOyHF74a5tkEkfvxoTSZfxvGCp7YO3I u1auDEVmyS5r3dxpExasqeI2Yn0uvJ0Tsa94E6WYraRCbxe2Q4ZuyaN3VSxzjoBCwlut mYKhwoqiu+0bpuYBigZnqp/ZtjcHnUu1jpGQGw0YuVnfADIBVh762aVGLS2e86mKNoyB pZxw==
Received: by 10.68.224.195 with SMTP id re3mr54769386pbc.90.1332783200853; Mon, 26 Mar 2012 10:33:20 -0700 (PDT)
Received: from [115.241.104.230] ([115.241.104.230]) by mx.google.com with ESMTPS id ko12sm12929703pbb.52.2012.03.26.10.33.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Mar 2012 10:33:20 -0700 (PDT)
From: Deepu Mathew 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Mar 2012 23:03:10 +0530
Message-Id: <53C4895A-AEEB-4FA2-83BA-CE3684CADC60@gmail.com>
To: dime@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Dime] Working Group Mailing List - RFC 4006
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Mar 2012 17:37:36 -0000

Hi,

I am currently working on Credit Control Application and have some =
doubts regarding RFC 4006.=20
So can you please let me know the working Group Mailing List for RFC =
4006?

Thanks
Deepu=

From deepu000@gmail.com  Mon Mar 26 10:42:37 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1904321E80DF for ; Mon, 26 Mar 2012 10:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.458
X-Spam-Level: 
X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsZ6enK2Mwl6 for ; Mon, 26 Mar 2012 10:42:36 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1524021F8467 for ; Mon, 26 Mar 2012 10:42:36 -0700 (PDT)
Received: by yenm5 with SMTP id m5so4480681yen.31 for ; Mon, 26 Mar 2012 10:42:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=guh/fzp+WyObDM1L1KZ9fEvuR1LBfv+6MaRxfBhOLuk=; b=js5HOTOxk9y9Gsl/HL5z0jXuI0pn0rQ8PzMTdfLeag429jN1RtcvRVr7SORlTovwVw DUpgqhHonrzDItBYpvO6G8TyzZ7gC+z9/MaxpZeHWCJCZDTY//15DMc64aDiLyeQzSHF QKClSa6MjaaQKTR9vKrzFF60IoUGaq/LISY8D6l0XRQNfGESdf4QZzVl/Jjr7U5AX+3m B/YZHiWKSMPvq5thLAtgx2d9t4SVKQMys/FeTXAnqe84NQOEsT/++WACmKJlVNYbVQA5 Jiuh4JiLC1YYTnxQh0a2YWH6Om/ap39yiWejGkZmF1Y6Ds+RLg+olGrCoxdN+eny+Y2X v0JQ==
Received: by 10.68.129.74 with SMTP id nu10mr54722749pbb.157.1332783755380; Mon, 26 Mar 2012 10:42:35 -0700 (PDT)
Received: from [115.241.104.230] ([115.241.104.230]) by mx.google.com with ESMTPS id o2sm12939710pbq.61.2012.03.26.10.42.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Mar 2012 10:42:34 -0700 (PDT)
From: Deepu Mathew 
Content-Type: multipart/alternative; boundary=Apple-Mail-5-141746306
Date: Mon, 26 Mar 2012 23:12:28 +0530
Message-Id: 
To: dime@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Dime] RFC - 4006 Clarifications
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Mar 2012 17:42:37 -0000

--Apple-Mail-5-141746306
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

I am trying to enhance the OCS functionality to involve Multi Service =
Session Scenarios using Credit Control Application for my current =
product but, I got stuck in the research activity due to certain =
confusions regarding  A.9 Flow IX:

Below are my concerns,
1. How is the multiplier derived and what is its significance? How will =
it work in case of tiered plans?
2. On what basis Services are allocated to the Credit Pool?
3. Does services in a pool be able to consume quota which was actually =
allocated to the other member services?
4. Why was Service 4 terminated soon after giving the credit and Service =
3 allowed to continue as free?

It would be great if you can provide some assistance with this as I am =
bit confused with the above questions. Kindly let me know in case this =
is not the correct mailing list who owns this RFC.

Thanks in Advance
Deepu




--Apple-Mail-5-141746306
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Hi,
I am trying to enhance =
the OCS functionality to involve Multi Service Session Scenarios using =
Credit Control Application for my current product but, I got stuck =
in the research activity due to certain confusions regarding  A.9 =
Flow IX:

Below are my =
concerns,
1. How is the =
multiplier derived and what is its significance? How will it work in =
case of tiered plans?
2. On what basis =
Services are allocated to the Credit Pool?
3. =
Does services in a pool be able to consume quota which was actually =
allocated to the other member services?
4. =
Why was Service 4 terminated soon after giving the credit and Service 3 =
allowed to continue as free?

It would be =
great if you can provide some assistance with this as I am bit confused =
with the above questions. Kindly let me know in case this is not the =
correct mailing list who owns this RFC.

Thanks in Advance
Deepu


=

--Apple-Mail-5-141746306--

From bclaise@cisco.com  Thu Mar 29 06:56:40 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04C621F8B7A for ; Thu, 29 Mar 2012 06:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level: 
X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V03Gy7Gtu83 for ; Thu, 29 Mar 2012 06:56:40 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D8C2B21F8973 for ; Thu, 29 Mar 2012 06:56:39 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2TDtZB6015585 for ; Thu, 29 Mar 2012 15:55:36 +0200 (CEST)
Received: from [10.61.98.92] (dhcp-10-61-98-92.cisco.com [10.61.98.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q2TDtZ0H002641 for ; Thu, 29 Mar 2012 15:55:35 +0200 (CEST)
Message-ID: <4F7469D7.3000000@cisco.com>
Date: Thu, 29 Mar 2012 15:55:35 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: multipart/alternative; boundary="------------060305050105000706020601"
Subject: [Dime] draft-ietf-dime-realm-based-redirect-04: Updates: RFC 3588?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Mar 2012 13:56:40 -0000

This is a multi-part message in MIME format.
--------------060305050105000706020601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Internet Engineering Task Force                                   T. Tsou

Internet-Draft                                  Huawei Technologies (USA)

Updates: RFC 3588 (if approved)                            T. Taylor, Ed.

Intended status: Standards Track                      Huawei Technologies

Expires: July 14, 2012                                   January 11, 2012

  

  

                   Realm-Based Redirection In Diameter

                 draft-ietf-dime-realm-based-redirect-04



When I saw "update RFC3588", I was wondering: should it be "Updates: RFC 
3588bis"?
And actually, is this "update" keyword required at all?

Regards, Benoit.


--------------060305050105000706020601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    
    
    
Internet Engineering Task Force                                  T. Tsou

    
Internet-Draft                                 Huawei Technologies (USA)

    
Updates: RFC 3588 (if approved)                           T. Taylor, Ed.

    
Intended status: Standards Track                     Huawei Technologies

    
Expires: July 14, 2012                                  January 11, 2012

    
 

    
 

    
                  Realm-Based Redirection In Diameter

    
                draft-ietf-dime-realm-based-redirect-04

    
    
    
    
    
    
    

    

    When I saw "update RFC3588", I was wondering: should it be "Updates:
    RFC 3588bis"?

    And actually, is this "update" keyword required at all?

    

    Regards, Benoit.

    

  


--------------060305050105000706020601--

From tom.taylor.stds@gmail.com  Thu Mar 29 11:48:44 2012
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB8121F8602 for ; Thu, 29 Mar 2012 11:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku5sBf6J+u-h for ; Thu, 29 Mar 2012 11:48:44 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A778321F85F3 for ; Thu, 29 Mar 2012 11:48:43 -0700 (PDT)
Received: by eeke51 with SMTP id e51so1358078eek.31 for ; Thu, 29 Mar 2012 11:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Vquxd7ldq6IMDprI2/Lv8BFeZGp/cNd7rH+X+fhi8g8=; b=l+4MO60iKWzzmqRvNXfP9GNs2/6TXNE+sQM29fxo3INNXtnHekRtVsE6X76IoiFqY8 cBYLN5jqDFHZRJrZvPiD4hzZ1ZN4xggUVzkYkVYzsJr98ge0wknt4uU5OgWidByjajzg Jd9JJKqFbkUbXAAmxmHp0W9SToYPEMClL8O2SLSVE6jibIGhxNiZhvCWaS4qBY1YAu4m lThrz65VmJaZiwBbiB//4l3MEdXeSMVqch3qCwRad/MLlwit7/ROfTU7o+vXlPntuTKV xnc+er35/vxwmNW74mPZPAPLFmYbSeoFQRTl2CvmCrLuReXruyG5jd1fi73/KUKduylk ip4g==
Received: by 10.213.105.143 with SMTP id t15mr194021ebo.133.1333046922843; Thu, 29 Mar 2012 11:48:42 -0700 (PDT)
Received: from [192.168.115.216] (LRouen-151-71-51-72.w80-11.abo.wanadoo.fr. [80.11.226.72]) by mx.google.com with ESMTPS id p57sm24331729eei.8.2012.03.29.11.48.37 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 11:48:41 -0700 (PDT)
Message-ID: <4F74AE81.70802@gmail.com>
Date: Thu, 29 Mar 2012 20:48:33 +0200
From: Tom Taylor 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: dime@ietf.org
References: <4F7469D7.3000000@cisco.com>
In-Reply-To: <4F7469D7.3000000@cisco.com>
Content-Type: multipart/alternative; boundary="------------090400050002000000050106"
Subject: Re: [Dime] draft-ietf-dime-realm-based-redirect-04: Updates: RFC 3588?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Mar 2012 18:48:45 -0000

This is a multi-part message in MIME format.
--------------090400050002000000050106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The justification was that it was modifying behaviour specified in 3588. 
Your point regarding 3588bis is reasonably well taken given the advanced 
state of that document.

I have to apologize for not showing up thius afternoon. I was tied up at 
hospital -- a strange case of a booby-trapped boot (or at least, 
contaminated, but that doesn't read so smoothly). Basically, I've 
responded to previous WGLC review comments and wonder if we could 
continue WGLC.

On 12-03-29 03:55 PM, Benoit Claise wrote:
> Dear all,
>
> Internet Engineering Task Force                                   T. Tsou
> Internet-Draft                                  Huawei Technologies (USA)
> Updates: RFC 3588 (if approved)                            T. Taylor, Ed.
> Intended status: Standards Track                      Huawei Technologies
> Expires: July 14, 2012                                   January 11, 2012
>   
>   
>                    Realm-Based Redirection In Diameter
>                  draft-ietf-dime-realm-based-redirect-04
>
>
> When I saw "update RFC3588", I was wondering: should it be "Updates: 
> RFC 3588bis"?
> And actually, is this "update" keyword required at all?
>
> Regards, Benoit.
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------090400050002000000050106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    The justification was that it was modifying behaviour specified in
    3588. Your point regarding 3588bis is reasonably well taken given
    the advanced state of that document.

    

    I have to apologize for not showing up thius afternoon. I was tied
    up at hospital -- a strange case of a booby-trapped boot (or at
    least, contaminated, but that doesn't read so smoothly). Basically,
    I've responded to previous WGLC review comments and wonder if we
    could continue WGLC.

    

    On 12-03-29 03:55 PM, Benoit Claise wrote:
    

      
      Dear all,

      

      
      
      
Internet Engineering Task Force                                  T. Tsou

      
Internet-Draft                                 Huawei Technologies (USA)

      
Updates: RFC 3588 (if approved)                           T. Taylor, Ed.

      
Intended status: Standards Track                     Huawei Technologies

      
Expires: July 14, 2012                                  January 11, 2012

      
 

      
 

      
                  Realm-Based Redirection In Diameter

      
                draft-ietf-dime-realm-based-redirect-04

      
      
      
      
      
      
      

      

      When I saw "update RFC3588", I was wondering: should it be
      "Updates: RFC 3588bis"?

      And actually, is this "update" keyword required at all?

      

      Regards, Benoit.

      

      

      

      

      
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


    

    

  


--------------090400050002000000050106--