From jouni.nospam@gmail.com Mon Aug 2 03:23:35 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBD83A6AAC for ; Mon, 2 Aug 2010 03:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhM8BxrWjE8J for ; Mon, 2 Aug 2010 03:23:34 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 64ADE3A69CA for ; Mon, 2 Aug 2010 03:22:31 -0700 (PDT) Received: by bwz7 with SMTP id 7so2104846bwz.31 for ; Mon, 02 Aug 2010 03:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=UH1Hll0tk5P4G0rpcv/T3H9jTZW7+P6jih8gdOaAReg=; b=bJlqhAxbIGNVU8IV1uPjAs4ofKiqKtPA1W8zFSWCV3yovVWStzl1R7C+FaJAYcdkFm vEZmsZ8Kfm+W2deFE240AKObIUDI3h9dKW3SZmnmrk4I7as79nBLazwEaw9Y3w6ybfOC GsOHjr6D0b7eEGiJpgVfXvW/KtXeSwF0+1edg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=TuEPlRQKqC+3toSBpOF6rUz5f1xMh43NDAP3NSVGyfxccYZO8FfqwoTZ+xVXJwoHrk tkAat8WpFAnOuduvr5Uwy2Lur6pk8Tw/ixnvxIaiQh76O+Y/jcQi9/PlDTBidE1fV1fP sb6SlVLNnXlh6hLup2ha6p1xMcHPxcMUotz2I= Received: by 10.204.77.212 with SMTP id h20mr4056580bkk.33.1280744578072; Mon, 02 Aug 2010 03:22:58 -0700 (PDT) Received: from a88-114-70-243.elisa-laajakaista.fi (a88-114-70-243.elisa-laajakaista.fi [88.114.70.243]) by mx.google.com with ESMTPS id s17sm3985519bkx.6.2010.08.02.03.22.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 03:22:57 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Aug 2010 13:22:56 +0300 Message-Id: <802ECC3D-32E0-4A23-81CF-8EF28D28303C@gmail.com> To: dime@ietf.org, draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] WGLC starting for draft-ietf-dime-ikev2-psk-diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 10:23:35 -0000 A two weeks WGLC for Diameter IKEv2 PSK = (draft-ietf-dime-ikev2-psk-diameter-02) starts as of today 2-Aug-2010 = and ends on Monday 16-Aug-2010 23:59 (CEST+1). We _require_ at least three reviews from people who are not authors of = the document. In case of an inadequate review success, we'll just keep = the document in the WG and go for another WGLC later (that will again = need a new set of three reviews ;). So lobby people to review! - Jouni & Lionel= From jouni.nospam@gmail.com Mon Aug 2 03:25:36 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11EBE3A69E0 for ; Mon, 2 Aug 2010 03:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bemdle8LoTJ for ; Mon, 2 Aug 2010 03:25:35 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D14293A69CE for ; Mon, 2 Aug 2010 03:25:34 -0700 (PDT) Received: by bwz7 with SMTP id 7so2106319bwz.31 for ; Mon, 02 Aug 2010 03:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=stnzXGb7nRxNQJn+/5HIZlQZAEtIJqrleyLpzpPaP9I=; b=mSRn56pljYRAnWKBhRGJF8/WsTRC1SWinH1+HGPDySBjXwKKdgR7z6ZREV+VPJ3asD yKiWiOv2cqDeND+hSB06lP3CFEUq3Y8KEUcuV74RhC340Kw1SiPUvKFAXQeKyxB2Mn1h Kw/tXpI8oA7GayN4RmYmIy4kpxi7AJZmVMLVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=nBtbarUOwXtY1XfEvlS7siE952k7nd5e1NxAYg4CcbGk9L92JhKcvDxR70rrHENMgY emF4MwHfP1hQOCe5e80doh8nLVk+rdbS0D3/NHJZP2etbs1t21YFlXJJ6xbdIvvkghL+ 7N5dCbvCkb4qWGEIE/Ad+GF054gEmVajtXpHk= Received: by 10.204.34.133 with SMTP id l5mr3953399bkd.180.1280744761778; Mon, 02 Aug 2010 03:26:01 -0700 (PDT) Received: from a88-114-70-243.elisa-laajakaista.fi (a88-114-70-243.elisa-laajakaista.fi [88.114.70.243]) by mx.google.com with ESMTPS id bq20sm3988262bkb.4.2010.08.02.03.26.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 03:26:01 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Aug 2010 13:26:00 +0300 Message-Id: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> To: dime@ietf.org, draft-ietf-dime-realm-based-redirect@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] WGLC starting for draft-ietf-dime-realm-based-redirect X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 10:25:36 -0000 A two weeks WGLC for Realm-Based Redirection In Diameter = (draft-ietf-dime-realm-based-redirect-03) starts as of today 2-Aug-2010 = and ends on Monday 16-Aug-2010 23:59 (CEST+1). We _require_ at least three reviews from people who are not authors of = the document. In case of an inadequate review success, we'll just keep = the document in the WG and go for another WGLC later (that will again = need a new set of three reviews ;). So lobby people to review! - Jouni & Lionel= From jouni.nospam@gmail.com Mon Aug 2 03:27:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38AD3A698D for ; Mon, 2 Aug 2010 03:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkTKviLfOsWB for ; Mon, 2 Aug 2010 03:27:28 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7C7563A69E0 for ; Mon, 2 Aug 2010 03:27:26 -0700 (PDT) Received: by bwz7 with SMTP id 7so2107175bwz.31 for ; Mon, 02 Aug 2010 03:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=UksKnk7PUsbE5Lu6N9AkdHbEKYAmXQqUUX4vAvLs6nA=; b=keiKAGmeZCj8FsTRkWJirfUvIxie8H3wcoRKpp+s7m/E5bMLEloI1JYidclZEZVYDj 2nbVPzGa+R/EKFyZNTJBxKifvpd8PIjmok6V0Qrz+hekp9McjkTHw0iSDV7N+SXsaUkA o2p+6L+8pai0oEGSEokrxCL8AKc81gtGxmgNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=Tne/XL9JPVH1+jY8oQ5mBiQ16vFgp3J15ZfGGyVpO/+NM+MF+/L5VsCnbtgdyveJZF 0YWmxrWgMFzw4sWZLafnvKU8RfZprRnxskLXpCPfJ+m+Po3vX1uHk0qg91BDra57MXVC Hxxp94F0At6yB9wHELZGytasP9S5cwBtPXtCo= Received: by 10.204.131.132 with SMTP id x4mr4051873bks.50.1280744873427; Mon, 02 Aug 2010 03:27:53 -0700 (PDT) Received: from a88-114-70-243.elisa-laajakaista.fi (a88-114-70-243.elisa-laajakaista.fi [88.114.70.243]) by mx.google.com with ESMTPS id y2sm3987644bkx.8.2010.08.02.03.27.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 03:27:52 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Aug 2010 13:27:51 +0300 Message-Id: To: dime@ietf.org, draft-ietf-dime-nat-control@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] WGLC starting for draft-ietf-dime-nat-control X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 10:27:29 -0000 A two weeks WGLC for Diameter Network Address and Port Translation = Control Application (draft-ietf-dime-nat-control-03) starts as of today = 2-Aug-2010 and ends on Monday 16-Aug-2010 23:59 (CEST+1). We _require_ at least three reviews from people who are not authors of = the document. In case of an inadequate review success, we'll just keep = the document in the WG and go for another WGLC later (that will again = need a new set of three reviews ;). So lobby people to review! - Jouni & Lionel= From jouni.nospam@gmail.com Mon Aug 2 03:32:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25643A6AA7 for ; Mon, 2 Aug 2010 03:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orAk4EDVMjkI for ; Mon, 2 Aug 2010 03:31:32 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4C7513A6A6F for ; Mon, 2 Aug 2010 03:30:50 -0700 (PDT) Received: by bwz7 with SMTP id 7so2108797bwz.31 for ; Mon, 02 Aug 2010 03:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=2lUpzHlk0bYv4bHWM57elJIo77U4Wq++dJBmbOWKlAQ=; b=F11t3Pmmk+WzhlacRryZYtPgq9xQ4lsQIIl1RMBz9E+2MKDd1WlCQkZglA84t/JDvB FIYMMJgWSAEOPcZf0AJEH1D7x7lqBYwVnVSWazlPzGSV4H3w5YJ11Cnwqysew+sLqKFg q1KCaTCQ0beEUBvd2Ir1JPI3UuXvUda+/islg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=NFA2V62YJJSgOdwvea3q+4TEJo/BVegtz+IDxQUlcjVP1WlnYtTRylOD/w3/DU5acP xheecSW9ZnoTfiAjOok5bxnZNWSR0pLDkjRuBH6W+82Z/0jlKspnV5TT5Q+/cQPQyqta oAuP5Hlt94k0N5xoC/PZMe7CXcTz3xKElWUw4= Received: by 10.204.13.72 with SMTP id b8mr3886916bka.190.1280745073696; Mon, 02 Aug 2010 03:31:13 -0700 (PDT) Received: from a88-114-70-243.elisa-laajakaista.fi (a88-114-70-243.elisa-laajakaista.fi [88.114.70.243]) by mx.google.com with ESMTPS id g11sm3989735bkw.10.2010.08.02.03.31.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 03:31:12 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Aug 2010 13:31:12 +0300 Message-Id: <68E84348-530B-4FCD-8383-E60A167BF941@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] DIME WG status update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 10:32:29 -0000 X-List-Received-Date: Mon, 02 Aug 2010 10:32:29 -0000 Hi all, Maastricht IETF 78 is over and I think we had a successful DIME WG = meeting there. Below is a short status update of DIME WG. The status = update slides presented during the meeting can be found here: = http://tools.ietf.org/agenda/78/slides/dime-0.pdf. The actual meeting = notes will follow a bit later. See also our wiki pages at: = http://trac.tools.ietf.org/wg/dime/trac/wiki. --- Documents stable enough for a WGLC * draft-ietf-dime-ikev2-psk-diameter (WGLC started 2-Aug-2010, ends = 16-Aug-2010) * draft-ietf-dime-realm-based-redirect (WGLC started 2-Aug-2010, ends = 16-Aug-2010) * draft-ietf-dime-nat-control (WGLC started 2-Aug-2010, ends = 16-Aug-2010) Documents recently sent to IESG: * draft-ietf-dime-capablities-update Documents currently in IESG: * draft-ietf-dime-diameter-base-protocol-mib (AD Evaluation::Revised ID = Needed) * draft-ietf-dime-diameter-cc-appl-mib-03 (AD Evaluation::Revised ID = Needed) Documents waiting for Proto Write-up to be completed: * draft-ietf-dime-rfc3588bis (Jouni has some editorial comments that = need to be addressed, but otherwise the Proto Write-Up is coming = asap) * draft-ietf-dime-priority-avps * draft-ietf-dime-local-keytran New WG document adoption (pending the official confirmation on the = mailing list): * draft-zorn-dime-rfc4005bis Pending Errata: * RFC4005: #1942: OK. Errata will be published and should be later = caputre in RFC4005bis. * RFC 5777: #2333/4/5/6: Reviewed by the authors. OK * RFC 5777: #2337 waiting for errata submitter's response. Charter: * Milestones must be updated according to works achieved so far and = missing WG document * We'll start considering new WG work at the next meeting AOB: * We will start using issue tracker for documents in WGLC --- - Jouni & Lionel= From jouni.nospam@gmail.com Mon Aug 2 03:53:56 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD493A69B6 for ; Mon, 2 Aug 2010 03:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSkQWgBbuecm for ; Mon, 2 Aug 2010 03:53:55 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0A8893A6859 for ; Mon, 2 Aug 2010 03:53:54 -0700 (PDT) Received: by bwz7 with SMTP id 7so2119223bwz.31 for ; Mon, 02 Aug 2010 03:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=Y8Jj94ybxf6rQYpRD+OoGQLPvIFniu272b79BvsgRKw=; b=vv3+G8b3KoCXfWzXprxwR8OTTCzCGb4VVkn6Pd04pstbrmF1nYvqxQ2vF3d3KmTJ/E +mL2w1UWWckW0fSVgRsnAvSHJT269pV75FtiIXuipEcHFtmdbBQl8OEO80W0GDUHlWfm giFvNMZ26+SyHuguDRN0gqHKG5uNjCdVlGKAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=G6HiCSAxdSHdevERksJ7wI/2R4TxQzfh2XS5pa4mtiTUC4w/ZttMlb9KcZiPUs8WY9 5mx9/3KxlxMuGty1JwCFjB9n2VVcbHlTnI+fFYC4jJzLtcGgx0/m8efM1EYS1S2TTXIR YdsYWfzBF2JCnuQN/xcNyasjO4F36UUktnj7k= Received: by 10.204.101.72 with SMTP id b8mr3894837bko.192.1280746461760; Mon, 02 Aug 2010 03:54:21 -0700 (PDT) Received: from a88-114-70-243.elisa-laajakaista.fi (a88-114-70-243.elisa-laajakaista.fi [88.114.70.243]) by mx.google.com with ESMTPS id o20sm4007731bkw.3.2010.08.02.03.54.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 03:54:21 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Aug 2010 13:54:19 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 10:53:56 -0000 As discussed during the Maastricht DIME WG meeting, the chairs agreed to = confirm the adoption of draft-zorn-dime-rfc4005bis-01 as the WG Item. = The work regarding RFC4005bis has been around the corner for some time = and discussed several times among AAA Doctors. There was support for the = adoption during the WG meeting. The one week poll ends 9-Aug-2010, 23:59 (CEST+1).. Silence counts also = as "yes", so unless you have a strong reason to disagree (like the North = Pole melts or Diameter will become obsolete due the adoption of this = draft), then express your "no" on the list with a proper reasoning why. = Technical details on the actual draft content can be handled later = (if/when the document gets adopted). - Jouni & Lionel= From jouni.nospam@gmail.com Mon Aug 2 04:56:07 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DBF3A6BF2 for ; Mon, 2 Aug 2010 04:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl8wba26mrfz for ; Mon, 2 Aug 2010 04:56:06 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 096223A6BF8 for ; Mon, 2 Aug 2010 04:56:05 -0700 (PDT) Received: by bwz7 with SMTP id 7so2149103bwz.31 for ; Mon, 02 Aug 2010 04:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=l/SsT/eC/vsudpNhVYrngYcOlvQhkg0fl1vwIIMNyQw=; b=fqYEcDFNd09a2b+uipRk+BzbvgaPhS4jCFZQB90qF1KDhq5QhAXOnZ2xuAi8rSGIh2 a1zDqH02ZgRX/6HX7UKadS1fg1RhsAR8j0+EYKqpeV5jfqYQ0Y1lQKQdUdb/YsqrX8+B +FJO0JJIq1hQAd64eHNPFotNkjdAJUnfNlQ1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=gdZ3G4oZYGs3fw25lmGmFTyEjiN54qPFwBQoO5QAJVTSqcBeEbRQdcXB2m8vd3+iTg 5m/V1kov+gDXu1osIkyRDC1Sf5g23G3rXDBy+g4SZSxbXnT07osWy1QmoWVWUzlghndc Pk82KD296dkBPI4RTmgR6sW1ugzllhCYKNY/U= Received: by 10.204.126.161 with SMTP id c33mr4082682bks.108.1280750192967; Mon, 02 Aug 2010 04:56:32 -0700 (PDT) Received: from a88-114-70-243.elisa-laajakaista.fi (a88-114-70-243.elisa-laajakaista.fi [88.114.70.243]) by mx.google.com with ESMTPS id a11sm4052789bkc.0.2010.08.02.04.56.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 04:56:32 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 2 Aug 2010 14:56:31 +0300 Message-Id: <75C65636-C80F-4B84-8B4D-E6F1197BCEE3@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] DIME meeting notes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 11:56:07 -0000 Can be found here: http://www.ietf.org/proceedings/78/minutes/dime.txt Thanks to Tom Taylor for taking the notes! - Jouni From gwz@net-zen.net Mon Aug 2 08:48:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6176F3A68E0 for ; Mon, 2 Aug 2010 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id advq8KTyHR2v for ; Mon, 2 Aug 2010 08:48:40 -0700 (PDT) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id 4850E3A6879 for ; Mon, 2 Aug 2010 08:48:40 -0700 (PDT) Received: (qmail 7750 invoked from network); 2 Aug 2010 15:49:07 -0000 Received: from unknown (195.46.229.98) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 02 Aug 2010 15:49:05 -0000 From: "Glen Zorn" To: References: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> In-Reply-To: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> Date: Mon, 2 Aug 2010 17:48:50 +0200 Organization: Network Zen Message-ID: <005401cb325a$352c9230$9f85b690$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsyLRzmJzI9wPO8Rh2DkKcsAQgMWQALMmkQ Content-Language: en-us Cc: draft-ietf-dime-realm-based-redirect@tools.ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] WGLC starting for draft-ietf-dime-realm-based-redirect X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 15:48:41 -0000 Looks fine to me; the only thing that I might add would be a more direct pointer to the "normal discovery procedures" mentioned in Section 3.1.2. Hope this helps. ~gwz > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > jouni korhonen > Sent: Monday, August 02, 2010 12:26 PM > To: dime@ietf.org; draft-ietf-dime-realm-based-redirect@tools.ietf.org > Cc: dime-chairs@tools.ietf.org > Subject: [Dime] WGLC starting for draft-ietf-dime-realm-based-redirect > > A two weeks WGLC for Realm-Based Redirection In Diameter (draft-ietf- > dime-realm-based-redirect-03) starts as of today 2-Aug-2010 and ends on > Monday 16-Aug-2010 23:59 (CEST+1). > > We _require_ at least three reviews from people who are not authors of > the document. In case of an inadequate review success, we'll just keep > the document in the WG and go for another WGLC later (that will again > need a new set of three reviews ;). So lobby people to review! > > - Jouni & Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dlehmann@ulticom.com Tue Aug 3 11:37:10 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1873A698B for ; Tue, 3 Aug 2010 11:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ+6zTLh32+y for ; Tue, 3 Aug 2010 11:37:09 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 6E5C93A6915 for ; Tue, 3 Aug 2010 11:37:09 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 68D1B24ECDD38B81 for ; Tue, 3 Aug 2010 14:37:28 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o73IbSTH007500 for ; Tue, 3 Aug 2010 14:37:28 -0400 (EDT) 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, 3 Aug 2010 14:37:28 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Private-Info AVP Thread-Index: AcszImLWGUzrJ7ucSuuUZLYPOSh9qAAGEgIg From: "David Lehmann" To: Received-SPF: none Subject: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 18:37:10 -0000 Hello, Currently, Diameter has an AVP called Proxy-Info AVP which can be put into a request and it is guaranteed to be in the corresponding answer. This is very useful to allow agents to remain stateless. However, it has its limitations. Namely, the Proxy-Info AVP can (1) only be added to the request and (2) must be removed by the agent that added the AVP to the message. Consider the following diagram in which all messages are for the same session. Proxy-Info (PI) was added to R1 by the Agent. The Agent must remove the Proxy-Info from the answer before sending the answer to the client. The same procedure is done for subsequent transactions. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| I would like DIME to consider a more general AVP, "Private-Info" AVP. The Private-Info AVP can be added to a request or answer. Considering a multi-transaction session, the Private-Info AVP can be added in any leg of the session. Each diameter node must forward/include the Private-Info AVP in all subsequent messages for that session. Only the originator of the Private-Info AVP may remove the AVP from the message. In the following diagram, PI is the "Private-Info" AVP. The agent inserts the Private-Info in the first request of the session and does not remove the AVP when forwarding the answer. In subsequent requests from the client for the same session, the Private-Info AVP is added to the message. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| If such an AVP already exists, please let me know. If there is no such AVP, can we discuss the possibility of adding such an AVP? -David From gwz@net-zen.net Tue Aug 3 12:12:01 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8B93A6AB9 for ; Tue, 3 Aug 2010 12:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEOfY+zea6gN for ; Tue, 3 Aug 2010 12:11:43 -0700 (PDT) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id 2943C3A69E7 for ; Tue, 3 Aug 2010 12:11:33 -0700 (PDT) Received: (qmail 22888 invoked from network); 3 Aug 2010 19:11:21 -0000 Received: from unknown (195.46.229.98) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 03 Aug 2010 19:11:20 -0000 From: "Glen Zorn" To: "'David Lehmann'" References: In-Reply-To: Date: Tue, 3 Aug 2010 21:10:59 +0200 Organization: Network Zen Message-ID: <000001cb333f$9d56f8b0$d804ea10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcszImLWGUzrJ7ucSuuUZLYPOSh9qAAGEgIgAAEr6hA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:12:01 -0000 David Lehmann [mailto://dlehmann@ulticom.com] writes: > Hello, > > Currently, Diameter has an AVP called Proxy-Info AVP which can be put > into a request and it is guaranteed to be in the corresponding answer. > This is very useful to allow agents to remain stateless. However, it > has its limitations. Namely, the Proxy-Info AVP can (1) only be added to > the request and (2) must be removed by the agent that added the AVP to > the message. > > Consider the following diagram in which all messages are for the same > session. Proxy-Info (PI) was added to R1 by the Agent. The Agent must > remove the Proxy-Info from the answer before sending the answer to the > client. The same procedure is done for subsequent transactions. > > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1 | A1+PI | > |<------------------------|<----------------------| > | | | > | R2 | R2+PI | > |------------------------>|---------------------->| > | | | > | A2 | A2+PI | > |<------------------------|<----------------------| > > I would like DIME to consider a more general AVP, "Private-Info" AVP. > The Private-Info AVP can be added to a request or answer. Considering a > multi-transaction session, the Private-Info AVP can be added in any leg > of the session. Each diameter node must forward/include the > Private-Info AVP in all subsequent messages for that session. Only the > originator of the Private-Info AVP may remove the AVP from the message. > > In the following diagram, PI is the "Private-Info" AVP. The agent > inserts the Private-Info in the first request of the session and does > not remove the AVP when forwarding the answer. In subsequent requests > from the client for the same session, the Private-Info AVP is added to > the message. > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1+PI | A1+PI | > |<------------------------|<----------------------| > | | | > | R2+PI | R2+PI | > |------------------------>|---------------------->| > | | | > | A2+PI | A2+PI | > |<------------------------|<----------------------| > > > If such an AVP already exists, please let me know. If there is no such > AVP, can we discuss the possibility of adding such an AVP? What for? From sdecugis@nict.go.jp Tue Aug 3 18:45:04 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94EF3A68F1 for ; Tue, 3 Aug 2010 18:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TUvX04-KNvL for ; Tue, 3 Aug 2010 18:45:03 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 50CE93A6A14 for ; Tue, 3 Aug 2010 18:44:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 6A12C27DCE for ; Wed, 4 Aug 2010 03:45:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuqJelKuYOfa for ; Wed, 4 Aug 2010 03:45:24 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 3B2FF27D86 for ; Wed, 4 Aug 2010 03:45:22 +0200 (CEST) Message-ID: <4C58C62F.4070308@nict.go.jp> Date: Wed, 04 Aug 2010 10:45:19 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 01:45:05 -0000 Hello, I think the Class AVP has a similar semantics, AFAIU... See http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-20#section-8.20. Hope this helps, Best regards, Sebastien. Le 04/08/2010 03:37, David Lehmann a écrit : > Hello, > > Currently, Diameter has an AVP called Proxy-Info AVP which can be put > into a request and it is guaranteed to be in the corresponding answer. > This is very useful to allow agents to remain stateless. However, it > has its limitations. Namely, the Proxy-Info AVP can (1) only be added to > the request and (2) must be removed by the agent that added the AVP to > the message. > > Consider the following diagram in which all messages are for the same > session. Proxy-Info (PI) was added to R1 by the Agent. The Agent must > remove the Proxy-Info from the answer before sending the answer to the > client. The same procedure is done for subsequent transactions. > > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1 | A1+PI | > |<------------------------|<----------------------| > | | | > | R2 | R2+PI | > |------------------------>|---------------------->| > | | | > | A2 | A2+PI | > |<------------------------|<----------------------| > > I would like DIME to consider a more general AVP, "Private-Info" AVP. > The Private-Info AVP can be added to a request or answer. Considering a > multi-transaction session, the Private-Info AVP can be added in any leg > of the session. Each diameter node must forward/include the > Private-Info AVP in all subsequent messages for that session. Only the > originator of the Private-Info AVP may remove the AVP from the message. > > In the following diagram, PI is the "Private-Info" AVP. The agent > inserts the Private-Info in the first request of the session and does > not remove the AVP when forwarding the answer. In subsequent requests > from the client for the same session, the Private-Info AVP is added to > the message. > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1+PI | A1+PI | > |<------------------------|<----------------------| > | | | > | R2+PI | R2+PI | > |------------------------>|---------------------->| > | | | > | A2+PI | A2+PI | > |<------------------------|<----------------------| > > > If such an AVP already exists, please let me know. If there is no such > AVP, can we discuss the possibility of adding such an AVP? > > -David > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From dlehmann@ulticom.com Wed Aug 4 05:47:25 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE5D3A6858 for ; Wed, 4 Aug 2010 05:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyfjmBZHMb7Q for ; Wed, 4 Aug 2010 05:47:25 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id BC84C3A680B for ; Wed, 4 Aug 2010 05:47:24 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 8E8EB26EC5D10F73; Wed, 4 Aug 2010 08:47:53 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o74Clo6U001007; Wed, 4 Aug 2010 08:47:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Aug 2010 08:47:50 -0400 Message-ID: In-Reply-To: <000001cb333f$9d56f8b0$d804ea10$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: AcszImLWGUzrJ7ucSuuUZLYPOSh9qAAGEgIgAAEr6hAAJJEbEA== References: <000001cb333f$9d56f8b0$d804ea10$@net> From: "David Lehmann" To: "Glen Zorn" Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 12:47:26 -0000 > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net] > Sent: Tuesday, August 03, 2010 3:11 PM > To: David Lehmann > Cc: dime@ietf.org > Subject: RE: [Dime] Private-Info AVP >=20 > David Lehmann [mailto://dlehmann@ulticom.com] writes: >=20 > > Hello, > > > > Currently, Diameter has an AVP called Proxy-Info AVP which can be put > > into a request and it is guaranteed to be in the corresponding answer. > > This is very useful to allow agents to remain stateless. However, it > > has its limitations. Namely, the Proxy-Info AVP can (1) only be added to > > the request and (2) must be removed by the agent that added the AVP to > > the message. > > > > Consider the following diagram in which all messages are for the same > > session. Proxy-Info (PI) was added to R1 by the Agent. The Agent must > > remove the Proxy-Info from the answer before sending the answer to the > > client. The same procedure is done for subsequent transactions. > > > > > > Client Agent A/S > > | R1 | R1+PI | > > |------------------------>|---------------------->| > > | | | > > | A1 | A1+PI | > > |<------------------------|<----------------------| > > | | | > > | R2 | R2+PI | > > |------------------------>|---------------------->| > > | | | > > | A2 | A2+PI | > > |<------------------------|<----------------------| > > > > I would like DIME to consider a more general AVP, "Private-Info" AVP. > > The Private-Info AVP can be added to a request or answer. Considering a > > multi-transaction session, the Private-Info AVP can be added in any leg > > of the session. Each diameter node must forward/include the > > Private-Info AVP in all subsequent messages for that session. Only the > > originator of the Private-Info AVP may remove the AVP from the message. > > > > In the following diagram, PI is the "Private-Info" AVP. The agent > > inserts the Private-Info in the first request of the session and does > > not remove the AVP when forwarding the answer. In subsequent requests > > from the client for the same session, the Private-Info AVP is added to > > the message. > > > > Client Agent A/S > > | R1 | R1+PI | > > |------------------------>|---------------------->| > > | | | > > | A1+PI | A1+PI | > > |<------------------------|<----------------------| > > | | | > > | R2+PI | R2+PI | > > |------------------------>|---------------------->| > > | | | > > | A2+PI | A2+PI | > > |<------------------------|<----------------------| > > > > > > If such an AVP already exists, please let me know. If there is no such > > AVP, can we discuss the possibility of adding such an AVP? >=20 > What for? ... for similar reasons that the Proxy-Info AVP was provided. One example is to allow the Agent to be stateless. Suppose there is a pool of A/Ses. The agent wants to store an identifier of which A/S it sent the first request (R1) so subsequent requests (R2) can be sent to the same A/S. -David From root@core3.amsl.com Wed Aug 4 06:15:06 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7AA1C3A69F5; Wed, 4 Aug 2010 06:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100804131504.7AA1C3A69F5@core3.amsl.com> Date: Wed, 4 Aug 2010 06:15:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-22.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 13:15:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-22.txt Pages : 159 Date : 2010-08-04 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-22.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-04061141.I-D@ietf.org> --NextPart-- From gwz@net-zen.net Wed Aug 4 06:45:34 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03B33A685E for ; Wed, 4 Aug 2010 06:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtkSo1MDlavi for ; Wed, 4 Aug 2010 06:45:34 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id EA8613A69BD for ; Wed, 4 Aug 2010 06:45:33 -0700 (PDT) Received: (qmail 19238 invoked from network); 4 Aug 2010 13:46:01 -0000 Received: from unknown (195.46.229.98) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 04 Aug 2010 13:46:01 -0000 From: "Glen Zorn" To: Date: Wed, 4 Aug 2010 15:45:38 +0200 Organization: Network Zen Message-ID: <008b01cb33db$5366ede0$fa34c9a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsz21D8KwX+JpMVRQe8mfdOI8JOTw== Content-Language: en-us x-cr-hashedpuzzle: BU8= AARf AK+w AW3v Acsj CA74 CFFM CRoS DZSx Dbtt FAZQ GQFw G0Fo HVhC Hw9t IANZ; 1; ZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {005021DA-5B17-433F-82C1-E1EC28D873B8}; ZwB3AHoAQABuAGUAdAAtAHoAZQBuAC4AbgBlAHQA; Wed, 04 Aug 2010 13:45:36 GMT; TQBhAGEAcwB0AHIAaQBjAGgAdAAgAHMAZQBzAHMAaQBvAG4AIABtAGkAbgB1AHQAZQBzAA== x-cr-puzzleid: {005021DA-5B17-433F-82C1-E1EC28D873B8} Subject: [Dime] Maastricht session minutes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 13:45:34 -0000 The draft minutes from the hokey session at IETF 78 are available here: http://www.ietf.org/proceedings/78/minutes/hokey.htm. Please send comments and corrections (if any) to the list. From Bill.Daily@comverse.com Wed Aug 4 12:39:18 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A262A3A6915 for ; Wed, 4 Aug 2010 12:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE7jj4o5MQbh for ; Wed, 4 Aug 2010 12:39:17 -0700 (PDT) Received: from ns7.comverse.com (ns7.comverse.com [192.118.49.221]) by core3.amsl.com (Postfix) with ESMTP id 87ABC3A67DB for ; Wed, 4 Aug 2010 12:39:16 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.55,317,1278277200"; d="scan'208";a="54457709" Received: from EXUS.comverse.com ([10.8.33.175]) by US-CH1.comverse.com ([::1]) with mapi; Wed, 4 Aug 2010 12:39:43 -0700 From: Daily William To: "dime@ietf.org" Date: Wed, 4 Aug 2010 12:39:38 -0700 Thread-Topic: Private-Info AVP Thread-Index: Acs0B4kFvkFLnzhnT3+gVHVIcDOz9wAAf/rQ Message-ID: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 19:39:18 -0000 DQo+IFdoYXQgZm9yPw0KDQouLi4gZm9yIHNpbWlsYXIgcmVhc29ucyB0aGF0IHRoZSBQcm94eS1J bmZvIEFWUCB3YXMgcHJvdmlkZWQuICBPbmUNCmV4YW1wbGUgaXMgdG8gYWxsb3cgdGhlIEFnZW50 IHRvIGJlIHN0YXRlbGVzcy4gIFN1cHBvc2UgdGhlcmUgaXMgYSBwb29sDQpvZiBBL1Nlcy4gVGhl IGFnZW50IHdhbnRzIHRvIHN0b3JlIGFuIGlkZW50aWZpZXIgb2Ygd2hpY2ggQS9TIGl0IHNlbnQN CnRoZSBmaXJzdCByZXF1ZXN0IChSMSkgc28gc3Vic2VxdWVudCByZXF1ZXN0cyAoUjIpIGNhbiBi ZSBzZW50IHRvIHRoZQ0Kc2FtZSBBL1MuDQoNCi1EYXZpZA0KDQoNCltiZF0NClRoZSBleGFtcGxl IGlzIGludGVyZXN0aW5nIGJlY2F1c2UgdGhpcyBwcm9ibGVtIGV4aXN0cyBpbiB0aGUgRGlhbWV0 ZXIgQ3JlZGl0IENvbnRyb2wgQXBwbGljYXRpb24uICBTZXZlcmFsIHZlbmRvcnMgaGF2ZSBjaG9z ZW4gdG8gYWRkcmVzcyB0aGlzIHNpdHVhdGlvbiBieSB1dGlsaXppbmcgdGhlIERlc3RpbmF0aW9u LUhvc3QgQVZQLg0KDQpUaGUgc2NlbmFyaW8gd291bGQgYmU6DQoNCkNDUi1Jbml0aWFsIC0tPg0K RGVzdGluYXRpb24tUmVhbG0gPSBleGFtcGxlLm5ldA0KDQogICAgICAgICAgICAgICAgPC0tIEND QS1Jbml0aWFsDQogICAgICAgICAgICAgICAgT3JpZ2luLUhvc3QgPSBub2RlLmV4YW1wbGUubmV0 DQogICAgICAgICAgICAgICAgT3JpZ2luLVJlYWxtID0gZXhhbXBsZS5uZXQNCg0KQ0NSLVVwZGF0 ZSAob3IgVGVybWluYXRlKSAtLT4NCkRlc3RpbmF0aW9uLVJlYWxtID0gZXhhbXBsZS5uZXQNCkRl c3RpbmF0aW9uLUhvc3QgPSBub2RlLmV4YW1wbGUubmV0DQoNCiAgICAgICAgICAgICAgICA8LS0g Q0NBLVVwZGF0ZSAob3IgVGVybWluYXRlKQ0KICAgICAgICAgICAgICAgIE9yaWdpbi1Ib3N0ID0g bm9kZS5leGFtcGxlLm5ldA0KICAgICAgICAgICAgICAgIE9yaWdpbi1SZWFsbSA9IGV4YW1wbGUu bmV0DQoNClRoZSBEaWFtZXRlciBjbGllbnQgaXMgZXhwZWN0ZWQgdG8gY2FwdHVyZSB0aGUgdmFs dWUgb2YgdGhlIE9yaWdpbi1Ib3N0IEFWUCBmcm9tIHRoZSBDQ0EtSW5pdGlhbCBzZW50IGJ5IHRo ZSBzZXJ2ZXIgYW5kIHVzZSB0aGlzIHZhbHVlIGluIHRoZSBEZXN0aW5hdGlvbi1Ib3N0IEFWUCBm b3IgYWxsIHN1YnNlcXVlbnQgQ3JlZGl0LUNvbnRyb2wtUmVxdWVzdHMuDQoNClRoZSBydWxlcyBm b3IgdGhlIERlc3RpbmF0aW9uLUhvc3QgbGVuZCBpdHNlbGYgdG8gdGhpcyBzY2VuYXJpbyAoc2Vl IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGltZS1yZmMzNTg4YmlzLTIw I3NlY3Rpb24tNi4xKSBob3dldmVyIHRoaXMgc2NlbmFyaW8gaXMgbm90IGV4cGxpY2l0bHkgZGVz Y3JpYmVkIGluIEJhc2UtRGlhbWV0ZXIuICBOZXZlcnRoZWxlc3MsIElNSE8gSSBkb24ndCBiZWxp ZXZlIHRoYXQgdGhlcmUgYXJlIGFueSBjb250cmFkaWN0aW9ucyBpbiB0aGlzIHNjZW5hcmlvIGFu ZCB0aGUgcnVsZXMgaW4gc2VjdGlvbiA2LjEuICBBZ2FpbiwgdGhpcyBwcmFjdGljZSBoYXMgYmVl biBhZG9wdGVkIGJ5IHNldmVyYWwgdmVuZG9ycy4NCg0KSXQgaGFzIG9jY3VycmVkIHRvIG1lIHRo ZSBCYXNlIERpYW1ldGVyIGJpcyB2ZXJzaW9uIG1pZ2h0IGJlbmVmaXQgZnJvbSBhIGRlc2NyaXB0 aW9uIG9mIHRoaXMgc2NlbmFyaW8sIGhvd2V2ZXIgc2luY2UgdGhlIGRyYWZ0IHdhcyBpbiBhIGxh dGUgc3RhdGUgaXQgZGlkIG5vdCBzZWVtIGxpa2UgYW4gYXBwcm9wcmlhdGUgdGltZSB0byBtYWtl IHRoaXMgdHlwZSBvZiBjaGFuZ2UuICBCdXQgc2luY2UgdGhlIHN1YmplY3Qgd2FzIGJyb3VnaHQg dXAgaXQgZG9lcyBub3QgaHVydCB0byBwdXQgaXQgb3V0IHRoZXJlIGZvciBjb21tZW50Lg0KDQpU aGFua3MgYW5kIHJlZ2FyZHMsDQoNCkJpbGwNCg0KDQrigJxUaGlzIGUtbWFpbCBtZXNzYWdlIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCwgY29tbWVyY2lhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgY29uc3RpdHV0ZXMgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gb2YgQ29tdmVyc2Ug VGVjaG5vbG9neSBvciBpdHMgc3Vic2lkaWFyaWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IG9mIHRoaXMgbWVzc2FnZSwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhh dCBhbnkgcmV2aWV3LCB1c2Ugb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMg YWJzb2x1dGVseSBwcm9oaWJpdGVkIGFuZCB3ZSByZXF1ZXN0IHRoYXQgeW91IGRlbGV0ZSBhbGwg Y29waWVzIGFuZCBjb250YWN0IHVzIGJ5IGUtbWFpbGluZyB0bzogc2VjdXJpdHlAY29tdmVyc2Uu Y29tLiBUaGFuayBZb3Uu4oCdDQo= From vf0213@gmail.com Wed Aug 4 14:55:46 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF313A6A49 for ; Wed, 4 Aug 2010 14:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSk21zIW4dBn for ; Wed, 4 Aug 2010 14:55:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7C5973A69DB for ; Wed, 4 Aug 2010 14:55:44 -0700 (PDT) Received: by wyb40 with SMTP id 40so6363902wyb.31 for ; Wed, 04 Aug 2010 14:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1C9ppRAfkOlkPgOrdBJoLMCfrO5RqG+oTo4eJW5HC7c=; b=vqe6di74rU9XPskYSiScmT/psXXt2uvQ1ZkOBklGlsia4G3Kwt2Zs/gjgxQeQobchk X/6XiU3qQu8I6s1AN+3ZlqYm1rUgjX76WfsZsw+ioIh2qtJDYaqK+Ho8xeIa1pbmIRD1 9DfEz9YMGOLIUz2eRRLd6ckUhje3Co4amiWrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p0Cb73ExHZsKsJhkypEnuHoR6n+EboGAgpJQXuiq3prgALb8uUIUN44CP0cIEA0KMu hK5HFKLi/UZ64yYioj+TrTsv/vH0De4fI7N/CgOx9xJx5zlOPhEZN4uEnXzoCPLM5AGK PSa4rCxwhvovPErllBmQdX8awvxPTvZacmY5I= MIME-Version: 1.0 Received: by 10.227.138.5 with SMTP id y5mr8229156wbt.204.1280958973143; Wed, 04 Aug 2010 14:56:13 -0700 (PDT) Received: by 10.216.167.67 with HTTP; Wed, 4 Aug 2010 14:56:13 -0700 (PDT) In-Reply-To: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> Date: Wed, 4 Aug 2010 17:56:13 -0400 Message-ID: From: Victor Fajardo To: Daily William Content-Type: multipart/alternative; boundary=001636833bd490eff4048d06805f Cc: "dime@ietf.org" Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 21:55:46 -0000 --001636833bd490eff4048d06805f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On Wed, Aug 4, 2010 at 3:39 PM, Daily William wrot= e: > > The rules for the Destination-Host lend itself to this scenario (see > http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-20#section-6.1) > however this scenario is not explicitly described in Base-Diameter. > Nevertheless, IMHO I don't believe that there are any contradictions in > this scenario and the rules in section 6.1. Again, this practice has bee= n > adopted by several vendors. > I tend to agree but I think the decision for using these types of schemes should be left to the context of the application and hence its not explicitly described in bis (and probably should not be). > > It has occurred to me the Base Diameter bis version might benefit from a > description of this scenario, however since the draft was in a late state= it > did not seem like an appropriate time to make this type of change. But > since the subject was brought up it does not hurt to put it out there for > comment. > It maybe better to put items like this in design guidelines rather than bis= . It is really up to an application on how it wants to maintain message cohession within a sessions. regards, victor > > Thanks and regards, > > Bill > > > =93This e-mail message may contain confidential, commercial or privileged > information that constitutes proprietary information of Comverse Technolo= gy > or its subsidiaries. If you are not the intended recipient of this messag= e, > you are hereby notified that any review, use or distribution of this > information is absolutely prohibited and we request that you delete all > copies and contact us by e-mailing to: security@comverse.com. Thank You.= =94 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --001636833bd490eff4048d06805f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

On Wed, Aug 4, 2010 at 3:39 PM, Daily William <Bill.Daily@c= omverse.com> wrote:
=A0

The rules for the Destinatio= n-Host lend itself to this scenario (see http://too= ls.ietf.org/html/draft-ietf-dime-rfc3588bis-20#section-6.1) however thi= s scenario is not explicitly described in Base-Diameter. =A0Nevertheless, I= MHO I don't believe that there are any contradictions in this scenario = and the rules in section 6.1. =A0Again, this practice has been adopted by s= everal vendors.
=A0
I tend to agree but I think the decision for using these types of=A0sc= hemes should be left to the context of the application and hence its not ex= plicitly described in bis (and probably should not be).
=A0
=A0

It has occurred to me the Ba= se Diameter bis version might benefit from a description of this scenario, = however since the draft was in a late state it did not seem like an appropr= iate time to make this type of change. =A0But since the subject was brought= up it does not hurt to put it out there for comment.
=A0
It maybe better to put items like this in design guidelines rather tha= n bis. It is really up to an application on how it wants to maintain=A0mess= age=A0cohession=A0within a=A0sessions.
=A0
regards,
victor
=A0
=A0
=A0

Thanks and regards,

B= ill


=93This e-mail message may contain confidential, commercial = or privileged information that constitutes proprietary information of Comve= rse Technology or its subsidiaries. If you are not the intended recipient o= f this message, you are hereby notified that any review, use or distributio= n of this information is absolutely prohibited and we request that you dele= te all copies and contact us by e-mailing to: security@comverse.com. Thank You.=94
_______________________________________________
DiME m= ailing list
DiME@ietf.org
https://= www.ietf.org/mailman/listinfo/dime

--001636833bd490eff4048d06805f-- From sdecugis@nict.go.jp Wed Aug 4 23:50:18 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF9F3A6AAA for ; Wed, 4 Aug 2010 23:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlkCHQFMlNHP for ; Wed, 4 Aug 2010 23:50:13 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 2CD573A6A9F for ; Wed, 4 Aug 2010 23:50:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 4DE1327DD0 for ; Thu, 5 Aug 2010 08:50:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VyqtDRAqzLh for ; Thu, 5 Aug 2010 08:50:38 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 95F8B27DCE for ; Thu, 5 Aug 2010 08:50:37 +0200 (CEST) Message-ID: <4C5A5F2D.20508@nict.go.jp> Date: Thu, 05 Aug 2010 15:50:21 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 06:50:18 -0000 Hello, "[...] RFC 4005 in general and RADIUS-Diameter interoperability in particular. In Anaheim we decided to just try removing the RADIUS-it had ever actually been deployed) & see who screamed in pain ;-)" If the main rationale for this revision is just to remove the RADIUS/Diameter translation explanations, as the above excerpt seems to indicate, I would rather see the adoption of this document postponned until a suitable mechanism for RADIUS/Diameter interaction is described somewhere. And, for information, the mechanism described in 4005 is implemented in freeDiameter, and so far, it works well :) My 2 cents, Best regards, Sebastien. Le 02/08/2010 19:54, jouni korhonen a écrit : > As discussed during the Maastricht DIME WG meeting, the chairs agreed to confirm the adoption of draft-zorn-dime-rfc4005bis-01 as the WG Item. The work regarding RFC4005bis has been around the corner for some time and discussed several times among AAA Doctors. There was support for the adoption during the WG meeting. > > The one week poll ends 9-Aug-2010, 23:59 (CEST+1).. Silence counts also as "yes", so unless you have a strong reason to disagree (like the North Pole melts or Diameter will become obsolete due the adoption of this draft), then express your "no" on the list with a proper reasoning why. Technical details on the actual draft content can be handled later (if/when the document gets adopted). > > - Jouni & Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Thu Aug 5 00:21:35 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95E53A6903 for ; Thu, 5 Aug 2010 00:21:35 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcqZn7Iv3s3y for ; Thu, 5 Aug 2010 00:21:34 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id BB7F83A67C0 for ; Thu, 5 Aug 2010 00:21:34 -0700 (PDT) Received: (qmail 15542 invoked from network); 5 Aug 2010 07:22:03 -0000 Received: from unknown (195.46.229.98) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 05 Aug 2010 07:22:03 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4C5A5F2D.20508@nict.go.jp> In-Reply-To: <4C5A5F2D.20508@nict.go.jp> Date: Thu, 5 Aug 2010 09:21:36 +0200 Organization: Network Zen Message-ID: <001c01cb346e$d7f9a460$87eced20$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs0aotkKJAfu6ZFQGi3n3XiKWgZhgAA0tdA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 07:21:36 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > Hello, >=20 > "[...] RFC 4005 in general and RADIUS-Diameter > interoperability in particular. In Anaheim we decided to just try > removing > the RADIUS-it had ever actually been deployed) & see who screamed in > pain ;-)" >=20 > If the main rationale for this revision is just to remove the > RADIUS/Diameter translation explanations, as the above excerpt seems = to > indicate, I would rather see the adoption of this document postponned > until a suitable mechanism for RADIUS/Diameter interaction is = described > somewhere.=20 Would you then consider http://www.ietf.org/id/draft-zorn-dime-radia-gate-01.txt to be = unsuitable? Be that as it may, however, the point is that it's very unclear whether = such functionality is actually useful... > And, for information, the mechanism described in 4005 is > implemented in freeDiameter, and so far, it works well :) >=20 > My 2 cents, >=20 > Best regards, > Sebastien. >=20 >=20 >=20 > Le 02/08/2010 19:54, jouni korhonen a =E9crit : > > As discussed during the Maastricht DIME WG meeting, the chairs = agreed > to confirm the adoption of draft-zorn-dime-rfc4005bis-01 as the WG = Item. > The work regarding RFC4005bis has been around the corner for some time > and discussed several times among AAA Doctors. There was support for = the > adoption during the WG meeting. > > > > The one week poll ends 9-Aug-2010, 23:59 (CEST+1).. Silence counts > also as "yes", so unless you have a strong reason to disagree (like = the > North Pole melts or Diameter will become obsolete due the adoption of > this draft), then express your "no" on the list with a proper = reasoning > why. Technical details on the actual draft content can be handled = later > (if/when the document gets adopted). > > > > - Jouni & Lionel > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Thu Aug 5 00:52:01 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70EF3A67AC for ; Thu, 5 Aug 2010 00:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxrFfTcqIrmi for ; Thu, 5 Aug 2010 00:51:59 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 15D183A6801 for ; Thu, 5 Aug 2010 00:51:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id DD65627D86; Thu, 5 Aug 2010 09:52:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrujkvw5BVeJ; Thu, 5 Aug 2010 09:52:25 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id EB13427DD0; Thu, 5 Aug 2010 09:52:23 +0200 (CEST) Message-ID: <4C5A6DA9.30309@nict.go.jp> Date: Thu, 05 Aug 2010 16:52:09 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Glen Zorn References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> In-Reply-To: <001c01cb346e$d7f9a460$87eced20$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 07:52:01 -0000 Hello again, > Would you then consider > http://www.ietf.org/id/draft-zorn-dime-radia-gate-01.txt to be unsuitable? Yes. That document describes how to use Diameter as a tunneling protocol (I don't understand the purpose of this, but anyway), it does not address the translation of the RADIUS messages to Diameter. > Be that as it may, however, the point is that it's very unclear whether such > functionality is actually useful... First of all, not being useful is a good enough rationale to revise a RFC? Secondly, I believe that yes, this mechanism is actually useful, to help transition to Diameter. It provides a way to interconnect several realms where some use RADIUS while others already moved to Diameter (example: take a consortium like EDUROAM. How would you migrate someday to something else that RADIUS, without a translation mechanism?) Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Thu Aug 5 01:20:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB5A3A6ACE for ; Thu, 5 Aug 2010 01:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyAXlShuqOwy for ; Thu, 5 Aug 2010 01:20:40 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 0103B3A6A97 for ; Thu, 5 Aug 2010 01:20:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 0039F27DD0 for ; Thu, 5 Aug 2010 10:21:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9Ewuf-nXLtB for ; Thu, 5 Aug 2010 10:21:06 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 4DFB327DCE for ; Thu, 5 Aug 2010 10:21:06 +0200 (CEST) Message-ID: <4C5A7463.2080603@nict.go.jp> Date: Thu, 05 Aug 2010 17:20:51 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] Comments on draft-ietf-dime-ikev2-psk-diameter-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:20:41 -0000 Here are my comments on this document. They are only cosmetics. I think the document is ready to be moved forward. 1) What is the purpose of including the Auth-Request-Type AVP in the IKEv2-PSK-Request, since its value is constrained? 2) Security section: This section refers to Master-Security-Association AVP, which is not defined (I believe Key AVP is intended). I also believe the second paragraph does not belong to this specification, but rather to I-D.ietf-dime-local-keytran. However, it does not harm as a reminder. 3) The reference section points to I-D.ietf-dime-local-keytran in version -01 but the -06 is the latest, maybe an update would be useful. That's all I have. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Thu Aug 5 01:41:54 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668793A6AE4 for ; Thu, 5 Aug 2010 01:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYijGAGefV93 for ; Thu, 5 Aug 2010 01:41:52 -0700 (PDT) Received: from smtpout07.prod.mesa1.secureserver.net (smtpout07-01.prod.mesa1.secureserver.net [64.202.165.230]) by core3.amsl.com (Postfix) with SMTP id 849733A6ACE for ; Thu, 5 Aug 2010 01:41:52 -0700 (PDT) Received: (qmail 20944 invoked from network); 5 Aug 2010 08:42:22 -0000 Received: from unknown (195.46.229.98) by smtpout07.prod.mesa1.secureserver.net (64.202.165.230) with ESMTP; 05 Aug 2010 08:42:21 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> In-Reply-To: <4C5A6DA9.30309@nict.go.jp> Date: Thu, 5 Aug 2010 10:41:54 +0200 Organization: Network Zen Message-ID: <003201cb347a$0fb844a0$2f28cde0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs0cygrziOkN8HKQJGjytJhGqxaHAABYkog Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:41:54 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hello again, > > > Would you then consider > > http://www.ietf.org/id/draft-zorn-dime-radia-gate-01.txt to be > unsuitable? > Yes. That document describes how to use Diameter as a tunneling protocol > (I don't understand the purpose of this, but anyway), it does not > address the translation of the RADIUS messages to Diameter. Exactly. Since it is manifestly impossible to perform the reverse translation (from Diameter to RADIUS) it seems rather pointless. > > > Be that as it may, however, the point is that it's very unclear > whether such > > functionality is actually useful... > First of all, not being useful is a good enough rationale to revise a > RFC? Yes. > > Secondly, I believe that yes, this mechanism is actually useful, to help > transition to Diameter. It provides a way to interconnect several realms > where some use RADIUS while others already moved to Diameter (example: > take a consortium like EDUROAM. How would you migrate someday to > something else that RADIUS, without a translation mechanism?) The problem is that apparently nobody has _ever_ transitioned from RADIUS to Diameter and it appears as if nobody ever will. Regarding EDUROAM, Diameter existed long before EDUROAM but they chose to hack RADIUS in their own way. In any case, if they decided to migrate to Diameter they could use the pointless tunneling protocol, retiring their RADIUS server when the transition was complete. > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From dromasca@avaya.com Thu Aug 5 01:45:50 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E043A6ACE for ; Thu, 5 Aug 2010 01:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nprrih+C7iNY for ; Thu, 5 Aug 2010 01:45:48 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5A0F73A6AE1 for ; Thu, 5 Aug 2010 01:45:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,320,1278302400"; d="scan'208";a="201281516" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Aug 2010 04:46:17 -0400 X-IronPort-AV: E=Sophos;i="4.55,320,1278302400"; d="scan'208";a="497569311" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Aug 2010 04:46:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Aug 2010 10:46:14 +0200 Message-ID: In-Reply-To: <4C5A6DA9.30309@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 Thread-Index: Acs0cysfn9ppvu9oSC6DqBOdwxFTcgABfh9Q References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> From: "Romascanu, Dan (Dan)" To: "Sebastien Decugis" , "Glen Zorn" Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:45:50 -0000 > First of all, not being useful is a good enough rationale to=20 > revise a RFC? Let me try to argue that yes, it is. A section in a Proposed Standard that is not useful may lead to (at least) two counter-productive effects:=20 - efforts are being made for implementation that result in useless code with the risk of bugs and wasting resources - the function that is described by the 'not useful' section seems to apparently solve what may be a real problem, discouraging search other ways of solving the problem (as 'there already is a standard way') I will let the RADIUS and Diameter experts decide whether the translation mechanism between RADIUS and Diameter as described in Section 9 of RFC 4005 belongs here. Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Sebastien Decugis > Sent: Thursday, August 05, 2010 10:52 AM > To: Glen Zorn > Cc: dime@ietf.org > Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 >=20 >=20 > Hello again, >=20 > > Would you then consider > > http://www.ietf.org/id/draft-zorn-dime-radia-gate-01.txt to=20 > be unsuitable? > Yes. That document describes how to use Diameter as a=20 > tunneling protocol (I don't understand the purpose of this,=20 > but anyway), it does not address the translation of the=20 > RADIUS messages to Diameter. >=20 > > Be that as it may, however, the point is that it's very unclear=20 > > whether such functionality is actually useful... > First of all, not being useful is a good enough rationale to=20 > revise a RFC? >=20 > Secondly, I believe that yes, this mechanism is actually=20 > useful, to help transition to Diameter. It provides a way to=20 > interconnect several realms where some use RADIUS while=20 > others already moved to Diameter (example: > take a consortium like EDUROAM. How would you migrate someday=20 > to something else that RADIUS, without a translation mechanism?) >=20 > Best regards, > Sebastien. >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From dlehmann@ulticom.com Thu Aug 5 05:35:46 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434C33A6B0C for ; Thu, 5 Aug 2010 05:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMeWOrVpFNzs for ; Thu, 5 Aug 2010 05:35:44 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 9EF3C3A6987 for ; Thu, 5 Aug 2010 05:35:44 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 75B9A34C4DE1552E; Thu, 5 Aug 2010 08:36:12 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o75CaCrO010565; Thu, 5 Aug 2010 08:36:12 -0400 (EDT) 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, 5 Aug 2010 08:31:16 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0H/g+yDcI8IYNStSSvYhsyK9HEgAeW7DQ References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: "David Lehmann" To: "Victor Fajardo" , "Daily William" Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 12:35:46 -0000 =A0 > It maybe better to put items like this in design guidelines rather = than bis.=20 > It is really up to an application on how it wants to = maintain=A0message=A0cohession=A0within a=A0sessions.=20 =A0 The intent of the Private-AVP is not for applications. Rather, as shown = in the example, it was intended to assist Diameter _agents_. (Although, = nothing should prevent an application from using this AVP.) Agents are = not aware of all the application rules. -David From rajithr@huawei.com Thu Aug 5 06:13:55 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A033A6B20 for ; Thu, 5 Aug 2010 06:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6K2KFk1+R9a for ; Thu, 5 Aug 2010 06:13:54 -0700 (PDT) Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5A72A3A6B1A for ; Thu, 5 Aug 2010 06:13:53 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6O00ARVKRYSZ@szxga05-in.huawei.com> for dime@ietf.org; Thu, 05 Aug 2010 21:14:22 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6O005ZAKRXGF@szxga05-in.huawei.com> for dime@ietf.org; Thu, 05 Aug 2010 21:14:22 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.18.1.31]) by szxmc03-in.huawei.com (mshttpd); Thu, 05 Aug 2010 18:14:21 +0500 Date: Thu, 05 Aug 2010 18:14:21 +0500 From: rajithr 70236 In-reply-to: To: David Lehmann Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=iso-8859-1 Content-language: en Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: en Priority: normal References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 13:13:55 -0000 ----- Original Message ----- From=3A David Lehmann =3Cdlehmann=40ulticom=2Ecom=3E Date=3A Thursday=2C August 5=2C 2010 6=3A06 pm Subject=3A Re=3A =5BDime=5D Private-Info AVP To=3A Victor Fajardo =3Cvf0213=40gmail=2Ecom=3E=2C Daily William =3CBill=2E= Daily=40comverse=2Ecom=3E Cc=3A dime=40ietf=2Eorg =3E =A0 =3E =3E It maybe better to put items like this in design guidelines = =3E rather than bis=2E = =3E =3E It is really up to an application on how it wants to = =3E maintain=A0message=A0cohession=A0within a=A0sessions=2E = =3E =A0 =3E = =3E The intent of the Private-AVP is not for applications=2E Rather=2C as= = =3E shown in the example=2C it was intended to assist Diameter =5Fagents=5F= =2E = =3E (Although=2C nothing should prevent an application from using this = =3E AVP=2E) Agents are not aware of all the application rules=2E I think all session stateful agents would be application aware=2E Let the= application handle these considerations=2E For stateless agents=2C Proxy Info AVP would keep the transaction state=2E= Why would we need this new AVP then=3F - Rajith =3E = =3E -David =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E DiME mailing list =3E DiME=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/dime =3E From lionel.morand@orange-ftgroup.com Thu Aug 5 06:17:15 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF383A67F9 for ; Thu, 5 Aug 2010 06:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.828 X-Spam-Level: X-Spam-Status: No, score=-102.828 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ncbuUKLoLZg for ; Thu, 5 Aug 2010 06:17:15 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id F3F973A680C for ; Thu, 5 Aug 2010 06:17:14 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EE5B38B800D; Thu, 5 Aug 2010 15:18:13 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id E5CD48B8004; Thu, 5 Aug 2010 15:18:13 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Aug 2010 15:17:42 +0200 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, 5 Aug 2010 15:17:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0H/g+yDcI8IYNStSSvYhsyK9HEgAeW7DQAAGZxaA= References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: To: , , X-OriginalArrivalTime: 05 Aug 2010 13:17:42.0794 (UTC) FILETIME=[961AC6A0:01CB34A0] Cc: dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 13:17:16 -0000 =20 > > It maybe better to put items like this in design guidelines=20 > rather than bis.=20 > > It is really up to an application on how it wants to=20 > maintain=A0message=A0cohession=A0within a=A0sessions.=20 > =A0 >=20 > The intent of the Private-AVP is not for applications.=20 > Rather, as shown in the example, it was intended to assist=20 > Diameter _agents_. (Although, nothing should prevent an=20 > application from using this AVP.) Agents are not aware of=20 > all the application rules. >=20 Difficult to see any specific need for such AVP for Relay or redirect = agent. It means that this AVP would be used by proxy and/or server, in = which diameter messages are managed at the application level. And = therefore, it can be defined in the application requiring such = functionality. Except if I missed something.=20 Lionel > -David >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From dlehmann@ulticom.com Thu Aug 5 06:18:14 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61913A6B11 for ; Thu, 5 Aug 2010 06:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIZAgCAwZIUr for ; Thu, 5 Aug 2010 06:18:14 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 051643A69FD for ; Thu, 5 Aug 2010 06:18:14 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 119DA26DC9D09CF4; Thu, 5 Aug 2010 09:18:44 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o75DIhFx014780; Thu, 5 Aug 2010 09:18:43 -0400 (EDT) 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: Thu, 5 Aug 2010 09:18:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0oCFkfaWsU6GQSn6y3g+eVV0GUAAACJ+Q References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: "David Lehmann" To: "rajithr 70236" Received-SPF: none Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 13:18:14 -0000 > > The intent of the Private-AVP is not for applications. Rather, as > > shown in the example, it was intended to assist Diameter _agents_. > > (Although, nothing should prevent an application from using this > > AVP.) Agents are not aware of all the application rules. >=20 > I think all session stateful agents would be application aware. Let the > application handle these considerations. > For stateless agents, Proxy Info AVP would keep the transaction state. >=20 > Why would we need this new AVP then? The Proxy-Info has a limited lifespan. The Private-Info is the same as the Proxy-Info except that it lasts then entire session. (See the original example.) -David From rajithr@huawei.com Thu Aug 5 07:03:06 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AE83A67F5 for ; Thu, 5 Aug 2010 07:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5h2n7yjqvSD for ; Thu, 5 Aug 2010 07:03:05 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 91E693A69D6 for ; Thu, 5 Aug 2010 07:03:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6O00HLIN1YT9@szxga04-in.huawei.com> for dime@ietf.org; Thu, 05 Aug 2010 22:03:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6O009U3N1YZ5@szxga04-in.huawei.com> for dime@ietf.org; Thu, 05 Aug 2010 22:03:34 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.18.1.31]) by szxmc03-in.huawei.com (mshttpd); Thu, 05 Aug 2010 19:03:34 +0500 Date: Thu, 05 Aug 2010 19:03:34 +0500 From: rajithr 70236 In-reply-to: To: David Lehmann Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 14:03:06 -0000 ----- Original Message ----- From: David Lehmann Date: Thursday, August 5, 2010 6:48 pm Subject: RE: [Dime] Private-Info AVP To: rajithr 70236 Cc: Victor Fajardo , Daily William , dime@ietf.org > > > The intent of the Private-AVP is not for applications. Rather, as > > > shown in the example, it was intended to assist Diameter _agents_. > > > (Although, nothing should prevent an application from using this > > > AVP.) Agents are not aware of all the application rules. > > > > I think all session stateful agents would be application aware. Let > the > > application handle these considerations. > > For stateless agents, Proxy Info AVP would keep the transaction > state.> > > Why would we need this new AVP then? > > The Proxy-Info has a limited lifespan. The Private-Info is the > same as > the Proxy-Info except that it lasts then entire session. (See the > original > example.) Why should a (session) stateless agent need to have such a mechanism that lasts the entire session? For session stateful agent, this may be needed and it would be considered in the application design. -Rajith > > -David > > From vf0213@gmail.com Thu Aug 5 07:16:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9EC3A6B29 for ; Thu, 5 Aug 2010 07:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L70JR1sAE5x3 for ; Thu, 5 Aug 2010 07:16:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2D2E23A6B1E for ; Thu, 5 Aug 2010 07:16:26 -0700 (PDT) Received: by wwj40 with SMTP id 40so52214wwj.13 for ; Thu, 05 Aug 2010 07:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NbF+HHkKRstjZgdLDih7b6igodyuUUmB8v6pqT2VDOg=; b=iP50ueKefK3cGuupKS4kHGXyjl7idfaeWJuM5OABdoX38UoId5XNJGbh+mscLFgYk0 mMRDQs5e3PFXxfIkTnxbvCvpG4D27FbrNFGJyrT91BulkwpKW/mbIQD9KycJ3OWzXTzz F9QLnNOjg6sH5nxI22vEWseItpWbsMydtMT6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=APSWifR6C+lANAQa4Am0UOds+8NQuzCLEK5+6D50CkmDfHrQlJoCQYG6V96o/odlWH B2AHwvH+78a/dGhyaiHCFiJW7uzOmqJ9jigGn/TtYDdNLQ/81dtc+RjSuv4kDQlaZu2Q KqA/Hko7As0ioit7d7eEFdzriDVWbeNV71iLc= MIME-Version: 1.0 Received: by 10.227.146.4 with SMTP id f4mr8984365wbv.14.1281017816017; Thu, 05 Aug 2010 07:16:56 -0700 (PDT) Received: by 10.216.167.67 with HTTP; Thu, 5 Aug 2010 07:16:55 -0700 (PDT) In-Reply-To: References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> Date: Thu, 5 Aug 2010 10:16:55 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=0016364ef85edff947048d1433f3 Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 14:16:29 -0000 --0016364ef85edff947048d1433f3 Content-Type: text/plain; charset=ISO-8859-1 Hi David, On Thu, Aug 5, 2010 at 9:18 AM, David Lehmann wrote: > > > The intent of the Private-AVP is not for applications. Rather, as > > > shown in the example, it was intended to assist Diameter _agents_. > > > (Although, nothing should prevent an application from using this > > > AVP.) Agents are not aware of all the application rules. > > > > I think all session stateful agents would be application aware. Let > the > > application handle these considerations. > > For stateless agents, Proxy Info AVP would keep the transaction state. > > > > Why would we need this new AVP then? > > The Proxy-Info has a limited lifespan. The Private-Info is the same as > the Proxy-Info except that it lasts then entire session. (See the > original > example.) > Unless I'm missing something, Proxy-Info can be included in an stateful application which can control it's lifetime .... so I'm still not sure why we need a new AVP that means the same thing. -- victor > > -David > > --0016364ef85edff947048d1433f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi David,

On Thu, Aug 5, 2010 at 9:18 AM, David Lehmann <dlehmann@ultico= m.com> wrote:
> > The intent of the Private-AVP is not for applic= ations. Rather, as
> > shown in the example, it was intended to as= sist Diameter _agents_.
> > (Although, nothing should prevent an a= pplication from using this
> > AVP.) =A0Agents are not aware of all the application rules.
&g= t;
> I think all session stateful agents would be application aware. = Let
the
> application handle these considerations.
> For sta= teless agents, Proxy Info AVP would keep the transaction state.
>
> Why would we need this new AVP then?

The Proxy-In= fo has a limited lifespan. =A0The Private-Info is the same as
the Proxy-= Info except that it lasts then entire session. (See the
original
exam= ple.)
=A0
=A0
Unless I'm missing something, Proxy-Info can be included in an sta= teful application which can control it's lifetime .... so I'm still= not sure why we need a new AVP that means the same thing.
=A0
-- victor
=A0
=A0
=A0

-Dav= id


--0016364ef85edff947048d1433f3-- From dlehmann@ulticom.com Thu Aug 5 07:35:17 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C607A3A67EF for ; Thu, 5 Aug 2010 07:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5KXlqAoHg5h for ; Thu, 5 Aug 2010 07:35:15 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 89BDA3A6B37 for ; Thu, 5 Aug 2010 07:34:49 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id B837A27EC9E1BC00; Thu, 5 Aug 2010 10:35:18 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o75EYvVi027354; Thu, 5 Aug 2010 10:35:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Thu, 5 Aug 2010 10:08:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0H/g+yDcI8IYNStSSvYhsyK9HEgAeW7DQAAGZxaAAAD1PEA== References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: "David Lehmann" To: , , Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 14:35:17 -0000 > > The intent of the Private-AVP is not for applications. > > Rather, as shown in the example, it was intended to assist > > Diameter _agents_. (Although, nothing should prevent an > > application from using this AVP.) Agents are not aware of > > all the application rules. > > >=20 > Difficult to see any specific need for such AVP for Relay or redirect agent. > It means that this AVP would be used by proxy and/or server, in which > diameter messages are managed at the application level. And therefore, it > can be defined in the application requiring such functionality. Except if I > missed something. My original example provided a specific need for stateless agents. =20 I sure there are other examples. -David From jouni.nospam@gmail.com Thu Aug 5 07:48:35 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D376C3A6B0F for ; Thu, 5 Aug 2010 07:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmtRNWTWGMyw for ; Thu, 5 Aug 2010 07:48:34 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 178463A659B for ; Thu, 5 Aug 2010 07:48:33 -0700 (PDT) Received: by fxm16 with SMTP id 16so2338648fxm.31 for ; Thu, 05 Aug 2010 07:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=dLpGo3LifSi4b7kEa6qtllXqVjl9EWsGxeXTVWVKq88=; b=mfUBKUSfkizfh1njI8xybkJAFg5RPo94+KrnJYtm/Zv1gfkIhqRGyM0mOBSJiT3BAz 22jVzT+vK3j+/NJC+AnjA5Z9g5fwgv8kgknr63/E92xKnWOY4ZB3nIdKduZIB8oEWAIm HGDzMo/lgryBVTs3Xk1ybF4v6MLCDRpDbj/Yk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=H9Z7A9163YoOOday3POrIwDy1wqnAUTXRaC5I/PLpJGwXlGlbyr5AVyf3G5002ucJr DGnZ8jdN0N6QQ/G/EbhVPpfwZekb58C1bcgDYxNs4HoBaI6+Xaub9Keye1tbR5zlfsT6 Gz2+gaPUwBQAyj03QQuRf2kBgVSkvsGV79VqA= Received: by 10.223.103.134 with SMTP id k6mr10904067fao.5.1281019743598; Thu, 05 Aug 2010 07:49:03 -0700 (PDT) Received: from a83-245-209-102.elisa-laajakaista.fi (a83-245-209-102.elisa-laajakaista.fi [83.245.209.102]) by mx.google.com with ESMTPS id p2sm118417fak.22.2010.08.05.07.49.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 07:49:02 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Aug 2010 17:48:59 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] New milestones proporal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 14:48:36 -0000 Hello, As indicated in Maastricht meeting we are in a process of updating Dime = WG milestones. See below the proposal for the updated milestones. = Comments are solicited. - Jouni & Lionel = --------------------------------------------------------------------------= ------ Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the = IESG for consideration as a Proposed Standards: * 'Diameter Mobile IPv6: Support for Home Agent to Diameter = Server=20 Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server = to=20 Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an=20= Informational RFC Done - Submit 'Quality of Service Parameters for Usage with = Diameter' to=20 the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for = consideration as=20 a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication = Protocol' as=20 DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing=20= Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group = item Done - Submit 'Quality of Service Attributes for Diameter' to the = IESG for=20 consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for = consideration=20 as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing=20= Clarifications' to the IESG for consideration as a Proposed=20= Standard Done - Submit 'Updated IANA Considerations for Diameter Command = Code=20 Allocations' as DIME working group item Done - Submit 'Updated IANA Considerations for Diameter Command = Code=20 Allocations' to the IESG for consideration as a Proposed = Standard Done - Submit 'Diameter NAT Control Application' as DIME working = group=20 item Done - Submit 'Diameter Capabilities Update' as DIME working group = item Done - Submit 'Diameter Credit Control Application MIB' to the = IESG for=20 consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for = consideration=20 as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for = consideration=20 as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME = working=20 group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic = Key=20 Transport' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized = Routing'=20 as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME = working group=20 item Done - Submit 'Diameter Extended NAPTR' as DIME working group item Aug 2010 - Submit Revision of 'Diameter Network Access Server = Application -=20 RFC 4005bis' as DIME working group item Aug 2010 - Submit Revision of 'Diameter Base Protocol' to the IESG for=20= consideration as a Proposed Standard Aug 2010 - Submit 'Diameter Priority Attribute Value Pairs' to the = IESG for=20 consideration as a Proposed Standard Aug 2010 - Submit 'Diameter Attribute-Value Pairs for Cryptographic = Key=20 Transport' to the IESG for consideration as a Proposed = Standard Sep 2010 - Submit 'Diameter Application Design Guidelines' to the IESG = for=20 consideration as a BCP document Sep 2010 - Submit 'Diameter NAT Control Application' to the IESG for=20= consideration as a Proposed Standard Sep 2010 - Submit 'Diameter IKEv2 PSK' to the IESG for consideration = as a=20 Proposed Standard Sep 2010 - Submit 'Realm-Based Redirection In Diameter' to the IESG = for=20 consideration as a Proposed Standard Oct 2010 - Submit 'Diameter Extended NAPTR' to the IESG for = consideration as a=20 Proposed Standard Nov 2010 - Submit 'Diameter Support for Proxy Mobile IPv6 Localized = Routing'=20 to the IESG for consideration as a Proposed Standard Nov 2010 - Submit 'Diameter Support for EAP Re-authentication = Protocol' to the=20 IESG for consideration as a Proposed Standard Jan 2011 - Submit new DIME charter to the IESG Nov 2011 - Submit Revision of 'Diameter Network Access Server = Application -=20 RFC 4005bis' to the IESG for consideration as a Proposed = Standard From dlehmann@ulticom.com Thu Aug 5 08:14:44 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CA93A63D3 for ; Thu, 5 Aug 2010 08:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9DvLyYMu9LY for ; Thu, 5 Aug 2010 08:14:43 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 564B83A6800 for ; Thu, 5 Aug 2010 08:14:42 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 613AA24E8DE2ACA0; Thu, 5 Aug 2010 11:15:08 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o75FEuRd003292; Thu, 5 Aug 2010 11:15:01 -0400 (EDT) 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: Thu, 5 Aug 2010 11:14:56 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0q2DAhXu+Yo8fRdG5c82HU3IGswAAq1TA References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 15:14:44 -0000 > Unless I'm missing something, Proxy-Info can be included in an stateful application which=20 > can control it's lifetime .... so I'm still not sure why we need a new AVP that means=20 > the same thing. How does one control the lifetime of the Proxy-Info? The RFC currently states, "If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded." Look at the original diagram. The Proxy-Info (PI) was added to R1 by the Agent, but the Agent "MUST" remove the Proxy Info before forwarding the answer to the client. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| The proposed Private-Info AVP would be the same as the Proxy-Info, except that it lasts for the whole session (or until the owner removes it). Again the diagram with PI being the Private-Info. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| So the Private-Info is different from the Proxy-Info, but only in regards to lifetime. -David From jouni.nospam@gmail.com Thu Aug 5 08:20:34 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FC03A67D1 for ; Thu, 5 Aug 2010 08:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLmTvg4YBsSy for ; Thu, 5 Aug 2010 08:20:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7DB1C3A63D3 for ; Thu, 5 Aug 2010 08:20:26 -0700 (PDT) Received: by fxm16 with SMTP id 16so2375043fxm.31 for ; Thu, 05 Aug 2010 08:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=sJBgsAncohgE1XBgqiBwiZSHqoJ9pn41U8tvyRs1wRY=; b=vHQwkQRcWMq9PQklh/+jcv+avn04/KPHObBjSE7Kg09nPwge2MhGLwtSR/sHN7exqE GSRMrvwz0zRX664V0SDPIRCEcYvFViJEEG5Q+6eSo4jnRaDu/Yf9at9905z1KPcnoVyA 8Nd1gMwy5sgWnAdP9lV/lVABDyf/A1Te4VKII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=vMHttI/HKzq3N2xMqot+gdCeQNglCXTPdCi5UX3EFHlmfsnHvQjCuKv2e4bc7cyUOb 461xRC2V//4JLjBdmmipm6U6DvnlnpyVQ1tPuWXLliom2zu1DlTtZg4nvfSenD1dZq+R ux0LkQgP7ZqaPjJJ+jqgvAtMajRYb8oIgGSZM= Received: by 10.223.103.198 with SMTP id l6mr10809722fao.102.1281021655695; Thu, 05 Aug 2010 08:20:55 -0700 (PDT) Received: from a83-245-209-102.elisa-laajakaista.fi (a83-245-209-102.elisa-laajakaista.fi [83.245.209.102]) by mx.google.com with ESMTPS id r5sm139326faq.32.2010.08.05.08.20.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 08:20:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <4C5A5F2D.20508@nict.go.jp> Date: Thu, 5 Aug 2010 18:20:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8F72C746-6A94-462B-B167-31830A0ED676@gmail.com> References: <4C5A5F2D.20508@nict.go.jp> To: Sebastien Decugis X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 15:20:34 -0000 Hi, On Aug 5, 2010, at 9:50 AM, Sebastien Decugis wrote: > Hello, >=20 > "[...] RFC 4005 in general and RADIUS-Diameter > interoperability in particular. In Anaheim we decided to just try = removing > the RADIUS-it had ever actually been deployed) & see who screamed in > pain ;-)" >=20 > If the main rationale for this revision is just to remove the > RADIUS/Diameter translation explanations, as the above excerpt seems = to > indicate, I would rather see the adoption of this document postponned > until a suitable mechanism for RADIUS/Diameter interaction is = described > somewhere. And, for information, the mechanism described in 4005 is > implemented in freeDiameter, and so far, it works well :) I guess we need such document that describes the basics of the = RADIUS/Diameter interactions eventually. However, I just do not believe = a generic translation works in situations that actually are interesting = and non-trivial. One approach that can be done already today (and to my best knowledge is = already used) is just documenting the RADIUS/Diameter interactions per = application within a specific system deployment. - Jouni >=20 > My 2 cents, >=20 > Best regards, > Sebastien. >=20 >=20 >=20 > Le 02/08/2010 19:54, jouni korhonen a =E9crit : >> As discussed during the Maastricht DIME WG meeting, the chairs agreed = to confirm the adoption of draft-zorn-dime-rfc4005bis-01 as the WG Item. = The work regarding RFC4005bis has been around the corner for some time = and discussed several times among AAA Doctors. There was support for the = adoption during the WG meeting. >>=20 >> The one week poll ends 9-Aug-2010, 23:59 (CEST+1).. Silence counts = also as "yes", so unless you have a strong reason to disagree (like the = North Pole melts or Diameter will become obsolete due the adoption of = this draft), then express your "no" on the list with a proper reasoning = why. Technical details on the actual draft content can be handled later = (if/when the document gets adopted). >>=20 >> - Jouni & Lionel >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > --=20 > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dlehmann@ulticom.com Thu Aug 5 08:21:48 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC953A67C3 for ; Thu, 5 Aug 2010 08:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2uI-BJixY6X for ; Thu, 5 Aug 2010 08:21:47 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 605433A6800 for ; Thu, 5 Aug 2010 08:21:47 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id E84BA27CC5F3D835; Thu, 5 Aug 2010 11:22:17 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o75FMHOq003559; Thu, 5 Aug 2010 11:22:17 -0400 (EDT) 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: Thu, 5 Aug 2010 11:22:17 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Dime] Private-Info AVP Thread-Index: Acs0p+kVs2c/NWP4RLOzXb0I8Kh/qQAAOt2Q References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: "David Lehmann" To: "rajithr 70236" Received-SPF: none Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 15:21:48 -0000 > > The Proxy-Info has a limited lifespan. The Private-Info is the > > same as > > the Proxy-Info except that it lasts then entire session. (See the > > original > > example.) >=20 > Why should a (session) stateless agent need to have such a mechanism that > lasts the entire session? ...in order for the agent to be stateless. If the agent can store information in the message, it does not need to store it in the agent (which would be make it stateful). Without the Private-Info AVP, an otherwise stateless agent must be come stateful. -David From vf0213@gmail.com Thu Aug 5 09:18:30 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F4B3A6B36 for ; Thu, 5 Aug 2010 09:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4B8-X7nanlH for ; Thu, 5 Aug 2010 09:18:29 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 7D0063A6B70 for ; Thu, 5 Aug 2010 09:18:00 -0700 (PDT) Received: by eyb7 with SMTP id 7so2746841eyb.31 for ; Thu, 05 Aug 2010 09:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/tiNrgy+8BNmCT1QszjRJUZCmkTUFbpcAtCg+PCPyfg=; b=vzubxaJaW7VXXDCE1rHEOKcR7XQw6aUV0B0vE+gvAWNiqM0ljlrOCW/h2GXVbQMoi2 Mu1/DTIynPl6K+28rZU/kKp3HxDzux53//B2mC2VSf2HQ4kEGnOqNOXgQhvT6BgOWPIu dcJ94k3+RPaa7qhA2FpQ14GtcX9WFhQoXCitw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X+9tpi1m0RIC17ZDjr/L6QVaHiTG7WgTONxv4eXeKMJ0vWnBMdUtOmy7lNGz1Yn4mT CIqR6uNtWSiRDi0E25b2nIJh7Lyc0QdVTWeJdD1ExQG8t4ZIWCjHRuBsWMVrOQVlRtU6 vVDFDYjYINLWSXVKpSL1RkYVlrWVhuj2GzVtg= MIME-Version: 1.0 Received: by 10.216.234.97 with SMTP id r75mr3779833weq.27.1281025110312; Thu, 05 Aug 2010 09:18:30 -0700 (PDT) Received: by 10.216.167.67 with HTTP; Thu, 5 Aug 2010 09:18:30 -0700 (PDT) In-Reply-To: References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> Date: Thu, 5 Aug 2010 12:18:30 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=000e0cdf8c20a60723048d15e60e Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 16:18:31 -0000 --000e0cdf8c20a60723048d15e60e Content-Type: text/plain; charset=ISO-8859-1 Ok. Then rolling back to the same line of questioning ... why do you want to generalize this ? Other applications commonly define their own AVP's to accomodate round-trip information such as this. regards, victor On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann wrote: > > Unless I'm missing something, Proxy-Info can be included in an > stateful application which > > can control it's lifetime .... so I'm still not sure why we need a new > AVP that means > > the same thing. > > > How does one control the lifetime of the Proxy-Info? The RFC currently > states, > "If the last Proxy-Info AVP in the message is targeted to the local > Diameter server, the AVP MUST be removed before the answer is > forwarded." > > Look at the original diagram. The Proxy-Info (PI) was added to R1 by the > Agent, but the Agent "MUST" remove the Proxy Info before forwarding the > answer to the client. > > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1 | A1+PI | > |<------------------------|<----------------------| > | | | > | R2 | R2+PI | > |------------------------>|---------------------->| > | | | > | A2 | A2+PI | > |<------------------------|<----------------------| > > > The proposed Private-Info AVP would be the same as the Proxy-Info, > except that it lasts for the whole session (or until the owner removes > it). Again the diagram with PI being the Private-Info. > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1+PI | A1+PI | > |<------------------------|<----------------------| > | | | > | R2+PI | R2+PI | > |------------------------>|---------------------->| > | | | > | A2+PI | A2+PI | > |<------------------------|<----------------------| > > > So the Private-Info is different from the Proxy-Info, but only in > regards to lifetime. > > -David > > --000e0cdf8c20a60723048d15e60e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok. Then rolling=A0back to the same line of questioning=A0... why do y= ou want to generalize this ? Other applications commonly define their own A= VP's to accomodate round-trip information such as this.

regards,
victor

=A0
On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann <= span dir=3D"ltr"><dlehmann@ultic= om.com> wrote:
> Unless I'm missing something, Proxy-Info can be = included in an
stateful application which
> can control it's l= ifetime .... so I'm still not sure why we need a new
AVP that means<= br> > the same thing.


How does one control the lifetime of = the Proxy-Info? The RFC currently
states,
=A0 "If the last Proxy= -Info AVP in the message is targeted to the local
=A0 Diameter server, t= he AVP MUST be removed before the answer is
forwarded."

Look at the original diagram. The Proxy-Info (PI) w= as added to R1 by the
Agent, but the Agent "MUST" remove the P= roxy Info before forwarding the
answer to the client.


Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Agent = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A/S
=A0| =A0 =A0 =A0 =A0 =A0R1 = =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R1+PI =A0 =A0 =A0 =A0 |
=A0|--= ---------------------->|---------------------->|
=A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A1 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 A1+PI = =A0 =A0 =A0 =A0 |
=A0|<------------------------|<-----------------= -----|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0R2 =A0 =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R2+PI =A0 =A0 =A0 =A0 |
=A0|------------------------>|---------------------->|
=A0| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A2 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 =A0 =A0 =A0 A2+PI =A0 =A0 =A0 =A0 |
=A0|<------------------------= |<----------------------|


The proposed Private-Info AVP would be the same as the Proxy-= Info,
except that it lasts for the whole session (or until the owner rem= oves
it). =A0Again the diagram with PI being the Private-Info.

Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Agent = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A/S
=A0| =A0 =A0 =A0 =A0 =A0R1 = =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R1+PI =A0 =A0 =A0 =A0 |
=A0|--= ---------------------->|---------------------->|
=A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A1+PI =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 A1+PI = =A0 =A0 =A0 =A0 |
=A0|<------------------------|<-----------------= -----|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0R2+PI =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 R2+PI =A0 =A0 =A0 =A0 |
=A0|------------------------>|---------------------->|
=A0| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A2+PI =A0 =A0 =A0 =A0 =A0| =A0= =A0 =A0 =A0 A2+PI =A0 =A0 =A0 =A0 |
=A0|<------------------------|&l= t;----------------------|


So the Private-Info is different from the Proxy-Info, but onl= y in
regards to lifetime.

-David

<= /font>

--000e0cdf8c20a60723048d15e60e-- From gwz@net-zen.net Thu Aug 5 10:37:38 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F09D3A6A98 for ; Thu, 5 Aug 2010 10:37:36 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVUZ7LOArJK0 for ; Thu, 5 Aug 2010 10:37:32 -0700 (PDT) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id 9C3E23A6B34 for ; Thu, 5 Aug 2010 10:37:26 -0700 (PDT) Received: (qmail 3878 invoked from network); 5 Aug 2010 17:36:44 -0000 Received: from unknown (195.46.229.98) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 05 Aug 2010 17:36:44 -0000 From: "Glen Zorn" To: "'jouni korhonen'" References: In-Reply-To: Date: Thu, 5 Aug 2010 19:36:40 +0200 Organization: Network Zen Message-ID: <00bc01cb34c4$c4a5ddb0$4df19910$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs0rV8e9T7iPL8jQJScsziaJgTj7wAFpraw Content-Language: en-us Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] New milestones proporal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 17:37:38 -0000 jouni korhonen [mailto://jouni.nospam@gmail.com] writes: > Hello, > > As indicated in Maastricht meeting we are in a process of updating Dime > WG milestones. See below the proposal for the updated milestones. > Comments are solicited. I really think that ERP & 4005bis should probably switch places, given the pace at which the ERP app has been progressing, the level of confusion in the hokey WG & the simplicity of 4005bis. > > - Jouni & Lionel > > > ------------------------------------------------------------------------ > -------- > > Goals and Milestones: > Done - Submit the following two Diameter Mobility documents to the > IESG > for consideration as a Proposed Standards: > * 'Diameter Mobile IPv6: Support for Home Agent to Diameter > Server > Interaction' > * 'Diameter Mobile IPv6: Support for Network Access Server > to > Diameter Server Interaction' > Done - Submit 'Diameter API' to the IESG for consideration as an > Informational RFC > Done - Submit 'Quality of Service Parameters for Usage with > Diameter' to > the IESG for consideration as a Proposed Standard. > Done - Submit 'Diameter QoS Application' to the IESG for > consideration as > a Proposed Standard > Done - Submit 'Diameter Support for EAP Re-authentication > Protocol' as > DIME working group item > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' as DIME working group item > Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group > item > Done - Submit 'Quality of Service Attributes for Diameter' to the > IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > consideration > as a Proposed Standard > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Updated IANA Considerations for Diameter Command > Code > Allocations' as DIME working group item > Done - Submit 'Updated IANA Considerations for Diameter Command > Code > Allocations' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter NAT Control Application' as DIME working > group > item > Done - Submit 'Diameter Capabilities Update' as DIME working group > item > Done - Submit 'Diameter Credit Control Application MIB' to the > IESG for > consideration as an Informational RFC > Done - Submit 'Diameter Base Protocol MIB' to the IESG for > consideration > as an Informational RFC > Done - Submit 'Diameter Capabilities Update' to the IESG for > consideration > as a Proposed Standard > > Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME > working > group item > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key > Transport' as DIME working group item > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' > as DIME working group item > Done - Submit 'Realm-Based Redirection In Diameter' as DIME > working group > item > Done - Submit 'Diameter Extended NAPTR' as DIME working group item > > Aug 2010 - Submit Revision of 'Diameter Network Access Server > Application - > RFC 4005bis' as DIME working group item > Aug 2010 - Submit Revision of 'Diameter Base Protocol' to the IESG for > consideration as a Proposed Standard > Aug 2010 - Submit 'Diameter Priority Attribute Value Pairs' to the > IESG for > consideration as a Proposed Standard > Aug 2010 - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key > Transport' to the IESG for consideration as a Proposed > Standard > Sep 2010 - Submit 'Diameter Application Design Guidelines' to the IESG > for > consideration as a BCP document > Sep 2010 - Submit 'Diameter NAT Control Application' to the IESG for > consideration as a Proposed Standard > Sep 2010 - Submit 'Diameter IKEv2 PSK' to the IESG for consideration > as a > Proposed Standard > Sep 2010 - Submit 'Realm-Based Redirection In Diameter' to the IESG > for > consideration as a Proposed Standard > Oct 2010 - Submit 'Diameter Extended NAPTR' to the IESG for > consideration as a > Proposed Standard > Nov 2010 - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' > to the IESG for consideration as a Proposed Standard > Nov 2010 - Submit 'Diameter Support for EAP Re-authentication > Protocol' to the > IESG for consideration as a Proposed Standard > Jan 2011 - Submit new DIME charter to the IESG > Nov 2011 - Submit Revision of 'Diameter Network Access Server > Application - > RFC 4005bis' to the IESG for consideration as a Proposed > Standard > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dlehmann@ulticom.com Thu Aug 5 11:03:40 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C763A68AF for ; Thu, 5 Aug 2010 11:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTkWgxuzHLD1 for ; Thu, 5 Aug 2010 11:03:34 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 750D73A63C9 for ; Thu, 5 Aug 2010 11:03:34 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 1202936F0DF2B459; Thu, 5 Aug 2010 14:04:04 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o75I43iV028343; Thu, 5 Aug 2010 14:04:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB34C8.9699EDA2" Date: Thu, 5 Aug 2010 14:04:03 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0udkLD3Isiw4CQgeXYr/nUpurugADCsDw References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 18:03:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB34C8.9699EDA2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposal is primarily for agents, not applications. (Although, I have no problem with applications employing the new AVP.) Agents can introduce the Private-Info into the messages to allow it to remain stateless without having knowledge of specific applications. =20 =20 Besides, you don't want an agent using an AVP which was intended be used for applications just because the AVP has the property of surviving on all legs of a session. An agent should introduce its own data in an AVP which is opaque to other nodes. It is cleaner, IMHO. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 12:19 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP =20 Ok. Then rolling back to the same line of questioning ... why do you want to generalize this ? Other applications commonly define their own AVP's to accomodate round-trip information such as this.=20 regards, victor =20 On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann wrote: > Unless I'm missing something, Proxy-Info can be included in an stateful application which > can control it's lifetime .... so I'm still not sure why we need a new AVP that means > the same thing. How does one control the lifetime of the Proxy-Info? The RFC currently states, "If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded." Look at the original diagram. The Proxy-Info (PI) was added to R1 by the Agent, but the Agent "MUST" remove the Proxy Info before forwarding the answer to the client. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| The proposed Private-Info AVP would be the same as the Proxy-Info, except that it lasts for the whole session (or until the owner removes it). Again the diagram with PI being the Private-Info. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| So the Private-Info is different from the Proxy-Info, but only in regards to lifetime. -David =20 ------_=_NextPart_001_01CB34C8.9699EDA2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The proposal is primarily  for = agents, not applications. (Although, I have no problem with applications employing = the new AVP.)  Agents can introduce the Private-Info into the messages to = allow it to remain stateless without having knowledge of specific applications. =    

 

Besides, you don’t want an agent using an AVP which = was intended be used for applications just because the AVP has the property = of surviving on all legs of a session.  An agent should introduce its = own data in an AVP which is opaque to other nodes.  It is cleaner, = IMHO.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 12:19 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject: Re: [Dime] Private-Info AVP

 

Ok. Then rolling back to the same line of questioning ... why do you want to generalize this ? Other = applications commonly define their own AVP's to accomodate round-trip information = such as this.


regards,

victor


 

On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann = <dlehmann@ulticom.com> = wrote:

> Unless I'm = missing something, Proxy-Info can be included in an
stateful application which
> can control it's lifetime .... so I'm still not sure why we need a = new
AVP that means
> the same thing.

How does one control = the lifetime of the Proxy-Info? The RFC currently
states,
  "If the last Proxy-Info AVP in the message is targeted to = the local
  Diameter server, the AVP MUST be removed before the answer is
forwarded."

Look at the original diagram. The Proxy-Info (PI) was added to R1 by = the
Agent, but the Agent "MUST" remove the Proxy Info before = forwarding the
answer to the client.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1         =     |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2         =     |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2         =     |         A2+PI         = |
 |<------------------------|<----------------------|

The proposed Private-Info AVP would be the same as = the Proxy-Info,
except that it lasts for the whole session (or until the owner = removes
it).  Again the diagram with PI being the = Private-Info.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1+PI       =    |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2+PI       =    |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2+PI       =    |         A2+PI         = |
 |<------------------------|<----------------------|

So the Private-Info = is different from the Proxy-Info, but only in
regards to lifetime.

-David

 

------_=_NextPart_001_01CB34C8.9699EDA2-- From vf0213@gmail.com Thu Aug 5 11:06:53 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872343A6A04 for ; Thu, 5 Aug 2010 11:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMMUc1pxxSCA for ; Thu, 5 Aug 2010 11:06:52 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 96CC03A68C8 for ; Thu, 5 Aug 2010 11:06:51 -0700 (PDT) Received: by wwf26 with SMTP id 26so3834620wwf.1 for ; Thu, 05 Aug 2010 11:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hGZlEW30891NZ/oDM98McWfywS09HhqrV8nLbQmvKqM=; b=c9aTFQqBJOwzwSQo4KklecTwWt3WF6GBcOzhwUVsxXvZAOtS54YbO0ZE8rtJQpphv+ x4TAmlLKgtTLkzJAe2+iwwNsxystAanx8dynNM+/778x5LXacuIF6hGtUDWoMzLXmTmi rIzAlD+inQ1MYm2qPLBQRLO5ppkqfLKKZFToE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=quk+Tyv5FzTIUKOaR6KN4QEmEKbAkmnEavrB91VmDhn5pzwXy//iNIyV9ohkbtycDO 2jaKzuLSRRVYayuPzjOD+tQ8WO6VymUWTUAIvO3zvH8FYlLfTMjMDsJl1d+3BPcWyY3Q JLRiHlmu0qO3I3TiQjHxdF/LRDHq6r9dtlO9Q= MIME-Version: 1.0 Received: by 10.216.79.66 with SMTP id h44mr9613152wee.6.1281031641521; Thu, 05 Aug 2010 11:07:21 -0700 (PDT) Received: by 10.216.167.67 with HTTP; Thu, 5 Aug 2010 11:07:21 -0700 (PDT) In-Reply-To: References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> Date: Thu, 5 Aug 2010 14:07:21 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=000e0cdf7468f06071048d176b1d Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 18:06:53 -0000 --000e0cdf7468f06071048d176b1d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann wrote: > *The proposal is primarily for agents*, not applications. (Although, I > have no problem with applications employing the new AVP.) Agents can > introduce the Private-Info into the messages to allow it to remain statel= ess > without having knowledge of specific applications. > > > > Besides, you don=92t want an agent using an AVP which was intended be use= d > for applications just because the AVP has the property of surviving on al= l > legs of a session. An agent should introduce its own data in an AVP whic= h > is opaque to other nodes. It is cleaner, IMHO. > But the content(s) and semantcis of the Private-Info is known only to the application :) ... so I'm not convinced if its really cleaner :) regards, victor > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Thursday, August 05, 2010 12:19 PM > *To:* David Lehmann > *Cc:* rajithr 70236; Daily William; dime@ietf.org > > *Subject:* Re: [Dime] Private-Info AVP > > > > Ok. Then rolling back to the same line of questioning ... why do you want > to generalize this ? Other applications commonly define their own AVP's t= o > accomodate round-trip information such as this. > > > regards, > > victor > > > > > On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann > wrote: > > > Unless I'm missing something, Proxy-Info can be included in an > stateful application which > > can control it's lifetime .... so I'm still not sure why we need a new > AVP that means > > the same thing. > > How does one control the lifetime of the Proxy-Info? The RFC currently > states, > "If the last Proxy-Info AVP in the message is targeted to the local > Diameter server, the AVP MUST be removed before the answer is > forwarded." > > Look at the original diagram. The Proxy-Info (PI) was added to R1 by the > Agent, but the Agent "MUST" remove the Proxy Info before forwarding the > answer to the client. > > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1 | A1+PI | > |<------------------------|<----------------------| > | | | > | R2 | R2+PI | > |------------------------>|---------------------->| > | | | > | A2 | A2+PI | > |<------------------------|<----------------------| > > The proposed Private-Info AVP would be the same as the Proxy-Info, > except that it lasts for the whole session (or until the owner removes > it). Again the diagram with PI being the Private-Info. > > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1+PI | A1+PI | > |<------------------------|<----------------------| > | | | > | R2+PI | R2+PI | > |------------------------>|---------------------->| > | | | > | A2+PI | A2+PI | > |<------------------------|<----------------------| > > So the Private-Info is different from the Proxy-Info, but only in > regards to lifetime. > > -David > > > --000e0cdf7468f06071048d176b1d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

=A0
On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann <dlehmann@ultico= m.com> wrote:

T= he proposal is primarily =A0for agents, not applications. (Although, I have no problem with= applications employing the new AVP.)=A0 Agents can introduce the Private-I= nfo into the messages to allow it to remain stateless without having knowle= dge of specific applications. =A0=A0=A0

=A0<= /span>

Besi= des, you don=92t want an agent using an AVP which was intended be used for = applications just because the AVP has the property of surviving on all legs= of a session.=A0 An agent should introduce its own data in an AVP which is= opaque to other nodes.=A0 It is cleaner, IMHO.

=A0
=A0
But the content(s) and semantcis=A0of the Private-Info is known only t= o the application :) ... so I'm not convinced if its really cleaner :)<= /div>
=A0
regards,
victor
=A0
=A0
=A0

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Th= ursday, August 05, 2010 12:19 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org=20


Subject: Re: [Dime] Private-Info AVP

=A0

Ok. Then rolling=A0back to the same line of question= ing=A0... why do you want to generalize this ? Other applications commonly = define their own AVP's to accomodate round-trip information such as thi= s.


regards,

victor


=A0

On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

> Unless I'm mi= ssing something, Proxy-Info can be included in an
stateful application w= hich
> can control it's lifetime .... so I'm still not sure w= hy we need a new
AVP that means
> the same thing.

How does one control t= he lifetime of the Proxy-Info? The RFC currently
states,
=A0 "If= the last Proxy-Info AVP in the message is targeted to the local
=A0 Dia= meter server, the AVP MUST be removed before the answer is
forwarded."

Look at the original diagram. The Proxy-Info (PI) w= as added to R1 by the
Agent, but the Agent "MUST" remove the P= roxy Info before forwarding the
answer to the client.


Client =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0Agent =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A/= S
=A0| =A0 =A0 =A0 =A0 =A0R1 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R= 1+PI =A0 =A0 =A0 =A0 |
=A0|------------------------>|----------------= ------>|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A1 =A0 =A0 =A0 =A0 =A0= =A0 | =A0 =A0 =A0 =A0 A1+PI =A0 =A0 =A0 =A0 |
=A0|<-----------------= -------|<----------------------|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0R2 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R2+PI = =A0 =A0 =A0 =A0 |
=A0|------------------------>|---------------------= ->|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A2 =A0 =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 A2+PI =A0 =A0 =A0 =A0 |
=A0|<------------------------|<----------------------|

The proposed Private-Info AVP would be the same as t= he Proxy-Info,
except that it lasts for the whole session (or until the = owner removes
it). =A0Again the diagram with PI being the Private-Info.<= /p>


Client =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0Agent =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A/= S
=A0| =A0 =A0 =A0 =A0 =A0R1 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R= 1+PI =A0 =A0 =A0 =A0 |
=A0|------------------------>|----------------= ------>|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A1+PI =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 A1+PI =A0 =A0 =A0 =A0 |
=A0|<-------------------= -----|<----------------------|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0R2+PI =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 R2+PI = =A0 =A0 =A0 =A0 |
=A0|------------------------>|---------------------= ->|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A2+PI =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 A2+PI =A0 =A0 =A0 =A0 |
=A0|<------------------------|<----------------------|

So the Private-Info is= different from the Proxy-Info, but only in
regards to lifetime.

-David

=A0


--000e0cdf7468f06071048d176b1d-- From dlehmann@ulticom.com Thu Aug 5 11:18:17 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294D93A6A8A for ; Thu, 5 Aug 2010 11:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSizNC24wI+o for ; Thu, 5 Aug 2010 11:18:11 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 990903A6881 for ; Thu, 5 Aug 2010 11:18:04 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 7A97936E89F32C82; Thu, 5 Aug 2010 14:18:33 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o75IIWwk028586; Thu, 5 Aug 2010 14:18:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB34CA.9CB4BAEA" Date: Thu, 5 Aug 2010 14:17:19 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0yQ9etU20qKkcQbigl15YOq8IyQAALXXA References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 18:18:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB34CA.9CB4BAEA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forget the applications using this AVP. Think about agents. It is opaque to the applications... just like the Proxy-Info. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 2:07 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP =20 =20 On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann wrote: The proposal is primarily for agents, not applications. (Although, I have no problem with applications employing the new AVP.) Agents can introduce the Private-Info into the messages to allow it to remain stateless without having knowledge of specific applications. =20 =20 Besides, you don't want an agent using an AVP which was intended be used for applications just because the AVP has the property of surviving on all legs of a session. An agent should introduce its own data in an AVP which is opaque to other nodes. It is cleaner, IMHO. =20 =20 But the content(s) and semantcis of the Private-Info is known only to the application :) ... so I'm not convinced if its really cleaner :) =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 12:19 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org=20 =09 Subject: Re: [Dime] Private-Info AVP =20 Ok. Then rolling back to the same line of questioning ... why do you want to generalize this ? Other applications commonly define their own AVP's to accomodate round-trip information such as this.=20 =09 regards, victor =09 =20 On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann wrote: > Unless I'm missing something, Proxy-Info can be included in an stateful application which > can control it's lifetime .... so I'm still not sure why we need a new AVP that means > the same thing. How does one control the lifetime of the Proxy-Info? The RFC currently states, "If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded." =09 Look at the original diagram. The Proxy-Info (PI) was added to R1 by the Agent, but the Agent "MUST" remove the Proxy Info before forwarding the answer to the client. =09 Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| The proposed Private-Info AVP would be the same as the Proxy-Info, except that it lasts for the whole session (or until the owner removes it). Again the diagram with PI being the Private-Info. =09 Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| So the Private-Info is different from the Proxy-Info, but only in regards to lifetime. =09 -David =20 =20 ------_=_NextPart_001_01CB34CA.9CB4BAEA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forget the applications using this AVP.  Think about agents.  It is opaque to the applications… just like the = Proxy-Info.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 2:07 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject: Re: [Dime] Private-Info AVP

 


 

On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann = <dlehmann@ulticom.com> = wrote:

The proposal is primarily =  for agents, not applications. (Although, I have no problem with applications employing = the new AVP.)  Agents can introduce the Private-Info into the messages to = allow it to remain stateless without having knowledge of specific applications.    

 

Besides, you don’t want = an agent using an AVP which was intended be used for applications just because = the AVP has the property of surviving on all legs of a session.  An agent = should introduce its own data in an AVP which is opaque to other nodes.  = It is cleaner, IMHO.

 

 

But the content(s) and semantcis of the = Private-Info is known only to the application :) ... so I'm not convinced if its really = cleaner :)

 

regards,

victor

 

 

 

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 12:19 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org


Subject: Re: [Dime] Private-Info AVP

 <= /o:p>

Ok. Then rolling back to the same line of questioning ... why do = you want to generalize this ? Other applications commonly define their own AVP's = to accomodate round-trip information such as this.


regards,

victor<= /o:p>


 

On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann <dlehmann@ulticom.com> wrote:

> Unless I'm missing something, Proxy-Info can be included in an
stateful application which
> can control it's lifetime .... so I'm still not sure why we need a = new
AVP that means
> the same thing.

How does one control the lifetime of the Proxy-Info? The RFC currently
states,
  "If the last Proxy-Info AVP in the message is targeted to = the local
  Diameter server, the AVP MUST be removed before the answer is
forwarded."

Look at the original diagram. The Proxy-Info (PI) was added to R1 by = the
Agent, but the Agent "MUST" remove the Proxy Info before = forwarding the
answer to the client.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1         =     |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2         =     |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2         =     |         A2+PI         = |
 |<------------------------|<----------------------|

The proposed Private-Info AVP would be the same as the Proxy-Info,
except that it lasts for the whole session (or until the owner = removes
it).  Again the diagram with PI being the = Private-Info.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1+PI       =    |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2+PI       =    |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2+PI       =    |         A2+PI         = |
 |<------------------------|<----------------------|

So the Private-Info is different from the Proxy-Info, but only in
regards to lifetime.

-David

 <= /o:p>

 

------_=_NextPart_001_01CB34CA.9CB4BAEA-- From vf0213@gmail.com Thu Aug 5 11:28:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF143A6B3D for ; Thu, 5 Aug 2010 11:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OiBfuXbU6zb for ; Thu, 5 Aug 2010 11:28:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DA52B3A6A2D for ; Thu, 5 Aug 2010 11:28:27 -0700 (PDT) Received: by wwj40 with SMTP id 40so281439wwj.13 for ; Thu, 05 Aug 2010 11:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qcUeGeSlty9objWQOA25AcNBmmCOcNIBHeXlcNaNvAo=; b=NXJQjN27TwSs/OHBgcDh61EnqVc/0u8L/FZsXHQBX3zJ8vYl07wD9t1MrWKElyFkhc dp63hkzPgbSC1nQITt/6Ko7C/OUjVzxnFK04SRGh2RiQ1Vm0ckQhiMws7dZiPgRHgT+V 4r2tvAQLHrke5QfOmsSEIXUg8Cp0AjbltDpX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UkNihhikqLhA5qffDbvraN7ouPp7zYFsP4zgqSF4KB1FH1oNXFGHEk8sxiUF8jQOzW fh0j7TKJrAX0QV9yxNh3XGq52yf7/SluSlZCLdZOIOGFn2ufMLAjzxEQeS8gzqCvgZaA Hf23y/XPIZjQocv9iCAgeS4zD22lTM8PUQOEo= MIME-Version: 1.0 Received: by 10.227.129.12 with SMTP id m12mr9366944wbs.102.1281032937737; Thu, 05 Aug 2010 11:28:57 -0700 (PDT) Received: by 10.216.167.67 with HTTP; Thu, 5 Aug 2010 11:28:57 -0700 (PDT) In-Reply-To: References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> Date: Thu, 5 Aug 2010 14:28:57 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=001636457756330ff3048d17b9c6 Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 18:28:30 -0000 --001636457756330ff3048d17b9c6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable your agent is a proxy which means its doing more than just forwarding messages. by definition, if your a proxy you have an application running in this agent that does special handling with these messages prior to forwarding ... hence we keep going back to the term 'application'. On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann wrote: > Forget the applications using this AVP. Think about agents. It is > opaque to the applications=85 just like the Proxy-Info. > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Thursday, August 05, 2010 2:07 PM > > *To:* David Lehmann > *Cc:* rajithr 70236; Daily William; dime@ietf.org > *Subject:* Re: [Dime] Private-Info AVP > > > > > > > On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann > wrote: > > *The proposal is primarily for agents*, not applications. (Although, I > have no problem with applications employing the new AVP.) Agents can > introduce the Private-Info into the messages to allow it to remain statel= ess > without having knowledge of specific applications. > > > > Besides, you don=92t want an agent using an AVP which was intended be use= d > for applications just because the AVP has the property of surviving on al= l > legs of a session. An agent should introduce its own data in an AVP whic= h > is opaque to other nodes. It is cleaner, IMHO. > > > > > > But the content(s) and semantcis of the Private-Info is known only to the > application :) ... so I'm not convinced if its really cleaner :) > > > > regards, > > victor > > > > > > > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Thursday, August 05, 2010 12:19 PM > *To:* David Lehmann > *Cc:* rajithr 70236; Daily William; dime@ietf.org > > > *Subject:* Re: [Dime] Private-Info AVP > > > > Ok. Then rolling back to the same line of questioning ... why do you want > to generalize this ? Other applications commonly define their own AVP's t= o > accomodate round-trip information such as this. > > > regards, > > victor > > > > > On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann > wrote: > > > Unless I'm missing something, Proxy-Info can be included in an > stateful application which > > can control it's lifetime .... so I'm still not sure why we need a new > AVP that means > > the same thing. > > How does one control the lifetime of the Proxy-Info? The RFC currently > states, > "If the last Proxy-Info AVP in the message is targeted to the local > Diameter server, the AVP MUST be removed before the answer is > forwarded." > > Look at the original diagram. The Proxy-Info (PI) was added to R1 by the > Agent, but the Agent "MUST" remove the Proxy Info before forwarding the > answer to the client. > > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1 | A1+PI | > |<------------------------|<----------------------| > | | | > | R2 | R2+PI | > |------------------------>|---------------------->| > | | | > | A2 | A2+PI | > |<------------------------|<----------------------| > > The proposed Private-Info AVP would be the same as the Proxy-Info, > except that it lasts for the whole session (or until the owner removes > it). Again the diagram with PI being the Private-Info. > > > Client Agent A/S > | R1 | R1+PI | > |------------------------>|---------------------->| > | | | > | A1+PI | A1+PI | > |<------------------------|<----------------------| > | | | > | R2+PI | R2+PI | > |------------------------>|---------------------->| > | | | > | A2+PI | A2+PI | > |<------------------------|<----------------------| > > So the Private-Info is different from the Proxy-Info, but only in > regards to lifetime. > > -David > > > > > --001636457756330ff3048d17b9c6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
your agent is a proxy which means its doing more than just forwarding = messages. by definition, if your a proxy you=A0have an application running = in this agent that does special handling with these messages prior to forwa= rding ... hence we keep going back to the term 'application'.


=A0
On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann <dlehmann@ultico= m.com> wrote:

Forg= et the applications using this AVP.=A0 Think about agents.=A0 It is opaque = to the applications=85 just like the Proxy-Info.

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Th= ursday, August 05, 2010 2:07 PM=20


To: David Lehmann
Cc: rajithr 70236;= Daily William; dime@iet= f.org
Subject: Re: [Dime] Private-Info AVP

=A0


=A0

On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann <dlehmann@ulticom.co= m> wrote:

T= he proposal is primarily =A0for agents, not applications. (Although, I have no problem with= applications employing the new AVP.)=A0 Agents can introduce the Private-I= nfo into the messages to allow it to remain stateless without having knowle= dge of specific applications. =A0=A0=A0

=A0<= /span>

Besi= des, you don=92t want an agent using an AVP which was intended be used for = applications just because the AVP has the property of surviving on all legs= of a session.=A0 An agent should introduce its own data in an AVP which is= opaque to other nodes.=A0 It is cleaner, IMHO.

=A0

=A0

But the content(s) and semantcis=A0of the Private-In= fo is known only to the application :) ... so I'm not convinced if its = really cleaner :)

=A0

regards,

victor

=A0

=A0

=A0

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Th= ursday, August 05, 2010 12:19 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org


Subject: = Re: [Dime] Private-Info AVP

=A0

Ok. Then rolling=A0back to the same line of question= ing=A0... why do you want to generalize this ? Other applications commonly = define their own AVP's to accomodate round-trip information such as thi= s.


regards,

victor


=A0

On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

> Unless I'm mi= ssing something, Proxy-Info can be included in an
stateful application w= hich
> can control it's lifetime .... so I'm still not sure w= hy we need a new
AVP that means
> the same thing.

How does one control t= he lifetime of the Proxy-Info? The RFC currently
states,
=A0 "If= the last Proxy-Info AVP in the message is targeted to the local
=A0 Dia= meter server, the AVP MUST be removed before the answer is
forwarded."

Look at the original diagram. The Proxy-Info (PI) w= as added to R1 by the
Agent, but the Agent "MUST" remove the P= roxy Info before forwarding the
answer to the client.


Client =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0Agent =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A/= S
=A0| =A0 =A0 =A0 =A0 =A0R1 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R= 1+PI =A0 =A0 =A0 =A0 |
=A0|------------------------>|----------------= ------>|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A1 =A0 =A0 =A0 =A0 =A0= =A0 | =A0 =A0 =A0 =A0 A1+PI =A0 =A0 =A0 =A0 |
=A0|<-----------------= -------|<----------------------|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0R2 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R2+PI = =A0 =A0 =A0 =A0 |
=A0|------------------------>|---------------------= ->|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A2 =A0 =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 A2+PI =A0 =A0 =A0 =A0 |
=A0|<------------------------|<----------------------|

The proposed Private-Info AVP would be the same as t= he Proxy-Info,
except that it lasts for the whole session (or until the = owner removes
it). =A0Again the diagram with PI being the Private-Info.<= /p>


Client =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0Agent =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A/= S
=A0| =A0 =A0 =A0 =A0 =A0R1 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 R= 1+PI =A0 =A0 =A0 =A0 |
=A0|------------------------>|----------------= ------>|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A1+PI =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 A1+PI =A0 =A0 =A0 =A0 |
=A0|<-------------------= -----|<----------------------|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0R2+PI =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 R2+PI = =A0 =A0 =A0 =A0 |
=A0|------------------------>|---------------------= ->|
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0| =A0 =A0 =A0 =A0 =A0A2+PI =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 A2+PI =A0 =A0 =A0 =A0 |
=A0|<------------------------|<----------------------|

So the Private-Info is= different from the Proxy-Info, but only in
regards to lifetime.

-David

=A0

=A0


--001636457756330ff3048d17b9c6-- From root@core3.amsl.com Thu Aug 5 12:00:02 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 124B73A6948; Thu, 5 Aug 2010 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100805190002.124B73A6948@core3.amsl.com> Date: Thu, 5 Aug 2010 12:00:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-23.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 19:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-23.txt Pages : 158 Date : 2010-08-05 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-23.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-05114534.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Thu Aug 5 12:11:01 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDAA3A6807 for ; Thu, 5 Aug 2010 12:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+tE1Qt6ktQG for ; Thu, 5 Aug 2010 12:10:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7A93C3A657C for ; Thu, 5 Aug 2010 12:10:51 -0700 (PDT) Received: by fxm16 with SMTP id 16so2630906fxm.31 for ; Thu, 05 Aug 2010 12:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=962I23CTH7HEh3F7cXdJMOjKGrwifWA3ij1b+oGKF8Y=; b=QhaXOpCr4UI9fIL24DP0PT0640lfAa8OQoADY2ndgmvlXUNhmw5Cro7TWenHESlfkL YLO35OJVn+Pd/Pt22l2d2bL0NlUVAt0BTkEz+lDjInFK1zTDcNs9OZwuPAzizPXBLxUb jrBJGoKUDCrXgRcusXR+l4nhsWAqE5CtuUufU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=URlDiKsQqj0ssnkkQuCP1Un6ArEq9lf8oBtJC7ilwYN1g9Drr93oHKXEybcgn3ZBZD tWK5GZN20wNT2HBIouOTPkuy5ZZ8PXK+YAoH6tLTzXQ3o9RSRaZK6U1phBSeihMIqvuz wKtyRgHo6tsqhM/MxJ5BJVwfzkWZvInkD7ne8= Received: by 10.223.113.12 with SMTP id y12mr11315087fap.36.1281035481018; Thu, 05 Aug 2010 12:11:21 -0700 (PDT) Received: from a83-245-209-102.elisa-laajakaista.fi (a83-245-209-102.elisa-laajakaista.fi [83.245.209.102]) by mx.google.com with ESMTPS id r27sm246646faa.0.2010.08.05.12.11.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 12:11:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <00bc01cb34c4$c4a5ddb0$4df19910$@net> Date: Thu, 5 Aug 2010 22:11:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <425BF499-96F0-41EB-BE0E-65AAADA9F3C6@gmail.com> References: <00bc01cb34c4$c4a5ddb0$4df19910$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] New milestones proporal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 19:11:01 -0000 Hi, Righty, point taken. I'll give ERP some more time then. Honestly, I = would be amazed if RFC4005bis is a done deal in a year.. RFC3588bis was = supposed to be quick as well. So: Jun 2011 - Submit 'Diameter Support for EAP Re-authentication = Protocol' to the=20 IESG for consideration as a Proposed Standard Jan 2011 - Submit new DIME charter to the IESG Aug 2011 - Submit Revision of 'Diameter Network Access Server = Application -=20 RFC 4005bis' to the IESG for consideration as a Proposed = Standard - Jouni On Aug 5, 2010, at 8:36 PM, Glen Zorn wrote: > jouni korhonen [mailto://jouni.nospam@gmail.com] writes: >=20 >> Hello, >>=20 >> As indicated in Maastricht meeting we are in a process of updating = Dime >> WG milestones. See below the proposal for the updated milestones. >> Comments are solicited. >=20 > I really think that ERP & 4005bis should probably switch places, given = the > pace at which the ERP app has been progressing, the level of confusion = in > the hokey WG & the simplicity of 4005bis. >=20 >>=20 >> - Jouni & Lionel >>=20 >>=20 >> = ------------------------------------------------------------------------ >> -------- >>=20 >> Goals and Milestones: >> Done - Submit the following two Diameter Mobility documents to = the >> IESG >> for consideration as a Proposed Standards: >> * 'Diameter Mobile IPv6: Support for Home Agent to = Diameter >> Server >> Interaction' >> * 'Diameter Mobile IPv6: Support for Network Access = Server >> to >> Diameter Server Interaction' >> Done - Submit 'Diameter API' to the IESG for consideration as an >> Informational RFC >> Done - Submit 'Quality of Service Parameters for Usage with >> Diameter' to >> the IESG for consideration as a Proposed Standard. >> Done - Submit 'Diameter QoS Application' to the IESG for >> consideration as >> a Proposed Standard >> Done - Submit 'Diameter Support for EAP Re-authentication >> Protocol' as >> DIME working group item >> Done - Submit 'Diameter User-Name and Realm Based Request = Routing >> Clarifications' as DIME working group item >> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group >> item >> Done - Submit 'Quality of Service Attributes for Diameter' to = the >> IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >> consideration >> as a Proposed Standard >> Done - Submit 'Diameter User-Name and Realm Based Request = Routing >> Clarifications' to the IESG for consideration as a = Proposed >> Standard >> Done - Submit 'Updated IANA Considerations for Diameter Command >> Code >> Allocations' as DIME working group item >> Done - Submit 'Updated IANA Considerations for Diameter Command >> Code >> Allocations' to the IESG for consideration as a Proposed >> Standard >> Done - Submit 'Diameter NAT Control Application' as DIME working >> group >> item >> Done - Submit 'Diameter Capabilities Update' as DIME working = group >> item >> Done - Submit 'Diameter Credit Control Application MIB' to the >> IESG for >> consideration as an Informational RFC >> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >> consideration >> as an Informational RFC >> Done - Submit 'Diameter Capabilities Update' to the IESG for >> consideration >> as a Proposed Standard >>=20 >> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >> Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME >> working >> group item >> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >> Key >> Transport' as DIME working group item >> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >> Routing' >> as DIME working group item >> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >> working group >> item >> Done - Submit 'Diameter Extended NAPTR' as DIME working group = item >>=20 >> Aug 2010 - Submit Revision of 'Diameter Network Access Server >> Application - >> RFC 4005bis' as DIME working group item >> Aug 2010 - Submit Revision of 'Diameter Base Protocol' to the IESG = for >> consideration as a Proposed Standard >> Aug 2010 - Submit 'Diameter Priority Attribute Value Pairs' to the >> IESG for >> consideration as a Proposed Standard >> Aug 2010 - Submit 'Diameter Attribute-Value Pairs for Cryptographic >> Key >> Transport' to the IESG for consideration as a Proposed >> Standard >> Sep 2010 - Submit 'Diameter Application Design Guidelines' to the = IESG >> for >> consideration as a BCP document >> Sep 2010 - Submit 'Diameter NAT Control Application' to the IESG for >> consideration as a Proposed Standard >> Sep 2010 - Submit 'Diameter IKEv2 PSK' to the IESG for consideration >> as a >> Proposed Standard >> Sep 2010 - Submit 'Realm-Based Redirection In Diameter' to the IESG >> for >> consideration as a Proposed Standard >> Oct 2010 - Submit 'Diameter Extended NAPTR' to the IESG for >> consideration as a >> Proposed Standard >> Nov 2010 - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >> Routing' >> to the IESG for consideration as a Proposed Standard >> Nov 2010 - Submit 'Diameter Support for EAP Re-authentication >> Protocol' to the >> IESG for consideration as a Proposed Standard >> Jan 2011 - Submit new DIME charter to the IESG >> Nov 2011 - Submit Revision of 'Diameter Network Access Server >> Application - >> RFC 4005bis' to the IESG for consideration as a Proposed >> Standard >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 From sdecugis@nict.go.jp Thu Aug 5 18:30:59 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276333A68B0 for ; Thu, 5 Aug 2010 18:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-71nOxIFwZr for ; Thu, 5 Aug 2010 18:30:57 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 0F7BB3A679C for ; Thu, 5 Aug 2010 18:30:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 5C88027DCE; Fri, 6 Aug 2010 03:31:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt0kf2XqAfFo; Fri, 6 Aug 2010 03:31:21 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 9DD1E27D86; Fri, 6 Aug 2010 03:31:20 +0200 (CEST) Message-ID: <4C5B65DB.3040006@nict.go.jp> Date: Fri, 06 Aug 2010 10:31:07 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Glen Zorn References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> In-Reply-To: <003201cb347a$0fb844a0$2f28cde0$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 01:30:59 -0000 Hello, > Exactly. Since it is manifestly impossible to perform the reverse > translation (from Diameter to RADIUS) it seems rather pointless. I tend to disagree. If the attributes your AAA server is sending to the AAA client can be conveyed in RADIUS (a requirement for the tunneling mechanism) then they can also be translated from Diameter to RADIUS. I see absolutly no situation where the tunneling mechanism would perform better than the translation mechanism, from a functional point of view. Would you care putting some light on this for me? > The problem is that apparently nobody has _ever_ transitioned from RADIUS to > Diameter and it appears as if nobody ever will. I am not so pessimistic about Diameter :) > Regarding EDUROAM, Diameter > existed long before EDUROAM but they chose to hack RADIUS in their own way. > In any case, if they decided to migrate to Diameter they could use the > pointless tunneling protocol, retiring their RADIUS server when the > transition was complete. You are implying that each domain can retire its RADIUS server only when *all* the domains have moved all their clients to Diameter... This reasoning may be possible in a single-domain context, but it does not hold in a multi-domain roaming consortium case. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Thu Aug 5 18:47:11 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34213A66B4 for ; Thu, 5 Aug 2010 18:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBiseB8Eu4wI for ; Thu, 5 Aug 2010 18:47:09 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 01CA03A6835 for ; Thu, 5 Aug 2010 18:47:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 2D3E327DCE; Fri, 6 Aug 2010 03:47:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94y+qthrPIUf; Fri, 6 Aug 2010 03:47:35 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id CFBE027D86; Fri, 6 Aug 2010 03:47:34 +0200 (CEST) Message-ID: <4C5B69A9.601@nict.go.jp> Date: Fri, 06 Aug 2010 10:47:21 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 01:47:11 -0000 Hello Dan, >> First of all, not being useful is a good enough rationale to >> revise a RFC? > Let me try to argue that yes, it is. It is good to know for the general case. > A section in a Proposed Standard > that is not useful may lead to (at least) two counter-productive > effects: > - efforts are being made for implementation that result in useless code > with the risk of bugs and wasting resources That would be the case if that section was claimed as "mandatory to implement". It is not the case in RFC4005. So, people will implement it only when they plan to actually use it. > - the function that is described by the 'not useful' section seems to > apparently solve what may be a real problem, discouraging search other > ways of solving the problem (as 'there already is a standard way') I personnally believe that the solution presented in RFC4005 is as good as it can be, and there will be no better solution for solving this particular problem. Hence, I would rather keep this text around, until a new draft comes to present a better solution and update the RFC4005 at that time. It was the intent of my initial comment. > I will let the RADIUS and Diameter experts decide whether the > translation mechanism between RADIUS and Diameter as described in > Section 9 of RFC 4005 belongs here. Since this section describes how to translate RADIUS to Diameter NASREQ application (and not the general translation case), I think it makes sense to have this inside this document. But I have no objection should the group decide to reorganize the set of documents to group all RADIUS/Diameter translation sections from all documents into one big guideline. It is a large work. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Thu Aug 5 18:52:25 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE7F3A6956 for ; Thu, 5 Aug 2010 18:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kae8QRTDq5pr for ; Thu, 5 Aug 2010 18:52:24 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 3C4723A684A for ; Thu, 5 Aug 2010 18:52:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id E2C9A27DCE for ; Fri, 6 Aug 2010 03:52:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G094brD87SO for ; Fri, 6 Aug 2010 03:52:51 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id C813927D86 for ; Fri, 6 Aug 2010 03:52:50 +0200 (CEST) Message-ID: <4C5B6AE5.9030604@nict.go.jp> Date: Fri, 06 Aug 2010 10:52:37 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <00bc01cb34c4$c4a5ddb0$4df19910$@net> <425BF499-96F0-41EB-BE0E-65AAADA9F3C6@gmail.com> In-Reply-To: <425BF499-96F0-41EB-BE0E-65AAADA9F3C6@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] New milestones proporal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 01:52:25 -0000 I also agree Diameter ERP will take time :) It has a dependency on: Nov 2011 - Submit the Hokey architecture draft to IESG (from the HOKEY milestones) Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Thu Aug 5 21:44:43 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD4C3A680E for ; Thu, 5 Aug 2010 21:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxUU7hIZAwdP for ; Thu, 5 Aug 2010 21:44:42 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 3A8663A6358 for ; Thu, 5 Aug 2010 21:44:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id A329827DD0 for ; Fri, 6 Aug 2010 06:45:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu0FuGx8ZE32 for ; Fri, 6 Aug 2010 06:45:08 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 6116A27DCC for ; Fri, 6 Aug 2010 06:45:07 +0200 (CEST) Message-ID: <4C5B9345.7030104@nict.go.jp> Date: Fri, 06 Aug 2010 13:44:53 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] comments on draft-ietf-dime-realm-based-redirect-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 04:44:43 -0000 Hello, Bellow are my comments on this document. I believe there are a few points that would deserve to be clarified in the document, but nothing blocking the next steps. 1) (3.1.1) second list item (editorial): Furthermore, the redirect agent MUST a Redirect-Realm AVP ^^^ missing word? 2) (3.1.1) What if the the other peer advertised the Relay application? Should the redirect agent consider that it supports the Redirect-Realm application? 3) (3.1.1) "the message MUST include the Error- Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP," IIUC this is an impossible situation, since the Redirect Agent did not forward the Request. I believe this text could be removed for clarity. 4) (3.1.2) What if the original request contains a Destination-Host AVP? In that case, should a UNABLE_TO_DELIVER error be returned? There is probably no point in sending to the alternate realm with a Destination-Host in the previous realm, right? Unless maybe if the Destination-Realm of the request message does not match the Origin-Realm of the Redirect indication (change of broker for example). Any opinion? 5) (3.2) This section does not give the value of the M flag for the new AVP. By the semantics of the application, I believe the M flag should be set, right? That's all I have. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From lionel.morand@orange-ftgroup.com Fri Aug 6 01:51:39 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEB03A68F3 for ; Fri, 6 Aug 2010 01:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTwPbqWMbYVr for ; Fri, 6 Aug 2010 01:51:38 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id DF5443A689D for ; Fri, 6 Aug 2010 01:51:37 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CCD428B8004; Fri, 6 Aug 2010 10:52:06 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 22DC28B801E; Fri, 6 Aug 2010 10:48:47 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Aug 2010 10:43:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Aug 2010 10:43:17 +0200 Message-ID: In-Reply-To: <4C5B65DB.3040006@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 Thread-Index: Acs1BxtKa/O1Tx9LRkGXrWUZ6MFTKwANnteg References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net><4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> From: To: , X-OriginalArrivalTime: 06 Aug 2010 08:43:19.0381 (UTC) FILETIME=[6B8F1050:01CB3543] Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 08:51:39 -0000 [chair-hat out]=20 Hi Sebastien, See below. =20 Lionel > Hello, >=20 > > Exactly. Since it is manifestly impossible to perform the reverse=20 > > translation (from Diameter to RADIUS) it seems rather pointless. > I tend to disagree. If the attributes your AAA server is=20 > sending to the AAA client can be conveyed in RADIUS (a=20 > requirement for the tunneling > mechanism) then they can also be translated from Diameter to=20 > RADIUS. I see absolutly no situation where the tunneling=20 > mechanism would perform better than the translation=20 > mechanism, from a functional point of view. > Would you care putting some light on this for me? I think that the idea is not to say that RADIUS/Diameter interworking is not possible at all. The idea is more about to acknowledge the fact that RFC 4005 can not remain the de-facto and the only reference for RADIUS/Diameter translation as this section is under specified and not applicable anyway to all RADIUS/Diameter interworking scenarios. As something has to be done, it is proposed to remove anything about RADIUS/Diameter translation from RFC 4005. The NASREQ application is self-consistent without this part. If any interworking solution between RADIUS and NASREQ needs to be standardized (some people have doubts about it), it would have to be documented in a separate document. After, any new application that would require interworking with RADIUS will have to describe how to do it in its own documentation.=20 >=20 > > The problem is that apparently nobody has _ever_ transitioned from=20 > > RADIUS to Diameter and it appears as if nobody ever will. > I am not so pessimistic about Diameter :) >=20 > > Regarding EDUROAM, Diameter > > existed long before EDUROAM but they chose to hack RADIUS=20 > in their own way. > > In any case, if they decided to migrate to Diameter they=20 > could use the=20 > > pointless tunneling protocol, retiring their RADIUS server when the=20 > > transition was complete. > You are implying that each domain can retire its RADIUS=20 > server only when > *all* the domains have moved all their clients to Diameter...=20 > This reasoning may be possible in a single-domain context,=20 > but it does not hold in a multi-domain roaming consortium case. About roaming issues, I think that we should make the difference between inter-domain and intra-domain. If there exists a solution for RADIUS/Diameter interworking, each domain could rely on either RADIUS or Diameter, and the interworking solution would be applied *only* between AAA servers/proxies. In intra-domain, if a single AAA server can support both RADIUS and Diameter clients, the migration path is quite simple, no? =20 >=20 > Best regards, > Sebastien. >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From sdecugis@nict.go.jp Fri Aug 6 02:12:39 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EAD3A689D for ; Fri, 6 Aug 2010 02:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RCjW4DQKwpC for ; Fri, 6 Aug 2010 02:12:38 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id B970E3A68CF for ; Fri, 6 Aug 2010 02:12:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id C59B427DD0; Fri, 6 Aug 2010 11:13:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQW-VE8f50E8; Fri, 6 Aug 2010 11:13:05 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id D549527DCC; Fri, 6 Aug 2010 11:13:03 +0200 (CEST) Message-ID: <4C5BD20E.9080802@nict.go.jp> Date: Fri, 06 Aug 2010 18:12:46 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net><4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 09:12:39 -0000 Hi Lionel, Thank you for answering my comments. Please see bellow. > About roaming issues, I think that we should make the difference between > inter-domain and intra-domain. If there exists a solution for > RADIUS/Diameter interworking, each domain could rely on either RADIUS or > Diameter, and the interworking solution would be applied *only* between > AAA servers/proxies. In intra-domain, if a single AAA server can support > both RADIUS and Diameter clients, the migration path is quite simple, > no? Yes, my concern was about interconnecting different domains together, when some of the domains want to move to Diameter. In this situation, a translation mechanism is mandatory, I think. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Fri Aug 6 03:43:19 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651933A68B1 for ; Fri, 6 Aug 2010 03:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A48f9WE3FCc for ; Fri, 6 Aug 2010 03:43:18 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 2E4CA3A68FC for ; Fri, 6 Aug 2010 03:43:17 -0700 (PDT) Received: (qmail 15213 invoked from network); 6 Aug 2010 10:43:47 -0000 Received: from unknown (195.46.229.98) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 06 Aug 2010 10:43:47 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> In-Reply-To: <4C5B65DB.3040006@nict.go.jp> Date: Fri, 6 Aug 2010 12:43:40 +0200 Organization: Network Zen Message-ID: <003401cb3554$3ce0c6c0$b6a25440$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs1BxX6R8m4TT/hTrO+x0tnHe+glQASTMTw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 10:43:19 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hello, > > > Exactly. Since it is manifestly impossible to perform the reverse > > translation (from Diameter to RADIUS) it seems rather pointless. > I tend to disagree. If the attributes your AAA server is sending to the > AAA client can be conveyed in RADIUS (a requirement for the tunneling > mechanism) then they can also be translated from Diameter to RADIUS. Precisely the problem: the necessity to provide for RADIUS compatibility unnecessarily constrains the content of the Diameter AVPs. In fact, NASREQ is not so much a Diameter application as RADIUS in a Diameter wrapper. > I > see absolutly no situation where the tunneling mechanism would perform > better than the translation mechanism, from a functional point of view. > Would you care putting some light on this for me? Removing the need to artificially limit the length of the NASREQ AVP payloads to 253 (or even 4073) octets would make NASREQ into a _real_ Diameter application. > > > The problem is that apparently nobody has _ever_ transitioned from > RADIUS to > > Diameter and it appears as if nobody ever will. > I am not so pessimistic about Diameter :) I'm not pessimistic, just realistic: virtually the only Diameter deployments of any consequence of which I'm aware have been green-field. Rumors come from WiMAX about migration from RADIUS to Diameter but I'll believe that when I see it ;-). > > > Regarding EDUROAM, Diameter > > existed long before EDUROAM but they chose to hack RADIUS in their own > way. > > In any case, if they decided to migrate to Diameter they could use the > > pointless tunneling protocol, retiring their RADIUS server when the > > transition was complete. > You are implying that each domain can retire its RADIUS server only when > *all* the domains have moved all their clients to Diameter... This > reasoning may be possible in a single-domain context, but it does not > hold in a multi-domain roaming consortium case. Care to give some sort of rationale for this statement? > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From gwz@net-zen.net Fri Aug 6 05:23:18 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7003A68C1 for ; Fri, 6 Aug 2010 05:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.416 X-Spam-Level: X-Spam-Status: No, score=-101.416 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_00=-2.599, FRT_BELOW2=2.154, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73xdGeVI4uXi for ; Fri, 6 Aug 2010 05:23:17 -0700 (PDT) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id 426993A635F for ; Fri, 6 Aug 2010 05:23:17 -0700 (PDT) Received: (qmail 16521 invoked from network); 6 Aug 2010 12:23:47 -0000 Received: from unknown (195.46.229.98) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 06 Aug 2010 12:23:47 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" , References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net><4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> <4C5BD20E.9080802@nict.go.jp> In-Reply-To: <4C5BD20E.9080802@nict.go.jp> Date: Fri, 6 Aug 2010 14:23:39 +0200 Organization: Network Zen Message-ID: <004a01cb3562$34d91460$9e8b3d20$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs1R6Un3E0y8NpIQdin8tGJcjSZ+wAGnjqw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 12:23:19 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hi Lionel, > > Thank you for answering my comments. Please see bellow. > > > About roaming issues, I think that we should make the difference > between > > inter-domain and intra-domain. If there exists a solution for > > RADIUS/Diameter interworking, each domain could rely on either RADIUS > or > > Diameter, and the interworking solution would be applied *only* > between > > AAA servers/proxies. In intra-domain, if a single AAA server can > support > > both RADIUS and Diameter clients, the migration path is quite simple, > > no? > Yes, my concern was about interconnecting different domains together, > when some of the domains want to move to Diameter. In this situation, a > translation mechanism is mandatory, I think. Justification, please? > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From dlehmann@ulticom.com Fri Aug 6 06:02:55 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53E23A6A1B for ; Fri, 6 Aug 2010 06:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A3iyulr0z0F for ; Fri, 6 Aug 2010 06:02:48 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 0DB913A6833 for ; Fri, 6 Aug 2010 06:02:47 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 87EEA24D0DE22286; Fri, 6 Aug 2010 09:03:18 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o76D33NA028917; Fri, 6 Aug 2010 09:03:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3567.B46C511E" Date: Fri, 6 Aug 2010 08:59:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0zBKtj01JbAzPTTWbFAKGVj8KXAAmkG3g References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 13:02:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3567.B46C511E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The agent is just forwarding messages and it would like to be application agnostic. The Private-Info AVP would aid in this effort, while allowing it to be stateless. =20 =20 As already noted by others, applications have defined messages which survive all subsequent legs of the session. The Private-Info is defining an AVP for similar purpose, but is intended for agents. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 2:29 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP =20 your agent is a proxy which means its doing more than just forwarding messages. by definition, if your a proxy you have an application running in this agent that does special handling with these messages prior to forwarding ... hence we keep going back to the term 'application'. =20 On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann wrote: Forget the applications using this AVP. Think about agents. It is opaque to the applications... just like the Proxy-Info. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 2:07 PM=20 To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP =20 =20 On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann wrote: The proposal is primarily for agents, not applications. (Although, I have no problem with applications employing the new AVP.) Agents can introduce the Private-Info into the messages to allow it to remain stateless without having knowledge of specific applications. =20 =20 Besides, you don't want an agent using an AVP which was intended be used for applications just because the AVP has the property of surviving on all legs of a session. An agent should introduce its own data in an AVP which is opaque to other nodes. It is cleaner, IMHO. =20 =20 But the content(s) and semantcis of the Private-Info is known only to the application :) ... so I'm not convinced if its really cleaner :) =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 12:19 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org=20 =09 Subject: Re: [Dime] Private-Info AVP =20 Ok. Then rolling back to the same line of questioning ... why do you want to generalize this ? Other applications commonly define their own AVP's to accomodate round-trip information such as this.=20 =09 regards, victor =09 =20 On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann wrote: > Unless I'm missing something, Proxy-Info can be included in an stateful application which > can control it's lifetime .... so I'm still not sure why we need a new AVP that means > the same thing. How does one control the lifetime of the Proxy-Info? The RFC currently states, "If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded." =09 Look at the original diagram. The Proxy-Info (PI) was added to R1 by the Agent, but the Agent "MUST" remove the Proxy Info before forwarding the answer to the client. =09 Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| The proposed Private-Info AVP would be the same as the Proxy-Info, except that it lasts for the whole session (or until the owner removes it). Again the diagram with PI being the Private-Info. =09 Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| So the Private-Info is different from the Proxy-Info, but only in regards to lifetime. =09 -David =20 =20 =20 ------_=_NextPart_001_01CB3567.B46C511E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The agent is just forwarding messages and it would like = to be application agnostic.   The Private-Info AVP would aid in this = effort, while allowing it to be stateless.  

 

As already noted by others, applications have defined = messages which survive all subsequent legs of the session.  The Private-Info = is defining an AVP for similar purpose, but is intended for = agents.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 2:29 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject: Re: [Dime] Private-Info AVP

 

your agent is a proxy which means its doing more = than just forwarding messages. by definition, if your a proxy you have an application running in this agent that does special handling with these messages prior to forwarding ... hence we keep going back to the term 'application'.



 

On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann = <dlehmann@ulticom.com> = wrote:

Forget the applications using = this AVP.  Think about agents.  It is opaque to the = applications… just like the Proxy-Info.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 2:07 PM


To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject: Re: [Dime] Private-Info AVP

 <= /o:p>


 

On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann <dlehmann@ulticom.com> wrote:

The proposal is primarily =  for agents, not applications. (Although, I have no problem with applications employing = the new AVP.)  Agents can introduce the Private-Info into the messages to = allow it to remain stateless without having knowledge of specific applications.    

 

Besides, you don’t want = an agent using an AVP which was intended be used for applications just because = the AVP has the property of surviving on all legs of a session.  An agent = should introduce its own data in an AVP which is opaque to other nodes.  = It is cleaner, IMHO.

 <= /o:p>

 <= /o:p>

But the content(s) and semantcis of the Private-Info is known only to = the application :) ... so I'm not convinced if its really cleaner = :)

 <= /o:p>

regards,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

=

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 12:19 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org


Subject: Re: [Dime] Private-Info AVP

 <= /o:p>

Ok. Then rolling back to the same line of questioning ... why do = you want to generalize this ? Other applications commonly define their own AVP's = to accomodate round-trip information such as this.


regards,

victor<= /o:p>


 

On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann <dlehmann@ulticom.com> wrote:

> Unless I'm missing something, Proxy-Info can be included in an
stateful application which
> can control it's lifetime .... so I'm still not sure why we need a = new
AVP that means
> the same thing.

How does one control the lifetime of the Proxy-Info? The RFC currently
states,
  "If the last Proxy-Info AVP in the message is targeted to = the local
  Diameter server, the AVP MUST be removed before the answer is
forwarded."

Look at the original diagram. The Proxy-Info (PI) was added to R1 by = the
Agent, but the Agent "MUST" remove the Proxy Info before = forwarding the
answer to the client.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1         =     |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2         =     |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2         =     |         A2+PI         = |
 |<------------------------|<----------------------|

The proposed Private-Info AVP would be the same as the Proxy-Info,
except that it lasts for the whole session (or until the owner = removes
it).  Again the diagram with PI being the = Private-Info.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1+PI       =    |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2+PI       =    |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2+PI       =    |         A2+PI         = |
 |<------------------------|<----------------------|

So the Private-Info is different from the Proxy-Info, but only in
regards to lifetime.

-David

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CB3567.B46C511E-- From gwz@net-zen.net Fri Aug 6 07:18:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68833A6A9E for ; Fri, 6 Aug 2010 07:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQXOaBLPt-xT for ; Fri, 6 Aug 2010 07:18:34 -0700 (PDT) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by core3.amsl.com (Postfix) with SMTP id 774853A67F9 for ; Fri, 6 Aug 2010 07:18:34 -0700 (PDT) Received: (qmail 14745 invoked from network); 6 Aug 2010 14:19:03 -0000 Received: from unknown (195.46.229.98) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 06 Aug 2010 14:19:02 -0000 From: "Glen Zorn" To: "'David Lehmann'" , "'Victor Fajardo'" References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> In-Reply-To: Date: Fri, 6 Aug 2010 16:18:54 +0200 Organization: Network Zen Message-ID: <007d01cb3572$4e48d150$eada73f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01CB3583.11D1A150" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs0zBKtj01JbAzPTTWbFAKGVj8KXAAmkG3gAAKTH2A= Content-Language: en-us Cc: 'Daily William' , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 14:18:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_007E_01CB3583.11D1A150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Lehmann [mailto://dlehmann@ulticom.com] writes: The agent is just forwarding messages and it would like to be application agnostic. The Private-Info AVP would aid in this effort, while allowing it to be stateless. As already noted by others, applications have defined messages which survive all subsequent legs of the session. The Private-Info is defining an AVP for similar purpose, but is intended for agents. It would help me, at least, if you said what type of agent you're talking about since there are 4. -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Thursday, August 05, 2010 2:29 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP your agent is a proxy which means its doing more than just forwarding messages. by definition, if your a proxy you have an application running in this agent that does special handling with these messages prior to forwarding ... hence we keep going back to the term 'application'. On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann wrote: Forget the applications using this AVP. Think about agents. It is opaque to the applications. just like the Proxy-Info. -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Thursday, August 05, 2010 2:07 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann wrote: The proposal is primarily for agents, not applications. (Although, I have no problem with applications employing the new AVP.) Agents can introduce the Private-Info into the messages to allow it to remain stateless without having knowledge of specific applications. Besides, you don't want an agent using an AVP which was intended be used for applications just because the AVP has the property of surviving on all legs of a session. An agent should introduce its own data in an AVP which is opaque to other nodes. It is cleaner, IMHO. But the content(s) and semantcis of the Private-Info is known only to the application :) ... so I'm not convinced if its really cleaner :) regards, victor -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Thursday, August 05, 2010 12:19 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP Ok. Then rolling back to the same line of questioning ... why do you want to generalize this ? Other applications commonly define their own AVP's to accomodate round-trip information such as this. regards, victor On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann wrote: > Unless I'm missing something, Proxy-Info can be included in an stateful application which > can control it's lifetime .... so I'm still not sure why we need a new AVP that means > the same thing. How does one control the lifetime of the Proxy-Info? The RFC currently states, "If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded." Look at the original diagram. The Proxy-Info (PI) was added to R1 by the Agent, but the Agent "MUST" remove the Proxy Info before forwarding the answer to the client. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| The proposed Private-Info AVP would be the same as the Proxy-Info, except that it lasts for the whole session (or until the owner removes it). Again the diagram with PI being the Private-Info. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| So the Private-Info is different from the Proxy-Info, but only in regards to lifetime. -David ------=_NextPart_000_007E_01CB3583.11D1A150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David Lehmann [mailto://dlehmann@ulti= com.com] writes:

 

The agent is just forwarding messages and it would like = to be application agnostic.   The Private-Info AVP would aid in this effort, while allowing it to be stateless.   =

 

As already noted by others, applications have defined = messages which survive all subsequent legs of the session.  The Private-Info is = defining an AVP for similar purpose, but is intended for = agents.

It would help me, at least, if you said what type of = agent you’re talking about since there are 4…

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 2:29 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject: Re: [Dime] Private-Info AVP

 

your agent is a proxy which means its doing more = than just forwarding messages. by definition, if your a proxy you have an application running in this agent that does special handling with these messages prior to forwarding ... hence we keep going back to the term 'application'.



 

On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann = <dlehmann@ulticom.com> = wrote:

Forget the applications using = this AVP.  Think about agents.  It is opaque to the = applications… just like the Proxy-Info.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 2:07 PM


To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject: Re: [Dime] Private-Info AVP

 <= /o:p>


 

On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann <dlehmann@ulticom.com> wrote:

The proposal is primarily =  for agents, not applications. (Although, I have no problem with applications employing = the new AVP.)  Agents can introduce the Private-Info into the messages to = allow it to remain stateless without having knowledge of specific applications.    

 

Besides, you don’t want = an agent using an AVP which was intended be used for applications just because = the AVP has the property of surviving on all legs of a session.  An agent = should introduce its own data in an AVP which is opaque to other nodes.  = It is cleaner, IMHO.

 <= /o:p>

 <= /o:p>

But the content(s) and semantcis of the Private-Info is known only to = the application :) ... so I'm not convinced if its really cleaner :)

 <= /o:p>

regards,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

=

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 12:19 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org


Subject: Re: [Dime] Private-Info AVP

 <= /o:p>

Ok. Then rolling back to the same line of questioning ... why do = you want to generalize this ? Other applications commonly define their own AVP's = to accomodate round-trip information such as this.


regards,

victor<= /o:p>


 

On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann <dlehmann@ulticom.com> wrote:

> Unless I'm missing something, Proxy-Info can be included in an
stateful application which
> can control it's lifetime .... so I'm still not sure why we need a = new
AVP that means
> the same thing.

How does one control the lifetime of the Proxy-Info? The RFC currently
states,
  "If the last Proxy-Info AVP in the message is targeted to = the local
  Diameter server, the AVP MUST be removed before the answer is
forwarded."

Look at the original diagram. The Proxy-Info (PI) was added to R1 by = the
Agent, but the Agent "MUST" remove the Proxy Info before = forwarding the
answer to the client.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1         =     |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2         =     |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2         =     |         A2+PI         = |
 |<------------------------|<----------------------|

The proposed Private-Info AVP would be the same as the Proxy-Info,
except that it lasts for the whole session (or until the owner = removes
it).  Again the diagram with PI being the = Private-Info.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1+PI       =    |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2+PI       =    |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2+PI       =    |         A2+PI         = |
 |<------------------------|<----------------------|

So the Private-Info is different from the Proxy-Info, but only in
regards to lifetime.

-David

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_007E_01CB3583.11D1A150-- From lionel.morand@orange-ftgroup.com Fri Aug 6 07:42:11 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4270A3A6A94 for ; Fri, 6 Aug 2010 07:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.898 X-Spam-Level: X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWNKIBLKUaFI for ; Fri, 6 Aug 2010 07:42:09 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 020913A6AC1 for ; Fri, 6 Aug 2010 07:42:09 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 341D78B803F; Fri, 6 Aug 2010 16:43:09 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 25C818B8031; Fri, 6 Aug 2010 16:43:09 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Aug 2010 16:42:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3575.9A8FB581" Date: Fri, 6 Aug 2010 16:42:32 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0zBKtj01JbAzPTTWbFAKGVj8KXAAmkG3gAAOtH/A= References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> From: To: , X-OriginalArrivalTime: 06 Aug 2010 14:42:33.0777 (UTC) FILETIME=[9AFAE210:01CB3575] Cc: Bill.Daily@comverse.com, dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 14:42:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3575.9A8FB581 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, =20 As said, I don't see what should be the usefulness of this functionality = for Relay and Redirect agents. Proxies are used at the application level = and can then rely on application-specific AVPs. =20 So what is the specific type of forwarding agents that would need such = generic AVP? =20 Regards, =20 Lionel ________________________________ De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de = David Lehmann Envoy=E9 : vendredi 6 ao=FBt 2010 14:59 =C0 : Victor Fajardo Cc : Daily William; dime@ietf.org Objet : Re: [Dime] Private-Info AVP =09 =09 The agent is just forwarding messages and it would like to be = application agnostic. The Private-Info AVP would aid in this effort, = while allowing it to be stateless. =20 =20 As already noted by others, applications have defined messages which = survive all subsequent legs of the session. The Private-Info is = defining an AVP for similar purpose, but is intended for agents. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 2:29 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP =20 your agent is a proxy which means its doing more than just forwarding = messages. by definition, if your a proxy you have an application running = in this agent that does special handling with these messages prior to = forwarding ... hence we keep going back to the term 'application'. =09 =09 =20 On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann = wrote: Forget the applications using this AVP. Think about agents. It is = opaque to the applications... just like the Proxy-Info. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 2:07 PM=20 =09 To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP =20 =09 =20 On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann = wrote: The proposal is primarily for agents, not applications. (Although, I = have no problem with applications employing the new AVP.) Agents can = introduce the Private-Info into the messages to allow it to remain = stateless without having knowledge of specific applications. =20 =20 Besides, you don't want an agent using an AVP which was intended be = used for applications just because the AVP has the property of surviving = on all legs of a session. An agent should introduce its own data in an = AVP which is opaque to other nodes. It is cleaner, IMHO. =20 =20 But the content(s) and semantcis of the Private-Info is known only to = the application :) ... so I'm not convinced if its really cleaner :) =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 12:19 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org=20 =09 Subject: Re: [Dime] Private-Info AVP =20 Ok. Then rolling back to the same line of questioning ... why do you = want to generalize this ? Other applications commonly define their own = AVP's to accomodate round-trip information such as this.=20 =09 regards, victor =09 =20 On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann = wrote: > Unless I'm missing something, Proxy-Info can be included in an stateful application which > can control it's lifetime .... so I'm still not sure why we need a = new AVP that means > the same thing. How does one control the lifetime of the Proxy-Info? The RFC currently states, "If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded." =09 Look at the original diagram. The Proxy-Info (PI) was added to R1 by = the Agent, but the Agent "MUST" remove the Proxy Info before forwarding = the answer to the client. =09 Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| The proposed Private-Info AVP would be the same as the Proxy-Info, except that it lasts for the whole session (or until the owner removes it). Again the diagram with PI being the Private-Info. =09 Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| So the Private-Info is different from the Proxy-Info, but only in regards to lifetime. =09 -David =20 =20 =20 ------_=_NextPart_001_01CB3575.9A8FB581 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi David,
 
As said, I don't see what should be the = usefulness of this=20 functionality for Relay and Redirect agents. Proxies are used at the = application=20 level and can then rely on application-specific = AVPs.
 
So what is the specific type of forwarding = agents that=20 would need such generic AVP?
 
Regards,
 
Lionel

De : dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] De la part de David=20 Lehmann
Envoy=E9 : vendredi 6 ao=FBt 2010 = 14:59
=C0 :=20 Victor Fajardo
Cc : Daily William;=20 dime@ietf.org
Objet : Re: [Dime] Private-Info=20 AVP

The=20 agent is just forwarding messages and it would like to be application=20 agnostic.   The Private-Info AVP would aid in this effort, = while=20 allowing it to be stateless.  

 

As=20 already noted by others, applications have defined messages which = survive all=20 subsequent legs of the session.  The Private-Info is defining an = AVP for=20 similar purpose, but is intended for agents.

 

--

David=20 Lehmann

Ulticom,=20 Inc.

856-787-2952

 

From: Victor = Fajardo=20 [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 = 2:29=20 PM
To: David Lehmann
Cc: rajithr 70236; Daily = William;=20 dime@ietf.org
Subject: Re: [Dime] Private-Info=20 AVP

 

your agent is a proxy which means its doing more = than just=20 forwarding messages. by definition, if your a proxy you have an=20 application running in this agent that does special handling with = these=20 messages prior to forwarding ... hence we keep going back to the term=20 'application'.



 

On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann = <dlehmann@ulticom.com>=20 wrote:

Forget the applications = using this=20 AVP.  Think about agents.  It is opaque to the = applications=85 just=20 like the Proxy-Info.

 

--

David=20 Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor=20 Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, = August 05, 2010=20 2:07 PM


To: = David=20 Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject:=20 Re: [Dime] Private-Info = AVP

 


 

On = Thu, Aug 5,=20 2010 at 2:04 PM, David Lehmann <dlehmann@ulticom.com> wrote:

The proposal is primarily =  for=20 agents, not = applications. (Although, I have no problem with applications employing = the new=20 AVP.)  Agents can introduce the Private-Info into the messages to = allow=20 it to remain stateless without having knowledge of specific = applications.=20    

 

Besides, you don=92t want an = agent using=20 an AVP which was intended be used for applications just because the = AVP has=20 the property of surviving on all legs of a session.  An agent = should=20 introduce its own data in an AVP which is opaque to other nodes.  = It is=20 cleaner, IMHO.

 

 

But = the=20 content(s) and semantcis of the Private-Info is known only to the = application :) ... so I'm not convinced if its really cleaner=20 :)

 

regards,

victor

 

 

 

 

--

David=20 Lehmann

Ulticom, = Inc.

856-787-2952

 

From:=20 Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, = August 05,=20 2010 12:19 PM
To: David Lehmann
Cc: rajithr = 70236; Daily=20 William; dime@ietf.org=20


Subject: Re: [Dime] = Private-Info=20 AVP

 

Ok. = Then=20 rolling back to the same line of questioning ... why do = you want=20 to generalize this ? Other applications commonly define their own = AVP's to=20 accomodate round-trip information such as this. =


regards,

victor


 

On = Thu, Aug 5,=20 2010 at 11:14 AM, David Lehmann <dlehmann@ulticom.com> wrote:

> Unless = I'm=20 missing something, Proxy-Info can be included in an
stateful = application=20 which
> can control it's lifetime .... so I'm still not sure = why we=20 need a new
AVP that means
> the same = thing.

How=20 does one control the lifetime of the Proxy-Info? The RFC=20 currently
states,
  "If the last Proxy-Info AVP in the = message is=20 targeted to the local
  Diameter server, the AVP MUST be = removed=20 before the answer is
forwarded."

Look at the original = diagram. The=20 Proxy-Info (PI) was added to R1 by the
Agent, but the Agent = "MUST" remove=20 the Proxy Info before forwarding the
answer to the = client.


Client =  =20                  Agent =  =20                 =  A/S
 |=20          R1         =  =20   |         R1+PI       =  =20 = |
 |------------------------>|---------------------->|
&= nbsp;|=20                   =    =20   |                 =  =20     |
 |          A1 =  =20           |         = A1+PI=20        =20 = |
 |<------------------------|<----------------------|
&= nbsp;|=20                   =    =20   |                 =  =20     |
 |          R2 =  =20           |         = R2+PI=20        =20 = |
 |------------------------>|---------------------->|
&= nbsp;|=20                   =    =20   |                 =  =20     |
 |          A2 =  =20           |         = A2+PI=20        =20 = |
 |<------------------------|<----------------------|=

The = proposed=20 Private-Info AVP would be the same as the Proxy-Info,
except that = it=20 lasts for the whole session (or until the owner removes
it). =  Again=20 the diagram with PI being the Private-Info.


Client =  =20                  Agent =  =20                 =  A/S
 |=20          R1         =  =20   |         R1+PI       =  =20 = |
 |------------------------>|---------------------->|
&= nbsp;|=20                   =    =20   |                 =  =20     |
 |          A1+PI =  =20        |         A1+PI =    =20    =20 = |
 |<------------------------|<----------------------|
&= nbsp;|=20                   =    =20   |                 =  =20     |
 |          R2+PI =  =20        |         R2+PI =    =20    =20 = |
 |------------------------>|---------------------->|
&= nbsp;|=20                   =    =20   |                 =  =20     |
 |          A2+PI =  =20        |         A2+PI =    =20    =20 = |
 |<------------------------|<----------------------|=

So=20 the Private-Info is different from the Proxy-Info, but only = in
regards to=20 lifetime.

-David

 

 

 

------_=_NextPart_001_01CB3575.9A8FB581-- From dlehmann@ulticom.com Fri Aug 6 09:06:32 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009633A67F5 for ; Fri, 6 Aug 2010 09:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMi-lGEUDN6d for ; Fri, 6 Aug 2010 09:06:23 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id CAB5D3A679F for ; Fri, 6 Aug 2010 09:06:22 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id DA41B17D05E26522; Fri, 6 Aug 2010 12:06:52 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o76G6mxS025842; Fri, 6 Aug 2010 12:06:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3581.5F82C54C" Date: Fri, 6 Aug 2010 12:06:47 -0400 Message-ID: In-Reply-To: <007d01cb3572$4e48d150$eada73f0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs0zBKtj01JbAzPTTWbFAKGVj8KXAAmkG3gAAKTH2AAAx2/MA== References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> <007d01cb3572$4e48d150$eada73f0$@net> From: "David Lehmann" To: "Glen Zorn" , "Victor Fajardo" Received-SPF: none Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:06:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3581.5F82C54C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was using the general term "agent" because it doesn't matter which type it is, from the RFC's point of view. The Private-Info is just an extension of the Proxy-Info. For the same reason that the Proxy-Info exists, the Private-Info AVP has the same desired purpose: "It contains state information that would otherwise be stored at the Diameter entity that created it. As such, this AVP MUST be treated as opaque data by entities other Diameter entities." The RFC (section 6.1.9) states that the Proxy-Info can be use by a Proxy or Relay agent. So it really does matter which type of agent uses the AVP nor does it matter for which purpose. Who knows all of the clever ways an agent uses the Proxy-Info? The RFC does not provide the specific purposes of the Proxy-Info, and rightly so. Nor does the RFC need to spell out the purposes of the Private-Info AVP. It is simply a tool to aid agents. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Friday, August 06, 2010 10:19 AM To: David Lehmann; 'Victor Fajardo' Cc: 'Daily William'; dime@ietf.org Subject: RE: [Dime] Private-Info AVP =20 David Lehmann [mailto://dlehmann@ulticom.com] writes: =20 The agent is just forwarding messages and it would like to be application agnostic. The Private-Info AVP would aid in this effort, while allowing it to be stateless. =20 =20 As already noted by others, applications have defined messages which survive all subsequent legs of the session. The Private-Info is defining an AVP for similar purpose, but is intended for agents. It would help me, at least, if you said what type of agent you're talking about since there are 4... =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 2:29 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP =20 your agent is a proxy which means its doing more than just forwarding messages. by definition, if your a proxy you have an application running in this agent that does special handling with these messages prior to forwarding ... hence we keep going back to the term 'application'. =20 On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann wrote: Forget the applications using this AVP. Think about agents. It is opaque to the applications... just like the Proxy-Info. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 2:07 PM=20 To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP =20 =20 On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann wrote: The proposal is primarily for agents, not applications. (Although, I have no problem with applications employing the new AVP.) Agents can introduce the Private-Info into the messages to allow it to remain stateless without having knowledge of specific applications. =20 =20 Besides, you don't want an agent using an AVP which was intended be used for applications just because the AVP has the property of surviving on all legs of a session. An agent should introduce its own data in an AVP which is opaque to other nodes. It is cleaner, IMHO. =20 =20 But the content(s) and semantcis of the Private-Info is known only to the application :) ... so I'm not convinced if its really cleaner :) =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Thursday, August 05, 2010 12:19 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org=20 =09 Subject: Re: [Dime] Private-Info AVP =20 Ok. Then rolling back to the same line of questioning ... why do you want to generalize this ? Other applications commonly define their own AVP's to accomodate round-trip information such as this.=20 =09 regards, victor =09 =20 On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann wrote: > Unless I'm missing something, Proxy-Info can be included in an stateful application which > can control it's lifetime .... so I'm still not sure why we need a new AVP that means > the same thing. How does one control the lifetime of the Proxy-Info? The RFC currently states, "If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded." =09 Look at the original diagram. The Proxy-Info (PI) was added to R1 by the Agent, but the Agent "MUST" remove the Proxy Info before forwarding the answer to the client. =09 Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| The proposed Private-Info AVP would be the same as the Proxy-Info, except that it lasts for the whole session (or until the owner removes it). Again the diagram with PI being the Private-Info. =09 Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| So the Private-Info is different from the Proxy-Info, but only in regards to lifetime. =09 -David =20 =20 =20 ------_=_NextPart_001_01CB3581.5F82C54C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I was using the general term “agent” because =
it doesn’t matter which type it is, from the RFC’s point of =
view.  The Private-Info is just an extension of the =
Proxy-Info.  For the same reason that the Proxy-Info exists, the =
Private-Info AVP has the same desired purpose:  “=
It contains state information that would =
otherwise be stored at the Diameter entity that created it.  As =
such, this AVP MUST be treated as opaque data by entities other Diameter =
entities.”  The RFC (section 6.1.9) states that the Proxy-Info can be use by a =
Proxy or Relay agent.  So it really does matter which type of agent =
uses the AVP nor does it matter for which purpose.  Who knows all =
of the clever ways an agent uses the Proxy-Info?  The RFC does not =
provide the specific purposes of the Proxy-Info, and rightly so. =
 Nor does the RFC need to spell out the purposes of the =
Private-Info AVP.   It is simply a tool to aid =
agents.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Glen Zorn [mailto:gwz@net-zen.net]
Sent: Friday, August 06, 2010 10:19 AM
To: David Lehmann; 'Victor Fajardo'
Cc: 'Daily William'; dime@ietf.org
Subject: RE: [Dime] Private-Info AVP

 

David Lehmann [mailto://dlehmann@ulti= com.com] writes:

 

The agent is just forwarding messages and it would like = to be application agnostic.   The Private-Info AVP would aid in this effort, while allowing it to be stateless.   =

 

As already noted by others, applications have defined = messages which survive all subsequent legs of the session.  The Private-Info = is defining an AVP for similar purpose, but is intended for = agents.

It would help me, at least, if you said what type of = agent you’re talking about since there are = 4…

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 2:29 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject: Re: [Dime] Private-Info AVP

 

your agent is a proxy which means its doing more = than just forwarding messages. by definition, if your a proxy you have an application running in this agent that does special handling with these messages prior to forwarding ... hence we keep going back to the term 'application'.



 

On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann = <dlehmann@ulticom.com> = wrote:

Forget the applications using = this AVP.  Think about agents.  It is opaque to the = applications… just like the Proxy-Info.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 2:07 PM


To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org
Subject: Re: [Dime] Private-Info AVP

 <= /o:p>


 

On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann <dlehmann@ulticom.com> wrote:

The proposal is primarily =  for agents, not applications. (Although, I have no problem with applications employing = the new AVP.)  Agents can introduce the Private-Info into the messages to = allow it to remain stateless without having knowledge of specific applications.    

 

Besides, you don’t want = an agent using an AVP which was intended be used for applications just because = the AVP has the property of surviving on all legs of a session.  An agent = should introduce its own data in an AVP which is opaque to other nodes.  = It is cleaner, IMHO.

 <= /o:p>

 <= /o:p>

But the content(s) and semantcis of the Private-Info is known only to = the application :) ... so I'm not convinced if its really cleaner = :)

 <= /o:p>

regards,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

=

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Thursday, August 05, 2010 12:19 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; dime@ietf.org


Subject: Re: [Dime] Private-Info AVP

 <= /o:p>

Ok. Then rolling back to the same line of questioning ... why do = you want to generalize this ? Other applications commonly define their own AVP's = to accomodate round-trip information such as this.


regards,

victor<= /o:p>


 

On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann <dlehmann@ulticom.com> wrote:

> Unless I'm missing something, Proxy-Info can be included in an
stateful application which
> can control it's lifetime .... so I'm still not sure why we need a = new
AVP that means
> the same thing.

How does one control the lifetime of the Proxy-Info? The RFC currently
states,
  "If the last Proxy-Info AVP in the message is targeted to = the local
  Diameter server, the AVP MUST be removed before the answer is
forwarded."

Look at the original diagram. The Proxy-Info (PI) was added to R1 by = the
Agent, but the Agent "MUST" remove the Proxy Info before = forwarding the
answer to the client.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1         =     |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2         =     |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2         =     |         A2+PI         = |
 |<------------------------|<----------------------|

The proposed Private-Info AVP would be the same as the Proxy-Info,
except that it lasts for the whole session (or until the owner = removes
it).  Again the diagram with PI being the = Private-Info.


Client                    Agent                 =    A/S
 |          R1         =     |         R1+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A1+PI       =    |         A1+PI         = |
 |<------------------------|<----------------------|
 |                   =       |                 =       |
 |          R2+PI       =    |         R2+PI         = |
 |------------------------>|---------------------->|
 |                   =       |                 =       |
 |          A2+PI       =    |         A2+PI         = |
 |<------------------------|<----------------------|

So the Private-Info is different from the Proxy-Info, but only in
regards to lifetime.

-David

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CB3581.5F82C54C-- From tom111.taylor@bell.net Fri Aug 6 11:08:40 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CCE3A6924 for ; Fri, 6 Aug 2010 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.123 X-Spam-Level: X-Spam-Status: No, score=-100.123 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D418e9nmCvDP for ; Fri, 6 Aug 2010 11:08:38 -0700 (PDT) Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by core3.amsl.com (Postfix) with ESMTP id CB3923A6A10 for ; Fri, 6 Aug 2010 11:08:37 -0700 (PDT) Received: from BLU0-SMTP65 ([65.55.116.73]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Aug 2010 11:09:07 -0700 X-Originating-IP: [69.158.64.160] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([69.158.64.160]) by BLU0-SMTP65.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Aug 2010 11:09:04 -0700 Date: Fri, 06 Aug 2010 14:08:46 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: David Lehmann References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> <007d01cb3572$4e48d150$eada73f0$@net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2010 18:09:05.0599 (UTC) FILETIME=[7514DCF0:01CB3592] Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 18:08:40 -0000 Somewhere back in this correspondence the use of the Class AVP for this purpose was noted. I know that we used it to preserve state in the IETF Rs application, running in stateless mode. Does it not serve your needs too? David Lehmann wrote: > I was using the general term "agent" because it doesn't matter which > type it is, from the RFC's point of view. The Private-Info is just an > extension of the Proxy-Info. For the same reason that the Proxy-Info > exists, the Private-Info AVP has the same desired purpose: "It contains > state information that would otherwise be stored at the Diameter entity > that created it. As such, this AVP MUST be treated as opaque data by > entities other Diameter entities." The RFC (section 6.1.9) states that > the Proxy-Info can be use by a Proxy or Relay agent. So it really does > matter which type of agent uses the AVP nor does it matter for which > purpose. Who knows all of the clever ways an agent uses the Proxy-Info? > The RFC does not provide the specific purposes of the Proxy-Info, and > rightly so. Nor does the RFC need to spell out the purposes of the > Private-Info AVP. It is simply a tool to aid agents. > > > > -- > > David Lehmann > > Ulticom, Inc. > > 856-787-2952 > ... From dlehmann@ulticom.com Fri Aug 6 12:36:01 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EDF13A6A9D for ; Fri, 6 Aug 2010 12:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY54qLOHIaFY for ; Fri, 6 Aug 2010 12:35:42 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 159993A6A75 for ; Fri, 6 Aug 2010 12:35:14 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id FB11A15ECDD38661; Fri, 6 Aug 2010 15:34:56 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o76JYU8b024806; Fri, 6 Aug 2010 15:34:34 -0400 (EDT) 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: Fri, 6 Aug 2010 15:34:30 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Private-Info AVP Thread-Index: Acs1kn2U6O/fj/qBR1yNXOv8O2NspgACf9vA References: <7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com> <007d01cb3572$4e48d150$eada73f0$@net> From: "David Lehmann" To: "Tom Taylor" Received-SPF: none Cc: Daily William , dime@ietf.org Subject: Re: [Dime] Private-Info AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 19:36:01 -0000 No. The Class AVP has a specific use for apps. Section 8.20 says that the Class AVP "is to be used by Diameter Servers". It is not intended for agents. In addition, it says that the Class AVP "MUST be present in subsequent re-authorization, session termination and accounting messages." The Private-Info would have the requirement that it "MUST be present in subsequent messages in the session". Also, the Private-Info, being an extension of Proxy-Info would contain Proxy-Host AVP to identify who owns the data. If a Class AVP were inserted by an agent, one of the endpoints may try to interpret it as its own data. -- David Lehmann Ulticom, Inc. 856-787-2952 > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: Friday, August 06, 2010 2:09 PM > To: David Lehmann > Cc: Glen Zorn; Victor Fajardo; Daily William; dime@ietf.org > Subject: Re: [Dime] Private-Info AVP >=20 > Somewhere back in this correspondence the use of the Class AVP for this > purpose > was noted. I know that we used it to preserve state in the IETF Rs > application, > running in stateless mode. Does it not serve your needs too? >=20 > David Lehmann wrote: > > I was using the general term "agent" because it doesn't matter which > > type it is, from the RFC's point of view. The Private-Info is just an > > extension of the Proxy-Info. For the same reason that the Proxy-Info > > exists, the Private-Info AVP has the same desired purpose: "It contains > > state information that would otherwise be stored at the Diameter entity > > that created it. As such, this AVP MUST be treated as opaque data by > > entities other Diameter entities." The RFC (section 6.1.9) states that > > the Proxy-Info can be use by a Proxy or Relay agent. So it really does > > matter which type of agent uses the AVP nor does it matter for which > > purpose. Who knows all of the clever ways an agent uses the Proxy-Info? > > The RFC does not provide the specific purposes of the Proxy-Info, and > > rightly so. Nor does the RFC need to spell out the purposes of the > > Private-Info AVP. It is simply a tool to aid agents. > > > > > > > > -- > > > > David Lehmann > > > > Ulticom, Inc. > > > > 856-787-2952 > > > ... From sdecugis@nict.go.jp Sun Aug 8 18:19:17 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1E53A6901 for ; Sun, 8 Aug 2010 18:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os6skC+JhOXS for ; Sun, 8 Aug 2010 18:19:16 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 43DC73A6891 for ; Sun, 8 Aug 2010 18:19:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 8C2DB27DD0; Mon, 9 Aug 2010 03:19:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcqGLahWpGfk; Mon, 9 Aug 2010 03:19:45 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 0543027DCE; Mon, 9 Aug 2010 03:19:44 +0200 (CEST) Message-ID: <4C5F57A1.8090400@nict.go.jp> Date: Mon, 09 Aug 2010 10:19:29 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Glen Zorn References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net><4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> <4C5BD20E.9080802@nict.go.jp> <004a01cb3562$34d91460$9e8b3d20$@net> In-Reply-To: <004a01cb3562$34d91460$9e8b3d20$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 01:19:17 -0000 Hi, >> Yes, my concern was about interconnecting different domains together, >> when some of the domains want to move to Diameter. In this situation, a >> translation mechanism is mandatory, I think. > Justification, please? Well, if domain A "speaks" only Diameter, I don't see how domain B who speaks RADIUS can interconnect, except with a translation mechanism. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Sun Aug 8 18:34:19 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687F33A6A06 for ; Sun, 8 Aug 2010 18:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.992, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBEIdH0zJnXq for ; Sun, 8 Aug 2010 18:34:18 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 3C43A3A69DB for ; Sun, 8 Aug 2010 18:34:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id ADCDE27DD0; Mon, 9 Aug 2010 03:34:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFoNpTYhA1DI; Mon, 9 Aug 2010 03:34:48 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 5E7D327DCE; Mon, 9 Aug 2010 03:34:47 +0200 (CEST) Message-ID: <4C5F5B28.7070900@nict.go.jp> Date: Mon, 09 Aug 2010 10:34:32 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Glen Zorn References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> <003401cb3554$3ce0c6c0$b6a25440$@net> In-Reply-To: <003401cb3554$3ce0c6c0$b6a25440$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 01:34:19 -0000 Hi again Glen, > Precisely the problem: the necessity to provide for RADIUS compatibility > unnecessarily constrains the content of the Diameter AVPs. In fact, NASREQ > is not so much a Diameter application as RADIUS in a Diameter wrapper. This holds only when the Origin-AAA-Protocol AVP is present; otherwise there is no such limitation in the RFC, as far as I know. > Removing the need to artificially limit the length of the NASREQ AVP > payloads to 253 (or even 4073) octets would make NASREQ into a _real_ > Diameter application. (see previous comment) >>> In any case, if they decided to migrate to Diameter they could use the >>> pointless tunneling protocol, retiring their RADIUS server when the >>> transition was complete. >> You are implying that each domain can retire its RADIUS server only when >> *all* the domains have moved all their clients to Diameter... This >> reasoning may be possible in a single-domain context, but it does not >> hold in a multi-domain roaming consortium case. > Care to give some sort of rationale for this statement? Well, assume domain A is still using RADIUS and domain B has moved all its equipment to Diameter. Now a user from domain B is accessing the network through a NAS in domain A. NAS-A -> RADIA agent (in RADIUS) RDR -> domain B in Diameter. Now, one needs to de-tunnel the RADIUS message from the RDR and then have a RADIUS stack to interpret this message, right? Hence my comment that we cannot get rid of RADIUS in domain B until all domains in the consortium have moved to Diameter... In addition, with RADIA you loose the benefit of Diameter applications allowing to route different applications to different servers. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From jouni.nospam@gmail.com Tue Aug 10 04:34:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EFE3A695D for ; Tue, 10 Aug 2010 04:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82KNuJy0VMqd for ; Tue, 10 Aug 2010 04:34:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A52EA3A6912 for ; Tue, 10 Aug 2010 04:34:31 -0700 (PDT) Received: by fxm18 with SMTP id 18so645960fxm.31 for ; Tue, 10 Aug 2010 04:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=XUug0sM7UxdspDZIKbd3ZjvD5vXF67O5r15kRrWIoaw=; b=kFY8Z2zg3VaUvHuAgfJjpQg6uRxhwB7FMyVuQg2f5A61pZ6h7mf9HVq+biuZ4Aiepx C14iu1tDBweuVYYIReWuVd5e55ONB+kUJ5wOSgeFH9tqRu93ILVt3QZj3+KV/Edwdj4e fdzVAikFgpathoMQPuFKSwSVqsU20YYxqI6qM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=XaJctxd8z2WmCmxH8JwBz396NV7Ncm5lKgG0Bt5oXrn8rWOh/QdrWho5FAn2DqC3gG IILHSt5jsSKGXfmTwj30B+NSrkQvEAe4uLIRgTfVPZkYX89g4+5JbiqN1/Q1AXWkhiPs j/mtpSVy1B0uUYqfRPeXQuTlsCeizGlbIvRJs= Received: by 10.223.113.144 with SMTP id a16mr17960072faq.41.1281440106092; Tue, 10 Aug 2010 04:35:06 -0700 (PDT) Received: from ku-hupnet243-74.hupnet.helsinki.fi (vallila-gw.hupnet.helsinki.fi [128.214.20.122]) by mx.google.com with ESMTPS id i9sm1853629faa.15.2010.08.10.04.34.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Aug 2010 04:35:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4C5BAAF1.5080901@nict.go.jp> Date: Tue, 10 Aug 2010 14:34:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00bc01cb34c4$c4a5ddb0$4df19910$@net> <425BF499-96F0-41EB-BE0E-65AAADA9F3C6@gmail.com> <4C5B6AE5.9030604@nict.go.jp> <0F53C723-E62D-401D-B709-FCB84263AEC1@gmail.com> <4C5BAAF1.5080901@nict.go.jp> To: dime@ietf.org X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] New milestones proporal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 11:34:33 -0000 Folks,=20 See the latest modified version of the milestones. Unless there are any = larger disagreement, this is what we are going forward with. - Jouni & Lionel Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the = IESG for consideration as a Proposed Standards: * 'Diameter Mobile IPv6: Support for Home Agent to Diameter = Server=20 Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server = to=20 Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an=20= Informational RFC Done - Submit 'Quality of Service Parameters for Usage with = Diameter' to=20 the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for = consideration as=20 a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication = Protocol' as=20 DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing=20= Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group = item Done - Submit 'Quality of Service Attributes for Diameter' to the = IESG for=20 consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for = consideration=20 as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing=20= Clarifications' to the IESG for consideration as a Proposed=20= Standard Done - Submit 'Updated IANA Considerations for Diameter Command = Code=20 Allocations' as DIME working group item Done - Submit 'Updated IANA Considerations for Diameter Command = Code=20 Allocations' to the IESG for consideration as a Proposed = Standard Done - Submit 'Diameter NAT Control Application' as DIME working = group=20 item Done - Submit 'Diameter Capabilities Update' as DIME working group = item Done - Submit 'Diameter Credit Control Application MIB' to the = IESG for=20 consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for = consideration=20 as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for = consideration=20 as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME = working=20 group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic = Key=20 Transport' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized = Routing'=20 as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME = working group=20 item Done - Submit 'Diameter Extended NAPTR' as DIME working group item Aug 2010 - Submit Revision of 'Diameter Network Access Server = Application -=20 RFC 4005bis' as DIME working group item Aug 2010 - Submit Revision of 'Diameter Base Protocol' to the IESG for=20= consideration as a Proposed Standard Aug 2010 - Submit 'Diameter Priority Attribute Value Pairs' to the = IESG for=20 consideration as a Proposed Standard Aug 2010 - Submit 'Diameter Attribute-Value Pairs for Cryptographic = Key=20 Transport' to the IESG for consideration as a Proposed = Standard Sep 2010 - Submit 'Diameter Application Design Guidelines' to the IESG = for=20 consideration as a BCP document Sep 2010 - Submit 'Diameter NAT Control Application' to the IESG for=20= consideration as a Proposed Standard Sep 2010 - Submit 'Diameter IKEv2 PSK' to the IESG for consideration = as a=20 Proposed Standard Sep 2010 - Submit 'Realm-Based Redirection In Diameter' to the IESG = for=20 consideration as a Proposed Standard Oct 2010 - Submit 'Diameter Extended NAPTR' to the IESG for = consideration as a=20 Proposed Standard Nov 2010 - Submit 'Diameter Support for Proxy Mobile IPv6 Localized = Routing'=20 to the IESG for consideration as a Proposed Standard Jan 2011 - Submit new DIME charter to the IESG Jul 2011 - Submit 'Diameter Support for EAP Re-authentication = Protocol' to the=20 IESG for consideration as a Proposed Standard Sep 2011 - Submit Revision of 'Diameter Network Access Server = Application -=20 RFC 4005bis' to the IESG for consideration as a Proposed = Standard From jouni.nospam@gmail.com Wed Aug 11 03:09:57 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8A03A6982 for ; Wed, 11 Aug 2010 03:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF63zyfq3X53 for ; Wed, 11 Aug 2010 03:09:56 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 595C43A68F5 for ; Wed, 11 Aug 2010 03:09:56 -0700 (PDT) Received: by fxm18 with SMTP id 18so1402420fxm.31 for ; Wed, 11 Aug 2010 03:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=63JKWuP9V+nWW2eAYiQMOBXWK6uB7qfPYZRu2R+Fb2c=; b=ELQOOxeWNY1Wl9LaqbTYV4R6aL7okOnW7WLxNaPCgup0OZWdpn6V3caY1JW2Rq6TQ2 ZFKJ2fXV1A/jCfQBFhmps2qGnAKezUgwnDjVVsaDInD8xrng6+mwQQYt3TTcECyRxyTd g5NIYChZ2h8fya9iBvuytcKUYpf6khRfBkegU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=kHmgT+YRWuJHs/KRkf65NGZm2PSNRQb+DuvTYQWS+HTjwMjdhQ5DlEYzX+/9pv6z7W 0fj3jaMDNY3u//v6euHhVKWo1W9DS8JcNECFojenjQk4G0HZhX5MiovNgnXSJhUfJRrQ 7LpeQ28Qzv+2QZdH9NH+PgkUq8l0A7xHkE/G0= Received: by 10.223.123.145 with SMTP id p17mr19616776far.90.1281521431772; Wed, 11 Aug 2010 03:10:31 -0700 (PDT) Received: from a88-114-173-193.elisa-laajakaista.fi (a88-114-173-193.elisa-laajakaista.fi [88.114.173.193]) by mx.google.com with ESMTPS id f11sm2756430fak.44.2010.08.11.03.10.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Aug 2010 03:10:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 11 Aug 2010 13:10:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <286ED423-EBF7-46E7-BF32-67C643E48BFB@gmail.com> References: To: dime@ietf.org, Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Concluded: WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:09:57 -0000 Hello all, Chairs (and the WG) have decided to adopt draft-zorn-dime-rfc4005bis-01 = as a Dime WG document. Glen, go ahead and post the -01 as the = draft-ietf-dime-rfc4005bis-00. - Jouni & Lionel On Aug 2, 2010, at 1:54 PM, jouni korhonen wrote: >=20 > As discussed during the Maastricht DIME WG meeting, the chairs agreed = to confirm the adoption of draft-zorn-dime-rfc4005bis-01 as the WG Item. = The work regarding RFC4005bis has been around the corner for some time = and discussed several times among AAA Doctors. There was support for the = adoption during the WG meeting. >=20 > The one week poll ends 9-Aug-2010, 23:59 (CEST+1).. Silence counts = also as "yes", so unless you have a strong reason to disagree (like the = North Pole melts or Diameter will become obsolete due the adoption of = this draft), then express your "no" on the list with a proper reasoning = why. Technical details on the actual draft content can be handled later = (if/when the document gets adopted). >=20 > - Jouni & Lionel From hannes.tschofenig@nsn.com Wed Aug 11 03:41:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC38E3A6807; Wed, 11 Aug 2010 03:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icZNSPjUccb3; Wed, 11 Aug 2010 03:41:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 8C9FF3A687D; Wed, 11 Aug 2010 03:41:32 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg7vj012349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Aug 2010 12:42:07 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg39M025777; Wed, 11 Aug 2010 12:42:05 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 12:42:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Aug 2010 13:42:03 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E5D28F@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback solicited for Privacy and Identity Management Terminology Thread-Index: Acs5PbPPmDYC77k+R6SShBKUqSLNJg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , , X-OriginalArrivalTime: 11 Aug 2010 10:42:04.0831 (UTC) FILETIME=[D6B932F0:01CB3941] Subject: [Dime] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:41:33 -0000 Hi all,=20 we have just submitted a new version of the privacy and identity management terminology document: http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology-01. txt =20 The full document titel is "Terminology for Talking about Privacy by Data Minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management" and here is the abstract:=20 This document is an attempt to consolidate terminology in the field privacy by data minimization. It motivates and develops definitions for anonymity/identifiability, (un)linkability, (un)detectability, (un)observability, pseudonymity, identity, partial identity, digital identity and identity management. Starting the definitions from the anonymity and unlinkability perspective and not from a definition of identity (the latter is the obvious approach to some people) reveals some deeper structures in this field. =20 Please let us know whether the terminology is useful and complete. Your input is highly appreciated! Ciao Hannes From root@core3.amsl.com Wed Aug 11 09:15:02 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C477D3A68D4; Wed, 11 Aug 2010 09:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100811161502.C477D3A68D4@core3.amsl.com> Date: Wed, 11 Aug 2010 09:15:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc4005bis-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 16:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Network Access Server Application Author(s) : G. Zorn Filename : draft-ietf-dime-rfc4005bis-00.txt Pages : 66 Date : 2010-08-11 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc4005bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-11090709.I-D@ietf.org> --NextPart-- From avi@bridgewatersystems.com Wed Aug 11 13:28:11 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E83F3A680C for ; Wed, 11 Aug 2010 13:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAf+SjRlJfL7 for ; Wed, 11 Aug 2010 13:28:10 -0700 (PDT) Received: from mail51.messagelabs.com (mail51.messagelabs.com [216.82.241.99]) by core3.amsl.com (Postfix) with ESMTP id 295C23A67DA for ; Wed, 11 Aug 2010 13:28:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-13.tower-51.messagelabs.com!1281558525!58264846!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 850 invoked from network); 11 Aug 2010 20:28:45 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-13.tower-51.messagelabs.com with RC4-SHA encrypted SMTP; 11 Aug 2010 20:28:45 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Wed, 11 Aug 2010 16:28:45 -0400 From: Avi Lior To: "dime@ietf.org" , "draft-ietf-dime-realm-based-redirect@tools.ietf.org" , "dime-chairs@tools.ietf.org" Date: Wed, 11 Aug 2010 16:28:43 -0400 Thread-Topic: Review of draft-ietf-dime-realm-based-redirect-03 Thread-Index: Acs5k8sSmWxQDaSsTlucWjLPA9Mktw== Message-ID: <1FD363A7-3530-4F5F-8F17-0B0A861C33D4@bridgewatersystems.com> References: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> <02AE8F14-B61F-4EAF-8654-7B86F154A9C8@huawei.com> In-Reply-To: <02AE8F14-B61F-4EAF-8654-7B86F154A9C8@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: multipart/alternative; boundary="_000_1FD363A735304F5F8F170B0A861C33D4bridgewatersystemscom_" MIME-Version: 1.0 Subject: [Dime] Review of draft-ietf-dime-realm-based-redirect-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:28:11 -0000 --_000_1FD363A735304F5F8F170B0A861C33D4bridgewatersystemscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have reviewed draft-ietf-dime-realm-based-redirect-03 document -- or I sh= ould say i started but I had to stop because there are serious fundamental = issues with this draft. I should start with the fact that i think the problem statement raised by t= he draft is valid. Also, I think that Diameter base 3588 should have suppor= ted Realm based redirection as well as host based redirection. Actually Rea= lm-based redirection are probably more useful. However, the problem I am having is that the draft is changing the semantic= s of a Redirect Agent as defined by base and I dont think that we should be= allowed to do that. I get that the draft got around backwards capability issue surrounding the = new AVPs be introduced by asserting that only new applications will support= the attributes. But in order to deliver this feature in 3588 the behavior of the Redirect A= gent had to change. This new redirect agent has to differentiate between applications that do s= upport realm base redirection vs non-realmbased redirection. This is new base behavior and thus should be done in Diameter V2 There is an alternative - which i thought was the approach taken when i sta= rted to read the draft and that is: -let the Application itself perform the redirection. To use the example pr= ovided, if the operator does not want to host the application anymore, it c= an let the Application respond back with the realm and/host redirection att= ributes. On 02-08-2010, at 10:11 , Tina TSOU wrote: Hi Avi, would u like to review it? 3 reviews at least are requested. Wish u= in purple:) B. R. Tina http://tinatsou.weebly.com/index.html /div> Begin forwarded message: From: jouni korhonen = > Date: August 2, 2010 12:26:00 PM GMT+02:00 To: dime@ietf.org, draft-ietf-dime-realm-based-redire= ct@tools.ietf.org Cc: dime-chairs@tools.ietf.org Subject: WGLC starting for draft-ietf-dime-realm-based-redirect A two weeks WGLC for Realm-Based Redirection In Diameter (draft-ietf-dime-r= ealm-based-redirect-03) starts as of today 2-Aug-2010 and ends on Monday 16= -Aug-2010 23:59 (CEST+1). We _require_ at least three reviews from people who are not authors of the = document. In case of an inadequate review success, we'll just keep the docu= ment in the WG and go for another WGLC later (that will again need a new se= t of three reviews ;). So lobby people to review! - Jouni & Lionel Avi Lior avi@bridgewatersystems.com office: +1 613-591-9104x6417 cell: +1 613-796-4183 --_000_1FD363A735304F5F8F170B0A861C33D4bridgewatersystemscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,

I h= ave reviewed draft-ietf-dime-realm-based-redirect-03 document -- or I shoul= d say i started but I had to stop because there are serious fundamental iss= ues with this draft.

I should start with the fact = that i think the problem statement raised by the draft is valid. Also, I th= ink that Diameter base 3588 should have supported Realm based redirection a= s well as host based redirection. Actually Realm-based redirection are prob= ably more useful.

However, the problem I am having= is that the draft is changing the semantics of a Redirect Agent as defined= by base and I dont think that we should be allowed to do that.
<= br>
I get that the draft got around backwards capability issue su= rrounding the new AVPs be introduced by asserting that only new application= s will support the attributes.

But in order to del= iver this feature in 3588 the behavior of the Redirect Agent had to change.=

This new redirect agent has to differentiate betw= een applications that do support realm base redirection vs non-realmbased r= edirection.

This is new base behavior and thus sho= uld be done in Diameter V2

There is an alternative= - which i thought was the approach taken when i started to read the draft = and that is:

-let the Application itself perform t= he redirection.  To use the example provided, if the operator does not= want to host the application anymore, it can let the Application respond b= ack with the realm and/host redirection attributes.


=


On 02-08-2010, at 10:11 , Tina = TSOU wrote:

Hi Avi, would u like to review it? 3= reviews at least are requested. Wish u in purple:)

=
=

Begin for= warded message:

From: = jouni korhonen <jouni.nospam@= gmail.com>
Date: August 2, 2010 12:26:00 PM GMT+02:00
To: dime@ietf.org, draft-ietf-dime-realm-based-redirect@tools.ietf.or= g
Cc: <= a href=3D"mailto:dime-chairs@tools.ietf.org">dime-chairs@tools.ietf.org=
Subject: WGLC starting for d= raft-ietf-dime-realm-based-redirect

A two weeks WGLC for Realm-Based Redirectio= n In Diameter (draft-ietf-dime-realm-based-redirect-03) starts as of today = 2-Aug-2010 and ends on Monday 16-Aug-2010 23:59 (CEST+1).

We _requir= e_ at least three reviews from people who are not authors of the document. = In case of an inadequate review success, we'll just keep the document in th= e WG and go for another WGLC later (that will again need a new set of three= reviews ;). So lobby people to review!

- Jouni & Lionel


off= ice: +1 613-591-9104x6417
   &n= bsp;cell: +1 613-796-4183

= --_000_1FD363A735304F5F8F170B0A861C33D4bridgewatersystemscom_-- From stefan.winter@restena.lu Fri Aug 13 02:11:45 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F123A6784 for ; Fri, 13 Aug 2010 02:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DEiwwkgEe+B for ; Fri, 13 Aug 2010 02:11:43 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0459C3A6893 for ; Fri, 13 Aug 2010 02:11:42 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 87B4910598 for ; Fri, 13 Aug 2010 11:12:17 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 535D410586 for ; Fri, 13 Aug 2010 11:12:17 +0200 (CEST) Message-ID: <4C650C71.9020000@restena.lu> Date: Fri, 13 Aug 2010 11:12:17 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: dime@ietf.org References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> In-Reply-To: <003201cb347a$0fb844a0$2f28cde0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:11:46 -0000 Hi, > The problem is that apparently nobody has _ever_ transitioned from RADIUS to > Diameter and it appears as if nobody ever will. Regarding EDUROAM, Diameter > existed long before EDUROAM but they chose to hack RADIUS in their own way. > In any case, if they decided to migrate to Diameter they could use the > pointless tunneling protocol, retiring their RADIUS server when the > transition was complete. For the record: Yes, Diameter-the-protocol existed before going into production service, and we looked at it. Diameter-the-actually-usable-implementation didn't exist, and still doesn't - at least not with our requirements. Sebastien's software is the first thing that gets vaguely close (too many EAP types missing though), and yes, we are evaluating it. Also the 4005 part of it. More for the record: the first eduroam prototype was online June 2003; RFC3588 dates September 2003. Your definition of "long before" violates temporal continuity. The pointless tunneling protocol doesn't help at all. As I pointed out at the mic at earlier occasions: the authentication can only take place if the final auth server is able to *unwrap* the message into plain RADIUS. If the end auth server is a pure RADIUS server, someone else has to do it for him. The outer Diameter message might have been decorated with untranslatable extra attributes on the way; creating a highly ambiguous state of the auth (unwrapped RADIUS might have conflicting values to the added genuine Diameter ones? Even if unwrapping works, what if a (Diameter) auth server crafts a (Diameter) answer, with untranslatable attributes which can never be translated back to a RADIUS NAS? If forwarded along multiple proxies, the wrapping entity would need signalling on whether there will be an entity along the line to unwrap the message at all. If there is none, the tunnel has no other end. Signalling of this along multiple hops is unspecified in your draft, if I'm not mistaken. I don't think your draft has answers to these questions. Anyway, the tunneling requires both ends of the tunnel to understand RADIUS. It is thus not a transition mechanism. It's an alternative transport. And a not very useful one, IMHO. I acknowledge your point that there are apparently some organisations which have hardwired the use of Diameter in their specs, while actually wanting to speak RADIUS on some paths, and for these organisations, RADIUS disguised as Diameter is a tool they might need. Your point "noone ever transitioned" is true; but for reasons of lack of options to do so. It's not exactly fair to blame the RFC for it. FWIW, if were to write about RADIUS<->Diameter translation, it would be one very short paragraph "This doesn't work." Note that I think that this sentence is necessary IMHO; merely not writing *anything* about the topic, because "noone ever used it", is not enough. You know, some people might be *curious* about the topic, and could be *told* that they need not look any further. Greetings, Stefan Winter >> Best regards, >> Sebastien. >> >> -- >> Sebastien Decugis >> Research fellow >> Network Architecture Group >> NICT (nict.go.jp) >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From stefan.winter@restena.lu Fri Aug 13 02:16:40 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9783A68BC for ; Fri, 13 Aug 2010 02:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiQeNgViL5tq for ; Fri, 13 Aug 2010 02:16:39 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7B643A685E for ; Fri, 13 Aug 2010 02:16:38 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7B78F10598 for ; Fri, 13 Aug 2010 11:17:15 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6F6E710586 for ; Fri, 13 Aug 2010 11:17:15 +0200 (CEST) Message-ID: <4C650D9B.1000503@restena.lu> Date: Fri, 13 Aug 2010 11:17:15 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: dime@ietf.org References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net><4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:16:40 -0000 > I think that the idea is not to say that RADIUS/Diameter interworking is > not possible at all. The idea is more about to acknowledge the fact that > RFC 4005 can not remain the de-facto and the only reference for > RADIUS/Diameter translation as this section is under specified and not > applicable anyway to all RADIUS/Diameter interworking scenarios. As > something has to be done, it is proposed to remove anything about > RADIUS/Diameter translation from RFC 4005. The NASREQ application is > self-consistent without this part. That seems like a good reasoning. So: I support adoption of this document. Greetings, Stefan Winter >>> The problem is that apparently nobody has _ever_ transitioned from >>> RADIUS to Diameter and it appears as if nobody ever will. >> I am not so pessimistic about Diameter :) >> >>> Regarding EDUROAM, Diameter >>> existed long before EDUROAM but they chose to hack RADIUS >> in their own way. >>> In any case, if they decided to migrate to Diameter they >> could use the >>> pointless tunneling protocol, retiring their RADIUS server when the >>> transition was complete. >> You are implying that each domain can retire its RADIUS >> server only when >> *all* the domains have moved all their clients to Diameter... >> This reasoning may be possible in a single-domain context, >> but it does not hold in a multi-domain roaming consortium case. > About roaming issues, I think that we should make the difference between > inter-domain and intra-domain. If there exists a solution for > RADIUS/Diameter interworking, each domain could rely on either RADIUS or > Diameter, and the interworking solution would be applied *only* between > AAA servers/proxies. In intra-domain, if a single AAA server can support > both RADIUS and Diameter clients, the migration path is quite simple, > no? > >> Best regards, >> Sebastien. >> >> -- >> Sebastien Decugis >> Research fellow >> Network Architecture Group >> NICT (nict.go.jp) >> >> _______________________________________________ >> 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 -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From gwz@net-zen.net Sun Aug 15 02:37:13 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302213A68B9 for ; Sun, 15 Aug 2010 02:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.792 X-Spam-Level: X-Spam-Status: No, score=-100.792 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZUtWEq8v246 for ; Sun, 15 Aug 2010 02:37:11 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id 8F6D73A67A7 for ; Sun, 15 Aug 2010 02:37:11 -0700 (PDT) Received: (qmail 20780 invoked from network); 15 Aug 2010 09:37:46 -0000 Received: from unknown (124.157.141.92) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 15 Aug 2010 09:37:45 -0000 From: "Glen Zorn" To: "'Stefan Winter'" References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C650C71.9020000@restena.lu> In-Reply-To: <4C650C71.9020000@restena.lu> Date: Sun, 15 Aug 2010 16:37:27 +0700 Organization: Network Zen Message-ID: <000e01cb3c5d$7b8d1620$72a74260$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs6x6Tr3aKyCp1QSCyj2WV+xlmkfABhifzw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 09:37:13 -0000 Stefan Winter [mailto://stefan.winter@restena.lu] writes: > Hi, >=20 > > The problem is that apparently nobody has _ever_ transitioned from > RADIUS to > > Diameter and it appears as if nobody ever will. Regarding EDUROAM, > Diameter > > existed long before EDUROAM but they chose to hack RADIUS in their = own > way. > > In any case, if they decided to migrate to Diameter they could use = the > > pointless tunneling protocol, retiring their RADIUS server when the > > transition was complete. >=20 > For the record: Yes, Diameter-the-protocol existed before going into > production service, and we looked at it. > Diameter-the-actually-usable-implementation didn't exist, and still > doesn't - at least not with our requirements.=20 I see. Where did the actually usable implementation of RADIUS over TCP = come from? > Sebastien's software is > the first thing that gets vaguely close (too many EAP types missing > though), and yes, we are evaluating it. Also the 4005 part of it. >=20 > More for the record: the first eduroam prototype was online June 2003; > RFC3588 dates September 2003. Your definition of "long before" = violates > temporal continuity. Of course, my mistake for not realizing that initial prototype =3D=3D = published RFC. >=20 > The pointless tunneling protocol doesn't help at all. As I pointed out > at the mic at earlier occasions: the authentication can only take = place > if the final auth server is able to *unwrap* the message into plain > RADIUS.=20 Yes. > If the end auth server is a pure RADIUS server, someone else has > to do it for him.=20 Why (& how) would a Diameter message be delivered to a pure RADIUS = server? > The outer Diameter message might have been decorated > with untranslatable extra attributes on the way; creating a highly > ambiguous state of the auth (unwrapped RADIUS might have conflicting > values to the added genuine Diameter ones?=20 The only element relevant to authentication/authorization in a RADIA = message is the encapsulated RADIUS message; any other Diameter AVPs that may be present are only for transport purposes. > Even if unwrapping works, > what if a (Diameter) auth server crafts a (Diameter) answer, with > untranslatable attributes which can never be translated back to a = RADIUS > NAS?=20 Then the Diameter server in question is broken; nevertheless, what = happens if a NASREQ app server does the same thing today? > If forwarded along multiple proxies, the wrapping entity would need > signalling on whether there will be an entity along the line to unwrap > the message at all. If there is none, the tunnel has no other end. > Signalling of this along multiple hops is unspecified in your draft, = if > I'm not mistaken. Because it's unnecessary; if there is no RADIA app server in the = destination realm, a standard "undeliverable message" error must be returned. That point should be made in the draft. >=20 > I don't think your draft has answers to these questions. >=20 > Anyway, the tunneling requires both ends of the tunnel to understand > RADIUS. It is thus not a transition mechanism.=20 OK. How, then, is RFC 4005 (one-way) translation a transition = mechanism? As I have pointed out many times, the end NASREQ server must understand = how to respond to the request in a translatable way; if transition is = complete, that dead code undoubtedly remains. OTOH, the RADIA servers can be = retired, along with the associated RADIUS servers. > It's an alternative > transport. And a not very useful one, IMHO. I acknowledge your point > that there are apparently some organisations which have hardwired the > use of Diameter in their specs, while actually wanting to speak RADIUS > on some paths, and for these organisations, RADIUS disguised as = Diameter > is a tool they might need. & is precisely what RADIA supplies, but w/o the overhead of = "translation". >=20 > Your point "noone ever transitioned" is true; but for reasons of lack = of > options to do so. It's not exactly fair to blame the RFC for it. FWIW, > if were to write about RADIUS<->Diameter translation, it would be one > very short paragraph "This doesn't work." Note that I think that this > sentence is necessary IMHO; merely not writing *anything* about the > topic, because "noone ever used it", is not enough. You know, some > people might be *curious* about the topic, and could be *told* that = they > need not look any further. Lots of people are curious about lots of things... >=20 > Greetings, >=20 > Stefan Winter >=20 > >> Best regards, > >> Sebastien. > >> > >> -- > >> Sebastien Decugis > >> Research fellow > >> Network Architecture Group > >> NICT (nict.go.jp) > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Sun Aug 15 03:03:18 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49DB3A67A7 for ; Sun, 15 Aug 2010 03:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.026 X-Spam-Level: X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ongxu6qkt+z0 for ; Sun, 15 Aug 2010 03:03:17 -0700 (PDT) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id ACA323A6830 for ; Sun, 15 Aug 2010 03:03:17 -0700 (PDT) Received: (qmail 25944 invoked from network); 15 Aug 2010 10:03:53 -0000 Received: from unknown (124.157.141.92) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 15 Aug 2010 10:03:53 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net><4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> <4C5BD20E.9080802@nict.go.jp> <004a01cb3562$34d91460$9e8b3d20$@net> <4C5F57A1.8090400@nict.go.jp> In-Reply-To: <4C5F57A1.8090400@nict.go.jp> Date: Sun, 15 Aug 2010 17:03:34 +0700 Organization: Network Zen Message-ID: <001201cb3c61$21952d70$64bf8850$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs3YPb3zfvnW4drR46ZYmZS6N5UHwE/iUMg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 10:03:19 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hi, > > >> Yes, my concern was about interconnecting different domains together, > >> when some of the domains want to move to Diameter. In this situation, > a > >> translation mechanism is mandatory, I think. > > Justification, please? > Well, if domain A "speaks" only Diameter, I don't see how domain B who > speaks RADIUS can interconnect, except with a translation mechanism. If 'A' is the VAAA & 'B' is the HAAA, translation is impossible anyway unless A respects the RADIUS rules WRT AVP & message length. IIRC, though, we're talking about the opposite case, where 'B' is the VAAA & 'A' is transitioning from RADIUS to Diameter. This implies that there _is_ a RADIUS server in the 'A' realm (otherwise it would not be in transition) so I fail to see why the RADIA approach wouldn't work... > > Best regards, > Sebastien. > > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From gwz@net-zen.net Sun Aug 15 03:19:01 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD133A680E for ; Sun, 15 Aug 2010 03:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.07 X-Spam-Level: X-Spam-Status: No, score=-102.07 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqp2zuGtnFfr for ; Sun, 15 Aug 2010 03:19:00 -0700 (PDT) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id 0DD1D3A6784 for ; Sun, 15 Aug 2010 03:18:59 -0700 (PDT) Received: (qmail 22096 invoked from network); 15 Aug 2010 10:19:36 -0000 Received: from unknown (124.157.141.92) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 15 Aug 2010 10:19:35 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> <003401cb3554$3ce0c6c0$b6a25440$@net> <4C5F5B28.7070900@nict.go.jp> In-Reply-To: <4C5F5B28.7070900@nict.go.jp> Date: Sun, 15 Aug 2010 17:19:17 +0700 Organization: Network Zen Message-ID: <001301cb3c63$53471f70$f9d55e50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs3YxEy1cSLr9CeSXKDADv79i6kPQE/zzlg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 10:19:01 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hi again Glen, Hi, sorry for the slow reply! ... > >>> In any case, if they decided to migrate to Diameter they could use > the > >>> pointless tunneling protocol, retiring their RADIUS server when the > >>> transition was complete. > >> You are implying that each domain can retire its RADIUS server only > when > >> *all* the domains have moved all their clients to Diameter... This > >> reasoning may be possible in a single-domain context, but it does not > >> hold in a multi-domain roaming consortium case. > > Care to give some sort of rationale for this statement? > Well, assume domain A is still using RADIUS and domain B has moved all > its equipment to Diameter. > Now a user from domain B is accessing the network through a NAS in > domain A. > > NAS-A -> RADIA agent (in RADIUS) > RDR -> domain B in Diameter. > Now, one needs to de-tunnel the RADIUS message from the RDR and then > have a RADIUS stack to interpret this message, right? Yes; presumably this would be the RADIUS server that they are retiring. > Hence my comment that we cannot get rid of RADIUS in domain B until all > domains in the consortium have moved to Diameter... OK, but it was the assertion that "This reasoning may be possible in a single-domain context, but it does not hold in a multi-domain roaming consortium case" that I was questioning. > In addition, with RADIA you loose the benefit of Diameter applications > allowing to route different applications to different servers. I'm confused: isn't the only Diameter app that deals w/RADIUS stuff NASREQ? > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From gwz@net-zen.net Sun Aug 15 03:48:38 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855803A67A7 for ; Sun, 15 Aug 2010 03:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.108 X-Spam-Level: X-Spam-Status: No, score=-102.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ex1OXpPugig for ; Sun, 15 Aug 2010 03:48:37 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 767D43A657C for ; Sun, 15 Aug 2010 03:48:37 -0700 (PDT) Received: (qmail 11492 invoked from network); 15 Aug 2010 10:49:12 -0000 Received: from unknown (124.157.141.92) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 15 Aug 2010 10:49:11 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" , "'Romascanu, Dan \(Dan\)'" References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <4C5B69A9.601@nict.go.jp> In-Reply-To: <4C5B69A9.601@nict.go.jp> Date: Sun, 15 Aug 2010 17:48:53 +0700 Organization: Network Zen Message-ID: <001401cb3c67$760f66d0$622e3470$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs1CV2CnHuSFT4pSHuFOuxqKmbbGQHWgndA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 10:48:38 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > Hello Dan, > > >> First of all, not being useful is a good enough rationale to > >> revise a RFC? > > Let me try to argue that yes, it is. > It is good to know for the general case. > > > A section in a Proposed Standard > > that is not useful may lead to (at least) two counter-productive > > effects: > > - efforts are being made for implementation that result in useless > code > > with the risk of bugs and wasting resources > That would be the case if that section was claimed as "mandatory to > implement". It is not the case in RFC4005. So, people will implement it > only when they plan to actually use it. This would be true only if all NASREQ implementations are custom jobs. I'm not that pessimistic about Diameter ;-). > > > - the function that is described by the 'not useful' section seems to > > apparently solve what may be a real problem, discouraging search other > > ways of solving the problem (as 'there already is a standard way') > I personnally believe that the solution presented in RFC4005 is as good > as it can be, and there will be no better solution for solving this > particular problem. Obviously, I disagree :-). A possibly interesting historical note: but for political reasons, the RADIA approach would be the one in RFC 4005. ... > Since this section describes how to translate RADIUS to Diameter NASREQ > application (and not the general translation case), I think it makes > sense to have this inside this document. But I have no objection should > the group decide to reorganize the set of documents to group all > RADIUS/Diameter translation sections from all documents into one big > guideline. It is a large work. Actually (as Stefan noted) the work is very slight: "It doesn't work". > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Sun Aug 15 18:37:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DD13A683C for ; Sun, 15 Aug 2010 18:37:33 -0700 (PDT) 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=0.306, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcEKL-IyBxuE for ; Sun, 15 Aug 2010 18:37:32 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 630763A6852 for ; Sun, 15 Aug 2010 18:37:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 1BFBF27DD0 for ; Mon, 16 Aug 2010 03:38:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9qh7OUDY1Or for ; Mon, 16 Aug 2010 03:38:03 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 9473C27DCC for ; Mon, 16 Aug 2010 03:38:02 +0200 (CEST) Message-ID: <4C689665.4090802@nict.go.jp> Date: Mon, 16 Aug 2010 10:37:41 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: dime@ietf.org References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C650C71.9020000@restena.lu> In-Reply-To: <4C650C71.9020000@restena.lu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 01:37:33 -0000 Hi, Le 13/08/2010 18:12, Stefan Winter a écrit : > FWIW, if were to write about RADIUS<->Diameter translation, it would > be one very short paragraph "This doesn't work." Note that I think > that this sentence is necessary IMHO; merely not writing *anything* > about the topic, because "noone ever used it", is not enough. You > know, some people might be *curious* about the topic, and could be > *told* that they need not look any further. Ideally, the RFC4005 bis will contain this sentence, with an explanation of why it would not work. Personnally, I still don't see why is that. I agree that in a few cases there are untranslatable attributes, but then: - as long as the Diameter server is aware of a RADIUS end point, it can avoid these attributes. - in any case if we require to send this large data, RADIA will not help. But, now the draft has been accepted as a WG item, so I guess there is little interest in continuing this argument ^^. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Sun Aug 15 18:44:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677BD3A6934 for ; Sun, 15 Aug 2010 18:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXSATMA5VNyC for ; Sun, 15 Aug 2010 18:44:28 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id 5D2C03A6919 for ; Sun, 15 Aug 2010 18:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 4642027DD0; Mon, 16 Aug 2010 03:45:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgL8In2zABIA; Mon, 16 Aug 2010 03:45:01 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id 63C1A27DCC; Mon, 16 Aug 2010 03:45:00 +0200 (CEST) Message-ID: <4C689807.20702@nict.go.jp> Date: Mon, 16 Aug 2010 10:44:39 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Glen Zorn References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C5B65DB.3040006@nict.go.jp> <003401cb3554$3ce0c6c0$b6a25440$@net> <4C5F5B28.7070900@nict.go.jp> <001301cb3c63$53471f70$f9d55e50$@net> In-Reply-To: <001301cb3c63$53471f70$f9d55e50$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 01:44:29 -0000 Hi Glen, all, >> Hence my comment that we cannot get rid of RADIUS in domain B until all >> domains in the consortium have moved to Diameter... > OK, but it was the assertion that "This reasoning may be possible in a > single-domain context, but it does not hold in a multi-domain roaming > consortium case" that I was questioning. This implies that when you are part of a consortium, you are to maintain your RADIUS equipment as long as at least one of the domains in the consortium has not completed its transition to Diameter -- which costs money. This certainly will discourage any member of the consortium to be the first to transition, and so it will (did) not happen... >> In addition, with RADIA you loose the benefit of Diameter applications >> allowing to route different applications to different servers. > I'm confused: isn't the only Diameter app that deals w/RADIUS stuff NASREQ? No. See for example RFC4740 section 12.1 (Diameter SIP). Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Sun Aug 15 18:56:08 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47553A67A1 for ; Sun, 15 Aug 2010 18:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScoI4hgyYNdF for ; Sun, 15 Aug 2010 18:56:07 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id C76663A63EC for ; Sun, 15 Aug 2010 18:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id AE54027DD0 for ; Mon, 16 Aug 2010 03:56:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ia8wcEexu5U for ; Mon, 16 Aug 2010 03:56:38 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id A0B5F27DCC for ; Mon, 16 Aug 2010 03:56:37 +0200 (CEST) Message-ID: <4C689AC0.4010400@nict.go.jp> Date: Mon, 16 Aug 2010 10:56:16 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: dime@ietf.org References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <4C5B69A9.601@nict.go.jp> <001401cb3c67$760f66d0$622e3470$@net> In-Reply-To: <001401cb3c67$760f66d0$622e3470$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 01:56:08 -0000 Hi again Glen, all, >> I personnally believe that the solution presented in RFC4005 is as good >> as it can be, and there will be no better solution for solving this >> particular problem. > Obviously, I disagree :-). A possibly interesting historical note: but for > political reasons, the RADIA approach would be the one in RFC 4005. > > ... It is indeed an interesting note, thank you for telling. It would tend to indicate that both mechanisms are wanted, right? Note that although I think RADIA needs some more design work (e.g. how the RADIUS security is handled) I believe it is useful. It simply solves a different problem than the translation mechanism. I think both approaches are useful, and my initial comment was only that I don't see the benefit of discarding the translation mechanism. > Actually (as Stefan noted) the work is very slight: "It doesn't work". I'd like to ask: "prove it" if I dare ;) We are using it (in a very small environment, agreed) and it works quite well... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From aland@deployingradius.com Sun Aug 15 23:27:16 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86BA3A6961 for ; Sun, 15 Aug 2010 23:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.601 X-Spam-Level: X-Spam-Status: No, score=-101.601 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2RZ51CvKLd6 for ; Sun, 15 Aug 2010 23:27:15 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 6E7403A68AE for ; Sun, 15 Aug 2010 23:27:14 -0700 (PDT) Message-ID: <4C68DA64.1020002@deployingradius.com> Date: Mon, 16 Aug 2010 08:27:48 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "dime@ietf.org" References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C650C71.9020000@restena.lu> <000e01cb3c5d$7b8d1620$72a74260$@net> In-Reply-To: <000e01cb3c5d$7b8d1620$72a74260$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 06:27:17 -0000 Glen Zorn wrote: > I see. Where did the actually usable implementation of RADIUS over TCP come > from? Radiator, for quite a while now. Radsecproxy for quite a while. FreeRADIUS (~1 year, available only in "stable" branch of revision control). The TCP draft (draft-ietf-radext-tcp-transport) was first submitted in November 2008, well after the Radiator and Radsecproxy implementations had been written. Alan DeKok. From gwz@net-zen.net Mon Aug 16 02:13:20 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E100F3A698E for ; Mon, 16 Aug 2010 02:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.211 X-Spam-Level: X-Spam-Status: No, score=-101.211 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djuCbm7ZW0LO for ; Mon, 16 Aug 2010 02:13:17 -0700 (PDT) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 698703A6990 for ; Mon, 16 Aug 2010 02:13:17 -0700 (PDT) Received: (qmail 27650 invoked from network); 16 Aug 2010 09:13:52 -0000 Received: from unknown (124.157.141.92) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 16 Aug 2010 09:13:50 -0000 From: "Glen Zorn" To: "'Avi Lior'" , , , References: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> <02AE8F14-B61F-4EAF-8654-7B86F154A9C8@huawei.com> <1FD363A7-3530-4F5F-8F17-0B0A861C33D4@bridgewatersystems.com> In-Reply-To: <1FD363A7-3530-4F5F-8F17-0B0A861C33D4@bridgewatersystems.com> Date: Mon, 16 Aug 2010 16:13:27 +0700 Organization: Network Zen Message-ID: <000001cb3d23$4be946c0$e3bbd440$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CB3D5D.F8481EC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs5k8sSmWxQDaSsTlucWjLPA9MktwDju2YA Content-Language: en-us Subject: Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:13:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CB3D5D.F8481EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Avi Lior [mailto://avi@bridgewatersystems.com] writes: Hi, I have reviewed draft-ietf-dime-realm-based-redirect-03 document -- or I should say i started but I had to stop because there are serious fundamental issues with this draft. I should start with the fact that i think the problem statement raised by the draft is valid. Also, I think that Diameter base 3588 should have supported Realm based redirection as well as host based redirection. Actually Realm-based redirection are probably more useful. However, the problem I am having is that the draft is changing the semantics of a Redirect Agent as defined by base and I dont think that we should be allowed to do that. If the change in behavior is backward-compatible, why not? I get that the draft got around backwards capability issue surrounding the new AVPs be introduced by asserting that only new applications will support the attributes. But in order to deliver this feature in 3588 the behavior of the Redirect Agent had to change. This new redirect agent has to differentiate between applications that do support realm base redirection vs non-realmbased redirection. This is new base behavior and thus should be done in Diameter V2 There is an alternative - which i thought was the approach taken when i started to read the draft and that is: -let the Application itself perform the redirection. To use the example provided, if the operator does not want to host the application anymore, it can let the Application respond back with the realm and/host redirection attributes. ------=_NextPart_000_0001_01CB3D5D.F8481EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Avi Lior [mailto://avi@bri= dgewatersystems.com] writes:

 

Hi,

 

I have reviewed = draft-ietf-dime-realm-based-redirect-03 document -- or I should say i started but I had to stop because there = are serious fundamental issues with this draft.

 

I should start with the fact that i think the = problem statement raised by the draft is valid. Also, I think that Diameter base = 3588 should have supported Realm based redirection as well as host based redirection. Actually Realm-based redirection are probably more = useful.

 

However, the problem I am having is that the draft = is changing the semantics of a Redirect Agent as defined by base and I dont = think that we should be allowed to do that.

 

If the change in behavior is backward-compatible, why = not?

 

I get that the draft got around backwards = capability issue surrounding the new AVPs be introduced by asserting that only new = applications will support the attributes.

 

But in order to deliver this feature in 3588 the = behavior of the Redirect Agent had to change.

 

This new redirect agent has to differentiate = between applications that do support realm base redirection vs non-realmbased = redirection.

 

This is new base behavior and thus should be done = in Diameter V2

 

There is an alternative - which i thought was the = approach taken when i started to read the draft and that is:

 

-let the Application itself perform the = redirection.  To use the example provided, if the operator does not want to host = the application anymore, it can let the Application respond back with the = realm and/host redirection attributes.

------=_NextPart_000_0001_01CB3D5D.F8481EC0-- From stefan.winter@restena.lu Mon Aug 16 02:52:13 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F353A681B for ; Mon, 16 Aug 2010 02:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f2Xmz0DfZ1p for ; Mon, 16 Aug 2010 02:52:11 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECE4A3A681F for ; Mon, 16 Aug 2010 02:52:10 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4832210586; Mon, 16 Aug 2010 11:52:46 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 242E710584; Mon, 16 Aug 2010 11:52:46 +0200 (CEST) Message-ID: <4C690A6D.3010903@restena.lu> Date: Mon, 16 Aug 2010 11:52:45 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Glen Zorn References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <003201cb347a$0fb844a0$2f28cde0$@net> <4C650C71.9020000@restena.lu> <000e01cb3c5d$7b8d1620$72a74260$@net> In-Reply-To: <000e01cb3c5d$7b8d1620$72a74260$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:52:13 -0000 Hi, > I see. Where did the actually usable implementation of RADIUS over TCP come > from? That's a good question. Back in the day, I thought we might have been the trigger for the Radiator guys (since the prototype system existed before I joined the club), but after all I heard, it wasn't us. There were apparently actual clients requesting that feature. It did fit quite nicely into our requirements, though, and that's why we picked it up. >> More for the record: the first eduroam prototype was online June 2003; >> RFC3588 dates September 2003. Your definition of "long before" violates >> temporal continuity. > Of course, my mistake for not realizing that initial prototype == published > RFC. This has nothing to do with published RFCs. You said "Diameter existed long before EDUROAM " and I pointed out that you are wrong. Deployers of IETF standards don't usually have to announce themselves by writing an RFC describing their deployment, so I'm completely lost why you are talking of a "published RFC" here. >> If the end auth server is a pure RADIUS server, someone else has >> to do it for him. > Why (& how) would a Diameter message be delivered to a pure RADIUS server? That's the point: if one realm in the consortium only speaks RADIUS and some other device has wrapped RADIUS into Diameter with RADIA, then there needs to be another RADIA-supporting Diameter server somewhere in the path to do the unwrapping. Of course not the Diameter message needs to be delivered, but only the contents of the Radius-Message AVP, unwrapped and transformed into plain RADIUS. > The only element relevant to authentication/authorization in a RADIA message > is the encapsulated RADIUS message; any other Diameter AVPs that may be > present are only for transport purposes. There's a " * [ AVP ] " in the command definition of Radia-Req and -Answer. I had the impression that this enables one to send non-transport-related content. I may be wrong with that; am I? >> Even if unwrapping works, >> what if a (Diameter) auth server crafts a (Diameter) answer, with >> untranslatable attributes which can never be translated back to a RADIUS >> NAS? > Then the Diameter server in question is broken; nevertheless, what happens > if a NASREQ app server does the same thing today? Why would the Diameter server in question be broken? RFC4005 mentions that it is well possible that a Diameter crafts messages with untranslatable attributes. That's not brokenness; it is just something that might happen. The RFCs answer for oversized attributes, for example (which also answers your own question, above, is: "a Result-Code of DIAMETER_INVALID_AVP_LENGTH should be returned." >> If forwarded along multiple proxies, the wrapping entity would need >> signalling on whether there will be an entity along the line to unwrap >> the message at all. If there is none, the tunnel has no other end. >> Signalling of this along multiple hops is unspecified in your draft, if >> I'm not mistaken. > Because it's unnecessary; if there is no RADIA app server in the destination > realm, a standard "undeliverable message" error must be returned. That > point should be made in the draft. Into what does this error message get translated to the originating RADIUS NAS? I would guess into an Access-Reject? With a Reply-Message containing some hint that it wasn't actually the user's fault? Or a new RADIUS attribute to convey the error condition? Or should it just be silently discarded? Difficult to say if the draft doesn't specify any handling for such error conditions. >> I don't think your draft has answers to these questions. >> >> Anyway, the tunneling requires both ends of the tunnel to understand >> RADIUS. It is thus not a transition mechanism. > OK. How, then, is RFC 4005 (one-way) translation a transition mechanism? It is not. As I wrote earlier, the much more honest answer to the transition question is "It's not possible." > As I have pointed out many times, the end NASREQ server must understand how > to respond to the request in a translatable way That's not what RFC4005 says. In the above-quoted section 9.5 it is acknowledged that untranslatable attributes can occur. There is no "must understand how to respond to the request in a translatable way"in the RFC. If there were, it would be easier to build a deterministic transition path with it. In it's current state, the answer "it will often work, but sometimes it just won't" is not a satisfactory answer. Funny, 4005bis could have been used to make such a point; but instead, now the content gets purged in its entirety. But I'm happy either way. >> It's an alternative >> transport. And a not very useful one, IMHO. I acknowledge your point >> that there are apparently some organisations which have hardwired the >> use of Diameter in their specs, while actually wanting to speak RADIUS >> on some paths, and for these organisations, RADIUS disguised as Diameter >> is a tool they might need. > & is precisely what RADIA supplies, but w/o the overhead of "translation". And it may very well be good for this particular and narrow purpose. The Abstract and Intro make much higher and undue promises to the reader though. How about calling this "transporting RADIUS messages over Diameter routing". >> Your point "noone ever transitioned" is true; but for reasons of lack of >> options to do so. It's not exactly fair to blame the RFC for it. FWIW, >> if were to write about RADIUS<->Diameter translation, it would be one >> very short paragraph "This doesn't work." Note that I think that this >> sentence is necessary IMHO; merely not writing *anything* about the >> topic, because "noone ever used it", is not enough. You know, some >> people might be *curious* about the topic, and could be *told* that they >> need not look any further. > Lots of people are curious about lots of things... And if this curiosity originates from them using an SDO's spec, then it might be a good idea if the SDO supplies the answer to them. Greetings, Stefan Winter >> Greetings, >> >> Stefan Winter >> >>>> Best regards, >>>> Sebastien. >>>> >>>> -- >>>> Sebastien Decugis >>>> Research fellow >>>> Network Architecture Group >>>> NICT (nict.go.jp) >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From stefan.winter@restena.lu Mon Aug 16 03:09:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A5D3A681F for ; Mon, 16 Aug 2010 03:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDfscpxq0mlA for ; Mon, 16 Aug 2010 03:09:24 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id E65493A6803 for ; Mon, 16 Aug 2010 03:09:23 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 6F3D410586 for ; Mon, 16 Aug 2010 12:09:59 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5AF3910584 for ; Mon, 16 Aug 2010 12:09:59 +0200 (CEST) Message-ID: <4C690E77.7000806@restena.lu> Date: Mon, 16 Aug 2010 12:09:59 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: dime@ietf.org References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <4C5B69A9.601@nict.go.jp> <001401cb3c67$760f66d0$622e3470$@net> <4C689AC0.4010400@nict.go.jp> In-Reply-To: <4C689AC0.4010400@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 10:09:29 -0000 Hi, > I'd like to ask: "prove it" if I dare ;) We are using it (in a very > small environment, agreed) and it works quite well... It can translate back and forth in many cases, but not all. Example: at some point, your Diameter server wants to send Filter-Rule AVPs to restrict the client's access to some resources. The total length of all filter rules which the Diameter server adds to the reply is 4100 Bytes long. RADIUS messages can't exceed 4096 Bytes. Translation will fail. QED. :-) (BTW, I looked up whether RFC4005 discusses the 4096 bytes boundary, but Ctrl+F for "4096" didn't give any match at all. I assume it has to be somewhere... anyone care to hint me at the appropriate section?) Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From avi@bridgewatersystems.com Mon Aug 16 14:11:43 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095523A6AB9 for ; Mon, 16 Aug 2010 14:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGEdum1TpSXN for ; Mon, 16 Aug 2010 14:11:41 -0700 (PDT) Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with ESMTP id E38483A6AC6 for ; Mon, 16 Aug 2010 14:11:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-15.tower-200.messagelabs.com!1281993135!77460713!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 13471 invoked from network); 16 Aug 2010 21:12:16 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-15.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 16 Aug 2010 21:12:16 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Mon, 16 Aug 2010 17:12:15 -0400 From: Avi Lior To: Glen Zorn Date: Mon, 16 Aug 2010 17:12:13 -0400 Thread-Topic: [Dime] Review of draft-ietf-dime-realm-based-redirect-03 Thread-Index: Acs9h7L7fQ4frSo7SE275BlzcVuCew== Message-ID: <023B0737-0E8B-4A68-80ED-EC79767DFB92@bridgewatersystems.com> References: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> <02AE8F14-B61F-4EAF-8654-7B86F154A9C8@huawei.com> <1FD363A7-3530-4F5F-8F17-0B0A861C33D4@bridgewatersystems.com> <000001cb3d23$4be946c0$e3bbd440$@net> In-Reply-To: <000001cb3d23$4be946c0$e3bbd440$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: multipart/alternative; boundary="_000_023B07370E8B4A6880EDEC79767DFB92bridgewatersystemscom_" MIME-Version: 1.0 Cc: "draft-ietf-dime-realm-based-redirect@tools.ietf.org" , "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:11:43 -0000 --_000_023B07370E8B4A6880EDEC79767DFB92bridgewatersystemscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 16-08-2010, at 05:13 , Glen Zorn wrote: However, the problem I am having is that the draft is changing the semantic= s of a Redirect Agent as defined by base and I dont think that we should be= allowed to do that. If the change in behavior is backward-compatible, why not? Its not just sufficient to know that an added feature is backwards compatib= le. The "approach" taken in Diameter design is that the one entity knows the be= havior/capability of a particular another entity. If you simply add functi= onality to something how would I know that the new features that i want to = use are supported. Specifically, how do I know that when I forward a message to a Redirect Age= nt that I would be able to get realm-redirections. If I have two relay age= nts how would I know which one to use. We have to decide that we are okay with building functionality into entitie= s without having the ability to know whether those entities support those f= eatures. And if we are okay with that then that is great. The draft solves the problem one way -- it allows the Redirect Agent know = whether an Application can handle the new redirect attributes. How about t= he other way as well? Avi Lior avi@bridgewatersystems.com office: +1 613-591-9104x6417 cell: +1 613-796-4183 --_000_023B07370E8B4A6880EDEC79767DFB92bridgewatersystemscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On 16-08-201= 0, at 05:13 , Glen Zorn wrote:

However, the problem I am having is that the draft is changi= ng the semantics of a Redirect Agent as defined by base and I dont think th= at we should be allowed to do that.
 
If the change in behavio= r is backward-compatible, why not?
=  

Its n= ot just sufficient to know that an added feature is backwards compatible.

The "approach" taken in Diameter design is that the= one entity knows the behavior/capability of a particular another entity. &= nbsp;If you simply add functionality to something how would I know that the= new features that i want to use are supported.

Sp= ecifically, how do I know that when I forward a message to a Redirect Agent= that I would be able to get realm-redirections.  If I have two relay = agents how would I know which one to use. 

We= have to decide that we are okay with building functionality into entities = without having the ability to know whether those entities support those fea= tures.  And if we are okay with that then that is great.
 The draft solves the problem one way -- it allows the Redirect= Agent know whether an Application can handle the new redirect attributes. =  How about the other way as well?

off= ice: +1 613-591-9104x6417
   &n= bsp;cell: +1 613-796-4183

= --_000_023B07370E8B4A6880EDEC79767DFB92bridgewatersystemscom_-- From sdecugis@nict.go.jp Mon Aug 16 18:26:48 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1333A6781 for ; Mon, 16 Aug 2010 18:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w2L7pYLnKKX for ; Mon, 16 Aug 2010 18:26:47 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id BB9833A65A5 for ; Mon, 16 Aug 2010 18:26:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id ACE0727DD0 for ; Tue, 17 Aug 2010 03:27:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhgL8d7aPNki for ; Tue, 17 Aug 2010 03:27:17 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id E64ED27DCC for ; Tue, 17 Aug 2010 03:27:16 +0200 (CEST) Message-ID: <4C69E55D.7050100@nict.go.jp> Date: Tue, 17 Aug 2010 10:26:53 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: dime@ietf.org References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <4C5B69A9.601@nict.go.jp> <001401cb3c67$760f66d0$622e3470$@net> <4C689AC0.4010400@nict.go.jp> <4C690E77.7000806@restena.lu> In-Reply-To: <4C690E77.7000806@restena.lu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 01:26:49 -0000 > It can translate back and forth in many cases, but not all. Example: > at some point, your Diameter server wants to send Filter-Rule AVPs to > restrict the client's access to some resources. The total length of > all filter rules which the Diameter server adds to the reply is 4100 > Bytes long. RADIUS messages can't exceed 4096 Bytes. Translation will > fail. QED. :-) Thank you for the real-life example :) Anyway since the server receives an indication that RADIUS translation is happening (thanks to Origin-AAA-Protocol AVP) the server is (at least, should be) able to handle this situation in a not-too-ugly way. Put otherwise: if we are using pure RADIUS (or RADIA), we face the same problem to convey this Filter Rule. What is the solution in that case? Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From stefan.winter@restena.lu Tue Aug 17 03:39:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FB33A68DB for ; Tue, 17 Aug 2010 03:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt6CumCrgwdQ for ; Tue, 17 Aug 2010 03:39:36 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id 003763A681F for ; Tue, 17 Aug 2010 03:39:35 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C4B6010584 for ; Tue, 17 Aug 2010 12:40:05 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 312D410086 for ; Tue, 17 Aug 2010 12:40:05 +0200 (CEST) Message-ID: <4C6A6704.6080306@restena.lu> Date: Tue, 17 Aug 2010 12:40:04 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: dime@ietf.org References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <4C5B69A9.601@nict.go.jp> <001401cb3c67$760f66d0$622e3470$@net> <4C689AC0.4010400@nict.go.jp> <4C690E77.7000806@restena.lu> <4C69E55D.7050100@nict.go.jp> In-Reply-To: <4C69E55D.7050100@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 10:39:37 -0000 Hi, > Thank you for the real-life example :) > Anyway since the server receives an indication that RADIUS translation > is happening (thanks to Origin-AAA-Protocol AVP) the server is (at > least, should be) able to handle this situation in a not-too-ugly way. > Put otherwise: if we are using pure RADIUS (or RADIA), we face the same > problem to convey this Filter Rule. What is the solution in that case? There is none. In a RADIUS world, such complex filter rules can't exist (or at least, not be transmitted from server to client). In a Diameter world, they can; which is the source of the translation problem. Of course a Diameter server can act thoughtfully, check the Origin-AAA-Protocol, and craft less complex filter rules which don't fill 4096 Bytes for that retarded RADIUS NAS. It will lead to different permissions for the connecting end users though, depending on which NAS they connect to, which is at least confusing. Note also that even if that Diameter server manages to cram its Filter-Rule into say 3900 Byte, there is still the problem that on the end (back translation to RADIUS for the NAS), a new RADIUS packet is constructed, with an unknown number and unknown size of attributes besides the ones that the Diameter server had. The resulting RADIUS packet could then be beyond 4096 again, even if the home Diameter server paid attention. This creates these highly unsatisfying "sometimes, it just doesn't work" situations. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From lionel.morand@orange-ftgroup.com Tue Aug 17 03:42:08 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9A93A687C for ; Tue, 17 Aug 2010 03:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.073 X-Spam-Level: X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdkNdyMr2yW4 for ; Tue, 17 Aug 2010 03:42:07 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id C9E1C3A68DB for ; Tue, 17 Aug 2010 03:42:06 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 834926C0003; Tue, 17 Aug 2010 12:42:56 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 728EF6C0002; Tue, 17 Aug 2010 12:42:56 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Aug 2010 12:42:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3DF8.EA9F35F4" Date: Tue, 17 Aug 2010 12:42:40 +0200 Message-ID: In-Reply-To: <023B0737-0E8B-4A68-80ED-EC79767DFB92@bridgewatersystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-realm-based-redirect-03 Thread-Index: Acs9h7L7fQ4frSo7SE275BlzcVuCewAbhrRA References: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> <02AE8F14-B61F-4EAF-8654-7B86F154A9C8@huawei.com> <1FD363A7-3530-4F5F-8F17-0B0A861C33D4@bridgewatersystems.com> <000001cb3d23$4be946c0$e3bbd440$@net> <023B0737-0E8B-4A68-80ED-EC79767DFB92@bridgewatersystems.com> From: To: , X-OriginalArrivalTime: 17 Aug 2010 10:42:41.0022 (UTC) FILETIME=[EAC601E0:01CB3DF8] Cc: draft-ietf-dime-realm-based-redirect@tools.ietf.org, dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 10:42:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3DF8.EA9F35F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Avi, =20 If I'm correct, you are not sending a request TO a Redirect Agent but = you are receiving an answer FROM a Redirect Agent. Before receiving the answer with the Result-Code set to = DIAMETER_REDIRECT_INDICATION, the Diameter agent only knows that it is = sending the request to a Diameter agent advertizing the Relay = application, which could be a Relay or a Redirect agent. =20 Why should the request originator have to know the redirection mechanism = (host-based or Realm-based) supported by a possible redirect agent in = the path? Does it not have to rely only on the redirection information provided in = the answer to know where to resend the request? And if the request is for the Diameter X appl that supports the = Realm-based redirection, it will be able to handle the specific = realm-based info sent back by the Redirect Agent. =20 Regards, =20 Lionel =20 ________________________________ De : Avi Lior [mailto:avi@bridgewatersystems.com]=20 Envoy=E9 : lundi 16 ao=FBt 2010 23:12 =C0 : Glen Zorn Cc : dime@ietf.org; = draft-ietf-dime-realm-based-redirect@tools.ietf.org; = dime-chairs@tools.ietf.org Objet : Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03 =09 =09 On 16-08-2010, at 05:13 , Glen Zorn wrote: =09 However, the problem I am having is that the draft is changing the = semantics of a Redirect Agent as defined by base and I dont think that = we should be allowed to do that. =09 If the change in behavior is backward-compatible, why not? Its not just sufficient to know that an added feature is backwards = compatible. The "approach" taken in Diameter design is that the one entity knows = the behavior/capability of a particular another entity. If you simply = add functionality to something how would I know that the new features = that i want to use are supported. Specifically, how do I know that when I forward a message to a Redirect = Agent that I would be able to get realm-redirections. If I have two = relay agents how would I know which one to use.=20 We have to decide that we are okay with building functionality into = entities without having the ability to know whether those entities = support those features. And if we are okay with that then that is = great. The draft solves the problem one way -- it allows the Redirect Agent = know whether an Application can handle the new redirect attributes. How = about the other way as well? =09 =09 =09 Avi Lior avi@bridgewatersystems.com office: +1 613-591-9104x6417 cell: +1 613-796-4183 =09 =09 ------_=_NextPart_001_01CB3DF8.EA9F35F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Avi,
 
If I'm correct, you are not sending a request = TO a Redirect=20 Agent but you are receiving an answer FROM a Redirect = Agent.
Before receiving the answer with the = Result-Code set to=20 DIAMETER_REDIRECT_INDICATION, the Diameter agent only knows that it is = sending=20 the request to a Diameter agent advertizing the Relay application, which = could=20 be a Relay or a Redirect agent.
 
Why should the request originator have to know = the=20 redirection mechanism (host-based or Realm-based) supported by a = possible=20 redirect agent in the path?
Does it not have to rely only on the = redirection=20 information provided in the answer to know where to resend the=20 request?
And if the request is for the Diameter X appl = that supports=20 the Realm-based redirection, it will be able to handle the specific = realm-based=20 info sent back by the Redirect Agent.
 
Regards,
 
Lionel
 

De : Avi Lior=20 [mailto:avi@bridgewatersystems.com]
Envoy=E9 : lundi = 16 ao=FBt=20 2010 23:12
=C0 : Glen Zorn
Cc : = dime@ietf.org;=20 draft-ietf-dime-realm-based-redirect@tools.ietf.org;=20 dime-chairs@tools.ietf.org
Objet : Re: [Dime] Review of = draft-ietf-dime-realm-based-redirect-03


On 16-08-2010, at 05:13 , Glen Zorn wrote:
However,=20 the problem I am having is that the draft is changing the semantics = of a=20 Redirect Agent as defined by base and I dont think that we should be = allowed=20 to do that.
If=20 the change in behavior is backward-compatible, why=20 not?

Its not just sufficient to know that an added feature is = backwards=20 compatible.

The "approach" taken in Diameter design is that the one entity = knows the=20 behavior/capability of a particular another entity.  If you = simply add=20 functionality to something how would I know that the new features that = i want=20 to use are supported.

Specifically, how do I know that when I forward a message to a = Redirect=20 Agent that I would be able to get realm-redirections.  If I have = two=20 relay agents how would I know which one to use. 

We have to decide that we are okay with building functionality = into=20 entities without having the ability to know whether those entities = support=20 those features.  And if we are okay with that then that is = great.

 The draft solves the problem one way -- it allows = the=20 Redirect Agent know whether an Application can handle the new redirect = attributes.  How about the other way as well?

Avi=20 Lior
avi@bridgewatersystems.com=
office:=20 +1 613-591-9104x6417   =20  cell: +1=20 613-796-4183


------_=_NextPart_001_01CB3DF8.EA9F35F4-- From sdecugis@nict.go.jp Tue Aug 17 03:48:40 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D871E3A6866 for ; Tue, 17 Aug 2010 03:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy-BOGetg8p8 for ; Tue, 17 Aug 2010 03:48:40 -0700 (PDT) Received: from sd-11965.dedibox.fr (sd-11965.dedibox.fr [88.191.67.190]) by core3.amsl.com (Postfix) with ESMTP id D69363A6803 for ; Tue, 17 Aug 2010 03:48:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-11965.dedibox.fr (Postfix) with ESMTP id 01AFA27DD0 for ; Tue, 17 Aug 2010 12:49:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-11965.dedibox.fr Received: from sd-11965.dedibox.fr ([127.0.0.1]) by localhost (sd-11965.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RdNOJ5U3J8V for ; Tue, 17 Aug 2010 12:49:11 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-11965.dedibox.fr (Postfix) with ESMTPSA id D808C27DCE for ; Tue, 17 Aug 2010 12:49:10 +0200 (CEST) Message-ID: <4C6A6906.8010107@nict.go.jp> Date: Tue, 17 Aug 2010 19:48:38 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: dime@ietf.org References: <4C5A5F2D.20508@nict.go.jp> <001c01cb346e$d7f9a460$87eced20$@net> <4C5A6DA9.30309@nict.go.jp> <4C5B69A9.601@nict.go.jp> <001401cb3c67$760f66d0$622e3470$@net> <4C689AC0.4010400@nict.go.jp> <4C690E77.7000806@restena.lu> <4C69E55D.7050100@nict.go.jp> <4C6A6704.6080306@restena.lu> In-Reply-To: <4C6A6704.6080306@restena.lu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] WG adoption call for draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 10:48:41 -0000 Hi Stefan, > It will lead to different permissions for the connecting end users > though, depending on which NAS they connect to, which is at least > confusing. I see, thank you for the detailed explanation. But, I still believe that "works sometimes" is better than "never works" -- although it might be confusing and needs to be properly reported by implementations when the situation occurs. I guess it is a matter of taste here. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From jouni.nospam@gmail.com Thu Aug 19 01:14:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B013A68F0 for ; Thu, 19 Aug 2010 01:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1Pqa3TLMPx2 for ; Thu, 19 Aug 2010 01:14:33 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A93A13A682F for ; Thu, 19 Aug 2010 01:14:32 -0700 (PDT) Received: by wyb40 with SMTP id 40so1997835wyb.31 for ; Thu, 19 Aug 2010 01:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=jQXhGbuAvUQwsD6a7ojY+oslk9oEk4CVK6+aB289JWE=; b=MDClMH+CJxbDEGAUpPwh4CSiXVm02fnEl18p5vGPBCafF0pj5PM8fXqF8xWi60inqS 5TA2jLLpvBljHEAF4b7i/ehnV2kYjGy/cQLtNYjR/IcwTfkRiGCaflCPJ88w7h3jF08V JbefCXTXxmhMuQSCmocoiLTiT01/RAa6Q8J3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=sOAKHzpbqcmkZTPxjTbbwAC+sancT3Z8AibPzjbkRX2T1n26y+LF3tYYHjctktNPK9 X3/+/MQWvb3KGClUOvmNCihr6Y0Flypeq86gqEHfC0Ne8kp4jdE/Cvm1rg82+N/ZC3X4 sW108yHeW624plnbl+x3uo2pF5aN1PDw0Z5Yo= Received: by 10.227.158.15 with SMTP id d15mr8140761wbx.46.1282205707011; Thu, 19 Aug 2010 01:15:07 -0700 (PDT) Received: from [10.254.0.57] ([192.100.123.77]) by mx.google.com with ESMTPS id m25sm1114393wbc.1.2010.08.19.01.15.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 01:15:06 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Aug 2010 11:15:03 +0300 Message-Id: <2CCD8883-CC51-449E-AA2B-D3015F03DB7F@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] An Issue Tracker advise.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 08:14:34 -0000 Hi, When using the issue tracker for WGLC document, please remember to add = dime@ietf.org to issue ticket's CC field. Otherwise, tickets won't show = up in the list. (well.. some might find this actually good ;) - Jouni=20= From lionel.morand@orange-ftgroup.com Fri Aug 20 20:52:08 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6BA3A635F for ; Fri, 20 Aug 2010 20:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXJCoZ9DIZiU for ; Fri, 20 Aug 2010 20:52:07 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 104673A6968 for ; Fri, 20 Aug 2010 20:52:05 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F31CFC4016 for ; Sat, 21 Aug 2010 05:52:33 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 823D3FC4013 for ; Sat, 21 Aug 2010 05:52:33 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Aug 2010 05:52:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Aug 2010 05:52:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 Thread-Index: Acs9YoqZijH8AvN5TFC9jStjpvqjXQDgagqA From: To: X-OriginalArrivalTime: 21 Aug 2010 03:52:33.0406 (UTC) FILETIME=[4924C9E0:01CB40E4] Subject: [Dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 03:52:08 -0000 =20 #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 ----------------------------------------------+------------------------- ----------------------------------------------+---- Reporter: lionel.morand@... | Owner: =20 Type: defect | Status: new Priority: major | Milestone: =20 Component: ikev2-psk-diameter | Version: =20 Severity: In WG Last Call | Keywords: =20 ----------------------------------------------+------------------------- ----------------------------------------------+---- I have reviewed this draft and is pretty good for publication. One remaining open issue from my side: 1/Is there any need for Authorize-Type AVP in the request if only Authorize-Only is used in this application? Additional comments/proposed modifications below. Regards, Lionel. ****************** 1. Introduction [RFC4306] defines Internet Key Exchange v2 as a protocol that =3D=3D> s/[RFC4306] defines Internet Key Exchange v2 as a protocol = that/ [RFC4306] defines the version 2 of the Internet Key Exchange (IKE) protocol that performs mutual authentication between two parties and establishes a security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication Header (AH) [RFC4302], and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry. IKEv2 protocol allows several different mechanisms for authenticating a IKEv2 Peer to be used, such as the Extensible Authentication Protocol, certificates, and pre-shared secrets. From a service provider perspective it is important to ensure that a =3D=3D> s/From a service provider perspective it is/From a service = provider perspective, it is user is authorized to use the services. Therefore, the IKEv2 Server must verify that the IKEv2 Peer is authorized for the requested services possibly with the assistance of the operator's Diameter servers. [RFC 5778] defines the home agent as a Diameter client to the Diameter server communication when the mobile node authenticates using the IKEv2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. This document =3D=3D> s/the Extensible Authentication Protocol or using the Mobile = IPv6 Authentication Protocol/ the Extensible Authentication Protocol (EAP) [RFC 3748] or using the Mobile IPv6 Authentication Protocol [RFC 4285]/ extends the functionality offered by [RFC 5778] with pre-shared key based authentication offered by IKEv2. This document does not assume that the IKEv2 Server has the pre-shared secrets (PSK) with the IKEv2 Peer. Instead, it allows for PSK to be derived for a specific IKEv2 session and exchanged between IKEv2 Server and HAAA. This is accomplished through the use of a new Diameter application specifically designed for performing IKEv2 authorization decisions. [skip] 4. Protocol Description 4.1. Support for IKEv2 and Pre-Shared Secrets When IKEv2 is used with PSK-based initiator authentication, the Diameter commands IKEv2-PSK-Request and IKEv2-PSK-Answer defined in =3D=3D> s/the Diameter commands IKEv2-PSK-Request and IKEv2-PSK-Answer defined/ the Diameter command pair IKEv2-PSK-Request/Answer defined this document are used to authorize the IKEv2 Peer for the services. =3D=3D> s/are used to authorize/are used between IKEv2 server and a = Home AAA server (HAAA) to authorize Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2 Server uses the information received in IDi to determine if it has the PSK for this IKEv2 Peer. If there is no PSK found associated with this IKEv2 Peer, the IKEv2 Server MUST send an Authorize-Only (Auth-Request-Type set to "Authorize-Only") Diameter IKEv2-PSK message with the IKEv2 Peer's IDi payload to the HAAA to obtain the PSK. =3D=3D> I think that the initial intention was to re-use RFC5778 and existing commands. Now, as you're creating new command, why do you have to re-use Auth-Request-Type AVP as it seems that only "Authorize-Only" will be used in this application? If removed from the command, this part will be modified. The IDi payload extracted from the IKE_AUTH message has to =3D=3D> s/has to/MUST contain an identity that is meaningful for the Diameter infrastructure, such as a Network Access Identifier (NAI), since it is used by the IKEv2 Server to populate the User-Name AVP in the Diameter message. The IKEv2 Server also includes in the IKEv2-Nonces AVP of the same Diameter message the initiator and responder nonces (Ni and Nr) exchanged during initial IKEv2 exchange. This message is routed to the IKEv2 Peer's HAAA. Upon receiving Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA SHALL use the User-Name AVP to retrieve the associated keying material. The HAAA SHALL use the nonces Ni and Nr received in IKEv2- Nonces AVP to generate the PSK. It is outside of scope of this document how the HAAA obtains or generates the PSK. For example, if the HAAA previously performed EAP based access authentication and authorization of the IKEv2 Peer, it can use the available EMSK to generate the PSK [RFC5295]. The HAAA returns the PSK to the IKEv2 Server using the Key AVP as specified in [I-D.ietf-dime-local-keytran]. =3D=3D> I would reorder the end of this paragraph and move the "it is outside of scope..." at the end. It would look like: "This message is routed to the IKEv2 Peer's HAAA. Upon receiving Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA SHALL use the User-Name AVP to retrieve the associated keying material. The HAAA SHALL use the nonces Ni and Nr received in IKEv2- Nonces AVP to generate the PSK. The HAAA returns the PSK to the IKEv2 Server using the Key AVP as specified in [I-D.ietf-dime-local-keytran]. It is outside of scope of this document how the HAAA obtains or generates the PSK. For example, if the HAAA previously performed EAP based access authentication and authorization of the IKEv2 Peer, it can use the available EMSK to generate the PSK [RFC5295]." [skip] 4.2.2. AbortSession-Request =3D=3D> AbortSession/Abort-Session The Abort-Session-Request (ASR) message [RFC3588] is sent by the HAAA to the IKEv2 Server to terminate the authorized session. When the IKEv2 Server receives the ASR message, it MUST delete the corresponding IKE_SA and all CHILD_SAs set up through it. The Abort-Session-Answer (ASA) message [RFC3588] is sent by the IKEv2 Server in response to an ASR message. [skip] 5.1. IKEv2-PSK-Request (IKEPSKR) Command The IKEv2-PSK-Request message, indicated with the Command-Code set to TBD2 and the 'R' bit set in the Command Flags field is sent from the IKEv2 Server to the HAAA to initiate IKEv2 with PSK authorization. In this case, the Application-ID field of the Diameter Header MUST be set to the Diameter IKE PSK Application ID (value of TDB1). Message format ::=3D < Diameter Header: TBD2, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] [ NAS-Identifier ] [ NAS-IP-Address ] [ NAS-IPv6-Address ] [ NAS-Port ] [ Origin-State-Id ] { User-Name } [ Auth-Session-State ] { IKEv2-Nonces } * [ Proxy-Info ] * [ Route-Record ] ... * [ AVP ] IKEv2-PSK-Request message MUST include a IKEv2-Nonces AVP containing Ni and Nr nonces exchanged during initial IKEv2 exchange. =3D=3D> Check if the use of Auth-Request-Type AVp is really needed. If = not, remove it. =3D=3D> Why do we have to insist on the presence of IKEv2-Nonces AVP as this AVP is described as required in the ABNF? =3D=3D> In the AVP Occurence table, Key AVP can be found in the request while this AVP is missing in the ABNF description. inconsistency must fixed. Moreover, if Key AVP can be found in the request, add some text to explain why. [skip] 7. AVP Occurrence Tables The following tables present the AVPs defined or used in this document and their occurrences in Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. The table uses the following symbols: 0: The AVP MUST NOT be present in the message. 0+: Zero or more instances of the AVP MAY be present in the message. 0-1: Zero or one instance of the AVP MAY be present in the message. 1: One instance of the AVP MUST be present in the message. +-------------------+ | Command-Code | |---------+---------+ AVP Name | IKEPSKR | IKEPSKA | -------------------------------|---------+---------+ Key | 0-1 | 0-1 | IKEv2-Nonces | 0-1 | 0 | +---------+---------+ IKEPSKR and IKEPSKA Commands AVP Table =3D=3D> Inconsistency! IKEv2-Nonces is described are required in the Request and the Occurence is then 1. Moreover, the use of Key AVP in the request is not described, neither in the text nor in the request ABNF description. [skip] 11.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008. =3D=3D> an informative reference to RFC 4285 should be added (cf. = previous comment) -- Ticket URL: dime From lionel.morand@orange-ftgroup.com Fri Aug 20 20:53:08 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050323A6781 for ; Fri, 20 Aug 2010 20:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.835 X-Spam-Level: X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhd6HqdlWkEe for ; Fri, 20 Aug 2010 20:53:07 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id AFA183A635F for ; Fri, 20 Aug 2010 20:53:06 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DCE09768009 for ; Sat, 21 Aug 2010 05:56:25 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id CB946768008 for ; Sat, 21 Aug 2010 05:56:25 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Aug 2010 05:53:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Aug 2010 05:53:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent Thread-Index: Acs5+DNGJcrHMeZRQludAQSkE/zi4wG7C0mA From: To: X-OriginalArrivalTime: 21 Aug 2010 03:53:40.0454 (UTC) FILETIME=[711B8060:01CB40E4] Subject: [Dime] #6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 03:53:08 -0000 #6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent ----------------------------------------------+------------------------- ----------------------------------------------+---- Reporter: lionel.morand@... | Owner: =20 Type: defect | Status: new Priority: major | Milestone: =20 Component: realm-based-redirect | Version: =20 Severity: In WG Last Call | Keywords: =20 ----------------------------------------------+------------------------- ----------------------------------------------+---- I have reviewed draft-ietf-dime-realm-based-redirect-03 document -- or I should say i started but I had to stop because there are serious fundamental issues with this draft. I should start with the fact that i think the problem statement raised by the draft is valid. Also, I think that Diameter base 3588 should have supported Realm based redirection as well as host based redirection. Actually Realm-based redirection are probably more useful. However, the problem I am having is that the draft is changing the semantics of a Redirect Agent as defined by base and I dont think that we should be allowed to do that. I get that the draft got around backwards capability issue surrounding the new AVPs be introduced by asserting that only new applications will support the attributes. But in order to deliver this feature in 3588 the behavior of the Redirect Agent had to change. This new redirect agent has to differentiate between applications that do support realm base redirection vs non-realmbased redirection. This is new base behavior and thus should be done in Diameter V2 There is an alternative - which i thought was the approach taken when i started to read the draft and that is: -let the Application itself perform the redirection. To use the example provided, if the operator does not want to host the application anymore, it can let the Application respond back with the realm and/host redirection attributes. -- Ticket URL: dime From lionel.morand@orange-ftgroup.com Fri Aug 20 20:53:43 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8303A68DF for ; Fri, 20 Aug 2010 20:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.04 X-Spam-Level: X-Spam-Status: No, score=-101.04 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ-X3-XWznkm for ; Fri, 20 Aug 2010 20:53:43 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id B4A043A635F for ; Fri, 20 Aug 2010 20:53:42 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CE8DEFC4016 for ; Sat, 21 Aug 2010 05:54:16 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C5D3DFC4013 for ; Sat, 21 Aug 2010 05:54:16 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Aug 2010 05:54:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Aug 2010 05:54:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #4: Review from Sebastien Decugis Thread-Index: Acs1PUN9KlUE1QWfRzyieycj4q16wgLpzYMQ From: To: X-OriginalArrivalTime: 21 Aug 2010 03:54:16.0814 (UTC) FILETIME=[86C798E0:01CB40E4] Subject: [Dime] #4: Review from Sebastien Decugis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 03:53:44 -0000 #4: Review from Sebastien Decugis ----------------------------------------------+------------------------- ----------------------------------------------+---- Reporter: lionel.morand@... | Owner: =20 Type: enhancement | Status: new Priority: major | Milestone: =20 Component: realm-based-redirect | Version: =20 Severity: In WG Last Call | Keywords: =20 ----------------------------------------------+------------------------- ----------------------------------------------+---- Bellow are my comments on this document. I believe there are a few points that would deserve to be clarified in the document, but nothing blocking the next steps. 1) (3.1.1) second list item (editorial): Furthermore, the redirect agent MUST a Redirect-Realm AVP ^^^ missing word? 2) (3.1.1) What if the the other peer advertised the Relay application? =3D=3D> Should the redirect agent consider that it supports the Redirect-Realm application? 3) (3.1.1) "the message MUST include the Error- Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP," =3D=3D> IIUC this is an impossible situation, since the Redirect Agent = did not forward the Request. I believe this text could be removed for clarity. 4) (3.1.2) =3D=3D> What if the original request contains a Destination-Host AVP? In that case, should a UNABLE_TO_DELIVER error be returned? There is probably no point in sending to the alternate realm with a Destination-Host in the previous realm, right? Unless maybe if the Destination-Realm of the request message does not match the Origin-Realm of the Redirect indication (change of broker for example). Any opinion? 5) (3.2) =3D=3D> This section does not give the value of the M flag for the new = AVP. By the semantics of the application, I believe the M flag should be set, right? -- Ticket URL: dime From lionel.morand@orange-ftgroup.com Fri Aug 20 20:54:16 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC7D3A6991 for ; Fri, 20 Aug 2010 20:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.012 X-Spam-Level: X-Spam-Status: No, score=-102.012 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09EPYK9B5r1r for ; Fri, 20 Aug 2010 20:54:15 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id A4DA33A6781 for ; Fri, 20 Aug 2010 20:54:15 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 356DE57C2C1 for ; Sat, 21 Aug 2010 05:55:05 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2CC7557C2BC for ; Sat, 21 Aug 2010 05:55:05 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Aug 2010 05:54:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Aug 2010 05:54:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #3: Missing interface in figure 4 Thread-Index: AcszE9j9DkApzjKjRAKWylj0k5RFFAN0LM7Q From: To: X-OriginalArrivalTime: 21 Aug 2010 03:54:49.0937 (UTC) FILETIME=[9A85C410:01CB40E4] Subject: [Dime] #3: Missing interface in figure 4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 03:54:16 -0000 #3: Missing interface in figure 4 ----------------------------------------------+------------------------- ----------------------------------------------+---- Reporter: lionel.morand@... | Owner: =20 Type: defect | Status: new Priority: minor | Milestone: =20 Component: nat-control | Version: =20 Severity: In WG Last Call | Keywords: =20 ----------------------------------------------+------------------------- ----------------------------------------------+---- In the figure 4, the DNCA Manager is in the AAA server and the DNCA Agent is in the NAT. There is therefore an interface between the AAA and the NAT to support the DNC application. But this interface is not illustrated in the figure. It should be added. -- Ticket URL: dime From lionel.morand@orange-ftgroup.com Fri Aug 20 20:54:53 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003A33A6781 for ; Fri, 20 Aug 2010 20:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.881 X-Spam-Level: X-Spam-Status: No, score=-102.881 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSLvCOkjBzEC for ; Fri, 20 Aug 2010 20:54:52 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 0B0593A635F for ; Fri, 20 Aug 2010 20:54:52 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 75AB0768008 for ; Sat, 21 Aug 2010 05:58:11 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 706A5768007 for ; Sat, 21 Aug 2010 05:58:11 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Aug 2010 05:55:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Aug 2010 05:55:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: #2: IPv4-only hosts in Fig 2, 3, 4 Thread-Index: AcszE0FqCH8jFyvySraTLyz8gxnAiAN0WEuQ From: To: X-OriginalArrivalTime: 21 Aug 2010 03:55:26.0625 (UTC) FILETIME=[B063E910:01CB40E4] Subject: [Dime] #2: IPv4-only hosts in Fig 2, 3, 4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 03:54:53 -0000 =20 #2: IPv4-only hosts in Fig 2, 3, 4 ----------------------------------------------+------------------------- ----------------------------------------------+---- Reporter: lionel.morand@... | Owner: =20 Type: defect | Status: new Priority: minor | Milestone: =20 Component: nat-control | Version: =20 Severity: In WG Last Call | Keywords: =20 ----------------------------------------------+------------------------- ----------------------------------------------+---- In figures 2, 3 and 5, only IPv4 hosts are described whereas hosts can be IPv4, IPv6 or IPv4/IPv6. Figures should be updated to clarify this point. -- Ticket URL: dime From violeta.cakulev@alcatel-lucent.com Tue Aug 24 10:22:03 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E752A3A6B8C for ; Tue, 24 Aug 2010 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbwbzMljYJUF for ; Tue, 24 Aug 2010 10:22:02 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 61D1B3A6358 for ; Tue, 24 Aug 2010 10:22:02 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o7OHMYVi002956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Aug 2010 12:22:34 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o7OHMXCE010516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Aug 2010 12:22:34 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 24 Aug 2010 12:22:33 -0500 From: "Cakulev, Violeta (Violeta)" To: Sebastien Decugis , "dime@ietf.org" Date: Tue, 24 Aug 2010 12:22:31 -0500 Thread-Topic: [Dime] Comments on draft-ietf-dime-ikev2-psk-diameter-02 Thread-Index: Acs0dyvsOWlQegCATset/6nZotLIwgPOOWDA Message-ID: References: <4C5A7463.2080603@nict.go.jp> In-Reply-To: <4C5A7463.2080603@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [Dime] Comments on draft-ietf-dime-ikev2-psk-diameter-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 17:22:04 -0000 Sebastien, Thanks for your comments. Please see the responses inline. -Violeta -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Seb= astien Decugis Sent: Thursday, August 05, 2010 4:21 AM To: dime@ietf.org Subject: [Dime] Comments on draft-ietf-dime-ikev2-psk-diameter-02 Here are my comments on this document. They are only cosmetics. I think the= document is ready to be moved forward. 1) What is the purpose of including the Auth-Request-Type AVP in the IKEv2-= PSK-Request, since its value is constrained? >>VC: I agree, today this value is constrained and probably not necessary, = but it may change tomorrow. In addition, it is better to be explicit then i= mplicit. So I propose to leave it as it is. 2) Security section: This section refers to Master-Security-Association AVP= , which is not defined (I believe Key AVP is intended). >>VC: Fixed. I also believe the second paragraph does not belong to this specification, = but rather to I-D.ietf-dime-local-keytran. However, it does not harm as a r= eminder. >>VC: I agree with both of your points. It probably does not belong here, b= ut it also does not harm, therefore I did not make any change. 3) The reference section points to I-D.ietf-dime-local-keytran in version -= 01 but the -06 is the latest, maybe an update would be useful. >>VC: Yes, we need to upload a new version. That's all I have. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Wed Aug 25 19:00:20 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248C43A6953 for ; Wed, 25 Aug 2010 19:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm+JAhVbvs74 for ; Wed, 25 Aug 2010 19:00:19 -0700 (PDT) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id ED8783A6900 for ; Wed, 25 Aug 2010 19:00:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id E02AA9469B for ; Thu, 26 Aug 2010 04:00:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSga6gmpxXDm for ; Thu, 26 Aug 2010 04:00:47 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 6F95794693 for ; Thu, 26 Aug 2010 04:00:46 +0200 (CEST) Message-ID: <4C75CAAF.3040907@nict.go.jp> Date: Thu, 26 Aug 2010 11:00:15 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] RFC4005 - Tunneling AVP ABNF question X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 02:00:20 -0000 Hello, In section 7.1 of RFC4005, the ABNF for the Tunneling AVP mark as "required" the following attributes: Tunnel-Type, Tunnel-Medium-Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint. While I understand that in an answer all these attributes may be required, I think that in a request, used as a hint from the NAS, all attributes are not necessarily present in the message. I think therefore that the ABNF should be relaxed. Do you have any opinion on this? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From root@core3.amsl.com Thu Aug 26 05:45:01 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B52CF3A6ADF; Thu, 26 Aug 2010 05:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100826124501.B52CF3A6ADF@core3.amsl.com> Date: Thu, 26 Aug 2010 05:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-24.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 12:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-24.txt Pages : 158 Date : 2010-08-26 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-24.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-26054023.I-D@ietf.org> --NextPart-- From Hannes.Tschofenig@gmx.net Fri Aug 27 11:47:06 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6553A6A89 for ; Fri, 27 Aug 2010 11:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19WqYwq+IHEp for ; Fri, 27 Aug 2010 11:47:03 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id F2C323A69E9 for ; Fri, 27 Aug 2010 11:47:02 -0700 (PDT) Received: (qmail 3996 invoked by uid 0); 27 Aug 2010 18:47:33 -0000 Received: from 88.115.222.204 by rms-de011.v300.gmx.net with HTTP Content-Type: multipart/alternative; boundary="========GMXBoundary226831282934852838659" Date: Fri, 27 Aug 2010 20:44:52 +0200 From: "Hannes Tschofenig" Message-ID: <20100827184732.226830@gmx.net> MIME-Version: 1.0 To: "Sebastien Decugis" , "dime@ietf.org"@core3.amsl.com, X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 X-GMX-UID: fTBOBdMfQEV/AsRVq3RpfUtCNzg2NYIV X-FuHaFi: 0.55000000000000004,0.55000000000000004 Subject: Re: [Dime] freeDiameter 1.0.0 released X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:47:06 -0000 --========GMXBoundary226831282934852838659 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Sebastien, I just wanted to say how happy I am about this open source version of Diameter. At the time when your announcement was sent to the list I was sitting in the AAA doctors team lunch meeting at the IETF #78 and spoke about the need to have more running code and other things one should be doing in the DIME/RADEXT working group beyond just writing specifications. I hope that folks in the group will use your Diameter implementation to write their specification as an extension so that we can be more confident about the quality of our work. Although I have not yet looked at the code you have produced I was wondering how easy/difficult it would be to let your code to interact with some of the FreeRADIUS code. FreeRADIUS is quite strong in the interworking with backend databases and you ideally want to have that as well. Have you thought about this issue of integrating the freeDiameter in an existing IT infrastructure? Ciao Hannes PS: Sorry for my late response. ----- Ursprüngliche Nachricht ----- Von: Sebastien Decugis Gesendet: 29.07.10 13:08 Uhr An: dime@ietf.org Betreff: [Dime] freeDiameter 1.0.0 released Dear DiME members, It is my pleasure to announce the first release of freeDiameter, a new open-source implementation of the Diameter protocol. freeDiameter is released under the BSD license. It is written in C, and should run on any modern POSIX system (tested on GNU/Linux and FreeBSD). freeDiameter is designed as a framework: a daemon handles the Diameter Base Protocol operations (network management, messages routing) common to all Diameter nodes, while extensions provide the additional Diameter applications logic to each peer. The daemon is fully compliant to RFC3588 and draft-ietf-dime-rfc3588bis-21, including native support for IPv6, SCTP, and TLS. In this first release, the following extensions are available: - A Diameter EAP server implementation (RFC4072) with support for EAP TLS and MD5 methods (additional methods to be added later). - A Diameter SIP server implementation (RFC4740) -- experimental. - A RADIUS/Diameter translation gateway with support for NASREQ (RFC40 05), EAP (RFC4072), SIP (RFC4740) and Accounting (RFC3588) applications. - A simple Diameter Accounting (RFC3588) implementation. freeDiameter also comes with a set of debug tools and mechanisms that may be handy to anyone involved with Diameter. For more information and download information, please visit the freeDiameter homepage at http://www.freediameter.net Thank you, The freeDiameter team. (supported by NICT and Teraoka-Lab., Keio University) -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --========GMXBoundary226831282934852838659 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I carefully went through the draft document "Diameter IKEv2 PSK: = Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interac= tion" (draft-ietf-dime-ikev2-psk-diameter-02.txt) and I have no commen= ts.
 
Regards,
Ioannis
 
 
 
 
 
  --_000_1E28A1093117114BB6E6066F66BAFCD5058574206BUSNAVSXCHMBSB_-- From lionel.morand@orange-ftgroup.com Mon Aug 30 18:32:31 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE15D3A6A1F for ; Mon, 30 Aug 2010 18:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.852 X-Spam-Level: X-Spam-Status: No, score=-102.852 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QiKcqbn3B96 for ; Mon, 30 Aug 2010 18:32:27 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 433EA3A68CF for ; Mon, 30 Aug 2010 18:32:26 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1BD3C798002; Tue, 31 Aug 2010 03:35:53 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 12C08760003; Tue, 31 Aug 2010 03:35:53 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Aug 2010 03:32:56 +0200 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, 31 Aug 2010 03:32:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 Thread-Index: Acs9YooxKq4wX5tRRC+T0JyNnhCMaQBsfJWAAmXEKBA= References: <074.fd1143ff15296cc8707a663a09a095ab@tools.ietf.org> From: To: , X-OriginalArrivalTime: 31 Aug 2010 01:32:56.0460 (UTC) FILETIME=[7039C4C0:01CB48AC] Subject: Re: [Dime] [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 01:32:31 -0000 Hi Violeta, Thank you for having taken into account my comments. About the Auth-Request-AVP, no problem for me to state that = AUTHORIZE-ONLY is the unique value to use. However, this AVP is defined in RFC3588, and is defined with the = following possible values: AUTHENTICATE_ONLY 1 The request being sent is for authentication only, and MUST contain the relevant application specific authentication AVPs that are needed by the Diameter server to authenticate the user. AUTHORIZE_ONLY 2 The request being sent is for authorization only, and MUST contain the application specific authorization AVPs that are necessary to identify the service being requested/offered. AUTHORIZE_AUTHENTICATE 3=20 What should be the behaviour of the receiver if the Auth-Request-Type = AVP is set to the value 1 or 3, which are valid values? What is the = error code send back to the sender? Regards, Lionel > -----Message d'origine----- > De : Cakulev, Violeta (Violeta)=20 > [mailto:violeta.cakulev@alcatel-lucent.com]=20 > Envoy=E9 : lundi 30 ao=FBt 2010 22:14 > =C0 : dime@ietf.org; MORAND Lionel RD-CORE-ISS > Objet : RE: [dime] #12: Review of=20 > draft-ietf-dime-ikev2-psk-diameter-02 >=20 >=20 > Lionel, > Thanks for the comments. > Please see inline (>>[VC]). >=20 > I'll upload a new version (v3) of the draft shortly. >=20 > -Violeta >=20 > -----Original Message----- > From: dime issue tracker [mailto:trac@tools.ietf.org] > Sent: Monday, August 16, 2010 12:46 PM > To: lionel.morand@orange-ftgroup.com > Cc: dime@ietf.org; Cakulev, Violeta (Violeta) > Subject: [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 >=20 > #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 > ----------------------------------------------+--------------- > ---------- > ----------------------------------------------+---- > Reporter: lionel.morand@... | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: ikev2-psk-diameter | Version: > Severity: In WG Last Call | Keywords: > ----------------------------------------------+--------------- > ---------- > ----------------------------------------------+---- > I have reviewed this draft and is pretty good for publication. >=20 > One remaining open issue from my side: >=20 > 1/Is there any need for Authorize-Type AVP in the request if=20 > only Authorize-Only is used in this application? > >>[VC] Please see my response to Sebastien. In short, today=20 > this value is constrained and probably not necessary, but in=20 > future it may change. In addition, it is better to be explicit. >=20 > Additional comments/proposed modifications below. >=20 > Regards, >=20 > Lionel. >=20 > ****************** >=20 >=20 >=20 > 1. Introduction >=20 > [RFC4306] defines Internet Key Exchange v2 as a protocol that >=20 > =3D=3D> s/[RFC4306] defines Internet Key Exchange v2 as a protocol = that/ > [RFC4306] defines the version 2 of the Internet Key=20 > Exchange (IKE) protocol that > >>[VC] Changed. >=20 > performs mutual authentication between two parties and=20 > establishes a > security association (SA) that includes shared secret information > that can be used to efficiently establish SAs for Encapsulating > Security Payload (ESP) [RFC4303] and/or Authentication Header (AH) > [RFC4302], and a set of cryptographic algorithms to be used by the > SAs to protect the traffic that they carry. IKEv2 protocol allows > several different mechanisms for authenticating a IKEv2 Peer to be > used, such as the Extensible Authentication Protocol,=20 > certificates, > and pre-shared secrets. >=20 > From a service provider perspective it is important to=20 > ensure that a >=20 > =3D=3D> s/From a service provider perspective it is/From a=20 > service provider perspective, it is > >>[VC] Changed. >=20 > user is authorized to use the services. Therefore, the=20 > IKEv2 Server > must verify that the IKEv2 Peer is authorized for the requested > services possibly with the assistance of the operator's Diameter > servers. [RFC 5778] defines the home agent as a Diameter=20 > client to > the Diameter server communication when the mobile node=20 > authenticates > using the IKEv2 protocol with the Extensible=20 > Authentication Protocol > or using the Mobile IPv6 Authentication Protocol. This document >=20 > =3D=3D> s/the Extensible Authentication Protocol or using the=20 > Mobile IPv6 Authentication Protocol/ > the Extensible Authentication Protocol (EAP) [RFC=20 > 3748] or using the Mobile IPv6 Authentication Protocol [RFC 4285]/ > >>[VC] Changed. >=20 > extends the functionality offered by [RFC 5778] with=20 > pre-shared key > based authentication offered by IKEv2. This document=20 > does not assume > that the IKEv2 Server has the pre-shared secrets (PSK)=20 > with the IKEv2 > Peer. Instead, it allows for PSK to be derived for a=20 > specific IKEv2 > session and exchanged between IKEv2 Server and HAAA. This is > accomplished through the use of a new Diameter application > specifically designed for performing IKEv2 authorization=20 > decisions. >=20 >=20 > [skip] >=20 >=20 > 4. Protocol Description >=20 > 4.1. Support for IKEv2 and Pre-Shared Secrets >=20 > When IKEv2 is used with PSK-based initiator authentication, the > Diameter commands IKEv2-PSK-Request and IKEv2-PSK-Answer=20 > defined in >=20 > =3D=3D> s/the Diameter commands IKEv2-PSK-Request and=20 > IKEv2-PSK-Answer defined/ > the Diameter command pair IKEv2-PSK-Request/Answer defined > >>[VC] Changed. >=20 > this document are used to authorize the IKEv2 Peer for=20 > the services. >=20 > =3D=3D> s/are used to authorize/are used between IKEv2 server=20 > and a Home AAA server (HAAA) to authorize > >>[VC] Changed. >=20 >=20 > Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2 > Server uses the information received in IDi to determine if it has > the PSK for this IKEv2 Peer. If there is no PSK found associated > with this IKEv2 Peer, the IKEv2 Server MUST send an Authorize-Only > (Auth-Request-Type set to "Authorize-Only") Diameter IKEv2-PSK > message with the IKEv2 Peer's IDi payload to the HAAA to=20 > obtain the > PSK. >=20 > =3D=3D> I think that the initial intention was to re-use RFC5778=20 > and existing commands. Now, as you're creating new command,=20 > why do you have to re-use Auth-Request-Type AVP as it seems=20 > that only "Authorize-Only" will be used in this application?=20 > If removed from the command, this part will be modified. > >>[VC] Discussed above. >=20 > The IDi payload extracted from the IKE_AUTH message has to >=20 > =3D=3D> s/has to/MUST > >>[VC] Changed. >=20 > contain an identity that is meaningful for the Diameter > infrastructure, such as a Network Access Identifier=20 > (NAI), since it > is used by the IKEv2 Server to populate the User-Name AVP in the > Diameter message. The IKEv2 Server also includes in the=20 > IKEv2-Nonces > AVP of the same Diameter message the initiator and=20 > responder nonces > (Ni and Nr) exchanged during initial IKEv2 exchange. >=20 > This message is routed to the IKEv2 Peer's HAAA. Upon receiving > Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA > SHALL use the User-Name AVP to retrieve the associated keying > material. The HAAA SHALL use the nonces Ni and Nr=20 > received in IKEv2- > Nonces AVP to generate the PSK. It is outside of scope of this > document how the HAAA obtains or generates the PSK. For=20 > example, if > the HAAA previously performed EAP based access authentication and > authorization of the IKEv2 Peer, it can use the available EMSK to > generate the PSK [RFC5295]. The HAAA returns the PSK to the IKEv2 > Server using the Key AVP as specified in > [I-D.ietf-dime-local-keytran]. >=20 > =3D=3D> I would reorder the end of this paragraph and move the=20 > "it is outside of scope..." at the end. It would look like: >=20 > "This message is routed to the IKEv2 Peer's HAAA. Upon receiving > Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA > SHALL use the User-Name AVP to retrieve the associated keying > material. The HAAA SHALL use the nonces Ni and Nr=20 > received in IKEv2- > Nonces AVP to generate the PSK. The HAAA returns the PSK=20 > to the IKEv2 > Server using the Key AVP as specified in > [I-D.ietf-dime-local-keytran]. >=20 > It is outside of scope of this document how the HAAA obtains or > generates the PSK. For example, if the HAAA previously=20 > performed EAP > based access authentication and authorization of the=20 > IKEv2 Peer, it > can use the available EMSK to generate the PSK [RFC5295]." >=20 > >>[VC] Reordered. >=20 > [skip] >=20 >=20 > 4.2.2. AbortSession-Request >=20 > =3D=3D> AbortSession/Abort-Session > >>[VC] Changed. >=20 > The Abort-Session-Request (ASR) message [RFC3588] is sent=20 > by the HAAA > to the IKEv2 Server to terminate the authorized session. When the > IKEv2 Server receives the ASR message, it MUST delete the > corresponding IKE_SA and all CHILD_SAs set up through it. >=20 > The Abort-Session-Answer (ASA) message [RFC3588] is sent=20 > by the IKEv2 > Server in response to an ASR message. >=20 >=20 > [skip] >=20 >=20 > 5.1. IKEv2-PSK-Request (IKEPSKR) Command >=20 > The IKEv2-PSK-Request message, indicated with the=20 > Command-Code set to > TBD2 and the 'R' bit set in the Command Flags field is=20 > sent from the > IKEv2 Server to the HAAA to initiate IKEv2 with PSK authorization. > In this case, the Application-ID field of the Diameter=20 > Header MUST be > set to the Diameter IKE PSK Application ID (value of TDB1). >=20 > Message format >=20 >=20 > ::=3D < Diameter Header: TBD2, REQ, PXY = > > < Session-Id > > { Auth-Application-Id } > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Auth-Request-Type } > [ Destination-Host ] > [ NAS-Identifier ] > [ NAS-IP-Address ] > [ NAS-IPv6-Address ] > [ NAS-Port ] > [ Origin-State-Id ] > { User-Name } > [ Auth-Session-State ] > { IKEv2-Nonces } > * [ Proxy-Info ] > * [ Route-Record ] > ... > * [ AVP ] >=20 > IKEv2-PSK-Request message MUST include a IKEv2-Nonces AVP=20 > containing > Ni and Nr nonces exchanged during initial IKEv2 exchange. >=20 > =3D=3D> Check if the use of Auth-Request-Type AVp is really=20 > needed. If not, remove it. > >>[VC] Discussed above. >=20 > =3D=3D> Why do we have to insist on the presence of IKEv2-Nonces=20 > AVP as this AVP is described as required in the ABNF? > >>[VC] Makes sense. However, focus was more on the fact that=20 > those are the nonces exchanged between the peer and the=20 > server in IKE messages. I believe it is not wrong to leave=20 > the text as it is. >=20 > =3D=3D> In the AVP Occurence table, Key AVP can be found in the=20 > request while this AVP is missing in the ABNF description.=20 > inconsistency must fixed. > Moreover, if Key AVP can be found in the request, add some=20 > text to explain why. > >>[VC] Good catch. Key AVP needs to be an optional AVP in the=20 > request. If present it contains SPI. Some applications might=20 > use SPI values for key identification purposes. Key AVP is=20 > added in the ABNF description. >=20 > [skip] >=20 >=20 > 7. AVP Occurrence Tables >=20 > The following tables present the AVPs defined or used in this > document and their occurrences in Diameter messages. =20 > Note that AVPs > that can only be present within a Grouped AVP are not=20 > represented in > this table. >=20 > The table uses the following symbols: >=20 > 0: >=20 > The AVP MUST NOT be present in the message. >=20 >=20 > 0+: >=20 > Zero or more instances of the AVP MAY be present in=20 > the message. >=20 >=20 > 0-1: >=20 > Zero or one instance of the AVP MAY be present in the message. >=20 >=20 > 1: >=20 > One instance of the AVP MUST be present in the message. >=20 >=20 >=20 > +-------------------+ > | Command-Code | > |---------+---------+ > AVP Name | IKEPSKR | IKEPSKA | > -------------------------------|---------+---------+ > Key | 0-1 | 0-1 | > IKEv2-Nonces | 0-1 | 0 | > +---------+---------+ >=20 > IKEPSKR and IKEPSKA Commands AVP Table >=20 > =3D=3D> Inconsistency! IKEv2-Nonces is described are required in=20 > the Request and the Occurence is then 1. Moreover, the use=20 > of Key AVP in the request is not described, neither in the=20 > text nor in the request ABNF description. > >>[VC] Agreed. Table is changed. >=20 >=20 > [skip] >=20 > 11.2. Informative References >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson,=20 > J., and H. > Levkowetz, "Extensible Authentication Protocol (EAP)", > RFC 3748, June 2004. >=20 > [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and=20 > M. Nakhjiri, > "Specification for the Derivation of Root Keys from an > Extended Master Session Key (EMSK)", RFC 5295, > August 2008. >=20 >=20 > =3D=3D> an informative reference to RFC 4285 should be added=20 > (cf. previous > comment) > >>[VC] Added. >=20 > -- > Ticket URL: > dime >=20 >=20 From dlehmann@ulticom.com Tue Aug 31 06:12:49 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619633A6835 for ; Tue, 31 Aug 2010 06:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUvaJa8RJs5H for ; Tue, 31 Aug 2010 06:12:45 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 2FEAD3A690E for ; Tue, 31 Aug 2010 06:12:45 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 8D47835CC1C0E5CB for ; Tue, 31 Aug 2010 09:13:15 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o7VDDA6Q001563 for ; Tue, 31 Aug 2010 09:13:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB490E.4296D6CE" Date: Tue, 31 Aug 2010 09:13:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3588 - fixed positioned session-ID AVPs Thread-Index: ActJDhHpu5bXx/dWT/OYD3e13pPP3Q== From: "David Lehmann" To: Received-SPF: none Subject: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 13:12:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB490E.4296D6CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." =20 By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 ------_=_NextPart_001_01CB490E.4296D6CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hello,
 
In RFC 3588 (and 3588bis), messages with session IDs are =
defined with the session ID AVPs with a fixed position which is =
immediately following the header. (e.g. section 8.3.1)  However, =
this is in contradiction with section 8.8 which states, “When =
present, the Session-Id SHOULD appear immediately following the Diameter =
Header (see Section =
3).”
 
By using =
“SHOULD”, the spec is stating that the session-ID AVP could =
be in any position in the message.



 



--



David =
Lehmann



Ulticom, =
Inc.



856-787-2952



 
------_=_NextPart_001_01CB490E.4296D6CE-- From gwz@net-zen.net Tue Aug 31 06:53:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CF03A693F for ; Tue, 31 Aug 2010 06:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRuLvXpiyi1A for ; Tue, 31 Aug 2010 06:53:32 -0700 (PDT) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id 712763A690E for ; Tue, 31 Aug 2010 06:53:31 -0700 (PDT) Received: (qmail 23101 invoked from network); 31 Aug 2010 13:53:59 -0000 Received: from unknown (124.157.141.122) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 31 Aug 2010 13:53:58 -0000 From: "Glen Zorn" To: "'David Lehmann'" References: In-Reply-To: Date: Tue, 31 Aug 2010 20:53:30 +0700 Organization: Network Zen Message-ID: <009f01cb4913$e76b5b50$b64211f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CB494E.93CA3350" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActJDhHpu5bXx/dWT/OYD3e13pPP3QABIG/w Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 13:53:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A0_01CB494E.93CA3350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Lehmann [mailto://dlehmann@ulticom.com] writes: Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. Hope this helps. ~gwz ------=_NextPart_000_00A0_01CB494E.93CA3350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
David =
Lehmann [mailto://dlehmann@ulticom.com] =
writes:

Hello,
Hello.
In RFC 3588 (and =
3588bis), messages with session IDs are defined with the session ID AVPs =
with a fixed position which is immediately following the header. (e.g. =
section 8.3.1)  
Yes.
Howev=
er, this is in contradiction with section 8.8 which states, “When =
present, the Session-Id SHOULD appear immediately following the Diameter =
Header (see Section 3).”
No.
By =
using “SHOULD”, the spec is stating that the session-ID AVP =
could be in any position in the message.

No, it is stating that the AVP could be in any position = in some message.  The syntax of the existing messages in RFC 3588 is = defined by the associated BNF and in those messages the Session-Id AVP = must immediately follow the Diameter header.

 

 

Hope this helps.

 

 ~gwz

------=_NextPart_000_00A0_01CB494E.93CA3350-- From dlehmann@ulticom.com Tue Aug 31 07:36:48 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3A53A69B7 for ; Tue, 31 Aug 2010 07:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs5p7Tb0RpJc for ; Tue, 31 Aug 2010 07:36:42 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id B7AF43A69B4 for ; Tue, 31 Aug 2010 07:36:41 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id AB4EA24C05F2A334; Tue, 31 Aug 2010 10:37:11 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o7VEbBuL017083; Tue, 31 Aug 2010 10:37:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4919.FEFFF24E" Date: Tue, 31 Aug 2010 10:37:11 -0400 Message-ID: In-Reply-To: <009f01cb4913$e76b5b50$b64211f0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC 3588 - fixed positioned session-ID AVPs Thread-Index: ActJDhHpu5bXx/dWT/OYD3e13pPP3QABIG/wAAF5JwA= References: <009f01cb4913$e76b5b50$b64211f0$@net> From: "David Lehmann" To: "Glen Zorn" Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 14:36:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4919.FEFFF24E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glen, =20 That is not what the spec says. At least, the wording is not clear and, IMHO, is misleading. In which "some message" can the session-id AVP be in any position? =20 It seems to me that the wording in section 8.8 should be: "When present, the Session-Id MUST appear immediately following the Diameter Header (see Section 3)." =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Tuesday, August 31, 2010 9:54 AM To: David Lehmann Cc: dime@ietf.org Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 David Lehmann [mailto://dlehmann@ulticom.com] writes: Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) =20 Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. =20 =20 Hope this helps. =20 ~gwz ------_=_NextPart_001_01CB4919.FEFFF24E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glen,

 

That is not what the = spec says.  At least, the wording is not clear and, IMHO, is misleading.  In = which “some message” can the session-id AVP be in any = position?

 

It seems to me that = the wording in section 8.8 should be:  “When present, the Session-Id = MUST appear immediately following the Diameter Header (see Section = 3).”

 

--

David Lehmann

Ulticom, = Inc.

856-787-2952

 

From:= Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 

David =
Lehmann [mailto://dlehmann@ulticom.com] =
writes:




Hello,
Hello.
In =
RFC 3588 (and 3588bis), messages with session IDs are defined with the =
session ID AVPs with a fixed position which is immediately following the =
header. (e.g. section 8.3.1)  
Yes.
Howev=
er, this is in contradiction with section 8.8 which states, “When =
present, the Session-Id SHOULD appear immediately following the Diameter =
Header (see Section 3).”
No.
By =
using “SHOULD”, the spec is stating that the session-ID AVP =
could be in any position in the message.

No, it is stating that the AVP could be in any position = in some message.  The syntax of the existing messages in RFC 3588 is = defined by the associated BNF and in those messages the Session-Id AVP = must immediately follow the Diameter header.

 

 

Hope this helps.

 

 ~gwz

------_=_NextPart_001_01CB4919.FEFFF24E-- From vf0213@gmail.com Tue Aug 31 08:51:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F293A6846 for ; Tue, 31 Aug 2010 08:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ6GGcoaiiVf for ; Tue, 31 Aug 2010 08:51:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C8B5D3A690F for ; Tue, 31 Aug 2010 08:51:39 -0700 (PDT) Received: by wyi11 with SMTP id 11so8558797wyi.31 for ; Tue, 31 Aug 2010 08:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LPpNVd8xkdw5ZK+kgG0AA7qpFaOQ2TTQnL2D5kNL+MY=; b=IAU28jUSgFrauMyTdK1nbnpbQ+TPqR3zaSkDTBFPG1kn8xefm9DQHeQP1AxAgS+OsK E+B01AQdbgdKlGF9cimrrd8nm6hJNrDvFsKKPjvnSB3THSZlKRYQillJYzSf69nThl7Z XzIAhmzxcoFQuudPklfxljzGBK6OgdDQqnr1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bU/oKr5XZ8gfdQb3cYve885f/asR2K58uU8YV8/XgNgoGovTC9PS9MaY2HdjaGXz2U kZBCgwVGQJOwWQXAtu5zIOeCeomRq6HEVuEQyV2JSHiiRvvYuJv9EL+/e5k3YqGBcyhu ZXDLA5jCZXxmtcas5gyYkmEnDMqmgHfD+LXCY= MIME-Version: 1.0 Received: by 10.227.145.69 with SMTP id c5mr6228706wbv.168.1283269929588; Tue, 31 Aug 2010 08:52:09 -0700 (PDT) Received: by 10.216.58.130 with HTTP; Tue, 31 Aug 2010 08:52:09 -0700 (PDT) In-Reply-To: References: <009f01cb4913$e76b5b50$b64211f0$@net> Date: Tue, 31 Aug 2010 11:52:09 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=001636833d464de2a1048f20904b Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 15:51:41 -0000 --001636833d464de2a1048f20904b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi David, On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann wrote= : > Glen, > > > > That is not what the spec says. At least, the wording is not clear and, > IMHO, is misleading. In which =93*some* message=94 can the session-id AV= P be > in any position? > > > > It seems to me that the wording in section 8.8 should be: =93When presen= t, > the Session-Id MUST appear immediately following the Diameter Header (see > Section 3).=94 > As Glen has mentioned, the BNF dictates the positioning of the AVP. If you add this text you are adding new rules beyond the BNF. regards, victor > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Glen Zorn [mailto:gwz@net-zen.net] > *Sent:* Tuesday, August 31, 2010 9:54 AM > *To:* David Lehmann > *Cc:* dime@ietf.org > *Subject:* RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > David Lehmann [mailto://dlehmann@ulticom.com] <[mailto://dlehmann@ulticom= .com%5d> writes: > > Hello, > > Hello. > > In RFC 3588 (and 3588bis), messages with session IDs are defined with the= session ID AVPs with a fixed position which is immediately following the h= eader. (e.g. section 8.3.1) > > Yes. > > However, this is in contradiction with section 8.8 which states, =93When = present, the Session-Id SHOULD appear immediately following the Diameter He= ader (see Section 3).=94 > > No. > > By using =93SHOULD=94, the spec is stating that the session-ID AVP could = be in any position in the message. > > No, it is stating that the AVP could be in any position in *some*message.= The syntax of the existing messages in RFC 3588 is defined by the > associated BNF and in *those* messages the Session-Id AVP *must*immediate= ly follow the Diameter header. > > > > > > Hope this helps. > > > > ~gwz > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > --001636833d464de2a1048f20904b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann = <dlehmann@ulti= com.com> wrote:

Glen,

=A0

That is not what the = spec says.=A0 At least, the wording is not clear and, IMHO, is misleading.= =A0 In which =93some message=94 can the session-id AVP be in any pos= ition?

=A0

It seems to me that t= he wording in section 8.8 should be:=A0 =93When present, the Session= -Id MUST appear immediately following the Diameter Header (see Section 3).= =94

=A0
As Glen has mentioned, the BNF dictates the positioning of the AVP. If= you add this text you are adding new rules beyond the BNF.
=A0
regards,
victor
=A0
=A0
=A0

=A0

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0

From:<= span style=3D"FONT-SIZE: 10pt"> Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, = August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - f= ixed positioned session-ID AVPs

=A0

David Lehmann [mailto://dlehmann@u=
lticom.com] writes:





Hello,
Hello.
In RFC 3588 (and 3588bis), messages with session IDs are def=
ined with the session ID AVPs with a fixed position which is immediately fo=
llowing the header. (e.g. section 8.3.1)=A0 =

Yes.
However, this is =
in contradiction with section 8.8 which states, =93When present, the Sessio=
n-Id SHOULD appear immediately following the Diameter Header (see Section 3=
).=94
No.
By using =93SHOULD=
=94, the spec is stating that the session-ID AVP could be in any position i=
n the message.

No, = it is stating that the AVP could be in any position in some message.= =A0 The syntax of the existing messages in RFC 3588 is defined by the assoc= iated BNF and in those messages the Session-Id AVP must immed= iately follow the Diameter header.

=A0

=A0<= /span>

Hope= this helps.

=A0<= /span>

=A0~= gwz


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


--001636833d464de2a1048f20904b-- From dlehmann@ulticom.com Tue Aug 31 10:54:03 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A7A3A6847 for ; Tue, 31 Aug 2010 10:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAnbdJpld7y1 for ; Tue, 31 Aug 2010 10:53:57 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 320D73A68DF for ; Tue, 31 Aug 2010 10:53:57 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 334C905FC5F07626; Tue, 31 Aug 2010 13:54:24 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o7VHs9ss015121; Tue, 31 Aug 2010 13:54:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4935.831DF8C6" Date: Tue, 31 Aug 2010 13:54:09 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC 3588 - fixed positioned session-ID AVPs Thread-Index: ActJJIE5KpKeGP52RyyvAA9176Y+9AAD09Mw References: <009f01cb4913$e76b5b50$b64211f0$@net> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 17:54:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4935.831DF8C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The existing text in 8.8 is contradicting the BNF. I am suggesting text that agrees and supports the BNF. =20 =20 If you don't want to modify the text to agree with the BNF, then I suggest removing the existing text which contradicts it. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 11:52 AM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 Hi David, On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann wrote: Glen, =20 That is not what the spec says. At least, the wording is not clear and, IMHO, is misleading. In which "some message" can the session-id AVP be in any position? =20 It seems to me that the wording in section 8.8 should be: "When present, the Session-Id MUST appear immediately following the Diameter Header (see Section 3)." =20 As Glen has mentioned, the BNF dictates the positioning of the AVP. If you add this text you are adding new rules beyond the BNF. =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Tuesday, August 31, 2010 9:54 AM To: David Lehmann Cc: dime@ietf.org Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 David Lehmann [mailto://dlehmann@ulticom.com] writes: =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) =20 Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. =20 =20 Hope this helps. =20 ~gwz =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------_=_NextPart_001_01CB4935.831DF8C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The existing text in 8.8 is contradicting the BNF.  = I am suggesting text that agrees and supports the BNF.  =

 

If you don’t want to modify the text to agree with = the BNF, then I suggest removing the existing text which contradicts = it.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 

Hi = David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann = <dlehmann@ulticom.com> = wrote:

Glen,

 

That is not what the spec says.  At least, = the wording is not clear and, IMHO, is misleading.  In which = “some message” can the session-id AVP be in any = position?

 

It seems to me that the wording in section 8.8 = should be:  “When present, the Session-Id MUST appear immediately following = the Diameter Header (see Section 3).”

 

As Glen has mentioned, the BNF dictates the = positioning of the AVP. If you add this text you are adding new rules beyond the = BNF.

 

regards,

victor

 

 

 

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

David Lehmann [mailto://dlehmann@ulticom.com] =
writes:




 





Hello,
Hello.
In RFC 3588 =
(and 3588bis), messages with session IDs are defined with the session ID =
AVPs with a fixed position which is immediately following the header. =
(e.g. section 8.3.1)  
Yes.
However, this =
is in contradiction with section 8.8 which states, “When present, =
the Session-Id SHOULD appear immediately following the Diameter Header =
(see Section 3).”
No.
By using =
“SHOULD”, the spec is stating that the session-ID AVP could =
be in any position in the message.

No, it is stating that the AVP = could be in any position in some message.  The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in = those messages the Session-Id AVP must immediately follow the Diameter = header.

 

 

Hope this = helps.

 

 ~gwz

=


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

 

------_=_NextPart_001_01CB4935.831DF8C6-- From vf0213@gmail.com Tue Aug 31 11:20:15 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9168E3A6A10 for ; Tue, 31 Aug 2010 11:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU-atLlb+PRi for ; Tue, 31 Aug 2010 11:20:14 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B559C3A69D7 for ; Tue, 31 Aug 2010 11:20:13 -0700 (PDT) Received: by ewy22 with SMTP id 22so4234454ewy.31 for ; Tue, 31 Aug 2010 11:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QbzEr5vmYh9uBEcjUScqxT5ffaw4Cz7DM/4d26rzkx8=; b=iuT5ECUa4dP76BZi3oqwvPmS5wb6traP43Xi0iKGiI5AhiBXUDkJAvMpefIGC+rtZU 0m2RTDSaXdBIdWRf6cyzxg4OUw/E/b0eu9hRBDXwaL55XRQ7Rm6nh8walmS3Df4SlJlM AjgI2Qu65PCHKkHtRNO6S+1Q+wHGh/2+0Gc+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vNxvkE2GoRdTuHbEoSadiypw0UmHhF/hV77uUN+dyB5Aw3BvVseClmiotRPGVwQWAz d/c5FfbzSQHoFrNBdXqZqXK3kJGiJaN+lgHFih8wz4BDj5VcZxphuaPdgnr56vfgIanZ NpUrfwE62xZs16i3V4rQE2Gxm9CBGZPZ6+tnM= MIME-Version: 1.0 Received: by 10.216.4.19 with SMTP id 19mr6672615wei.110.1283278840600; Tue, 31 Aug 2010 11:20:40 -0700 (PDT) Received: by 10.216.58.130 with HTTP; Tue, 31 Aug 2010 11:20:40 -0700 (PDT) In-Reply-To: References: <009f01cb4913$e76b5b50$b64211f0$@net> Date: Tue, 31 Aug 2010 14:20:40 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=0016364c76fd711934048f22a392 Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 18:20:15 -0000 --0016364c76fd711934048f22a392 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann wrote= : > The existing text in 8.8 is contradicting the BNF. > Which BNF though ? There maybe apps beyond 3588 that may not necessarily put the session-id after the header in their BNF's. In that regard, the existing text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF. my two cents, victor > I am suggesting text that agrees and supports the BNF. > > > > If you don=92t want to modify the text to agree with the BNF, then I sugg= est > removing the existing text which contradicts it. > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 11:52 AM > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > Hi David, > > On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann > wrote: > > Glen, > > > > That is not what the spec says. At least, the wording is not clear and, > IMHO, is misleading. In which =93*some* message=94 can the session-id AV= P be > in any position? > > > > It seems to me that the wording in section 8.8 should be: =93When presen= t, > the Session-Id MUST appear immediately following the Diameter Header (see > Section 3).=94 > > > > As Glen has mentioned, the BNF dictates the positioning of the AVP. If yo= u > add this text you are adding new rules beyond the BNF. > > > > regards, > > victor > > > > > > > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Glen Zorn [mailto:gwz@net-zen.net] > *Sent:* Tuesday, August 31, 2010 9:54 AM > *To:* David Lehmann > *Cc:* dime@ietf.org > *Subject:* RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > David Lehmann [mailto://dlehmann@ulticom.com] <[mailto://dlehmann@ulticom= .com%5d> writes: > > > > > > Hello, > > Hello. > > In RFC 3588 (and 3588bis), messages with session IDs are defined with the= session ID AVPs with a fixed position which is immediately following the h= eader. (e.g. section 8.3.1) > > Yes. > > However, this is in contradiction with section 8.8 which states, =93When = present, the Session-Id SHOULD appear immediately following the Diameter He= ader (see Section 3).=94 > > No. > > By using =93SHOULD=94, the spec is stating that the session-ID AVP could = be in any position in the message. > > No, it is stating that the AVP could be in any position in *some*message.= The syntax of the existing messages in RFC 3588 is defined by the > associated BNF and in *those* messages the Session-Id AVP *must*immediate= ly follow the Diameter header. > > > > > > Hope this helps. > > > > ~gwz > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > --0016364c76fd711934048f22a392 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <= span dir=3D"ltr"><dlehmann@ultic= om.com> wrote:

The = existing text in 8.8 is contradicting the BNF.=A0

=A0
=A0
Which BNF though ? There maybe apps beyond 3588 that may not necessari= ly put the session-id after the header in their BNF's. In that regard, = the existing text is not contradictory but is meant to be generalized speci= ally because it describes an AVP and is agnostic to any BNF.
=A0
my two cents,
victor
=A0
=A0

I am= suggesting text that agrees and supports the BNF.=A0

=A0<= /span>

If y= ou don=92t want to modify the text to agree with the BNF, then I suggest re= moving the existing text which contradicts it.

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] R= FC 3588 - fixed positioned session-ID AVPs

=A0

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <= dlehmann@ulticom.= com> wrote:

Glen,

=A0

That is not what the = spec says.=A0 At least, the wording is not clear and, IMHO, is misleading.= =A0 In which =93some message=94 can the session-id AVP be in any pos= ition?

=A0

It seems to me that t= he wording in section 8.8 should be:=A0 =93When present, the Session= -Id MUST appear immediately following the Diameter Header (see Section 3).= =94

=A0

As Glen has mentioned, the BNF dictates the position= ing of the AVP. If you add this text you are adding new rules beyond the BN= F.

=A0

regards,

victor

=A0

=A0

=A0

=A0

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0

From:<= span style=3D"FONT-SIZE: 10pt"> Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, = August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - f= ixed positioned session-ID AVPs

=A0

David Lehmann [mailto://dlehmann@u=
lticom.com] writes:





=A0





Hello,
Hello.
In RFC 3588 (and 3588bis), messages with session IDs are def=
ined with the session ID AVPs with a fixed position which is immediately fo=
llowing the header. (e.g. section 8.3.1)=A0 
Yes.
However, this is =
in contradiction with section 8.8 which states, =93When present, the Sessio=
n-Id SHOULD appear immediately following the Diameter Header (see Section 3=
).=94
No.
By using =93SHOULD=
=94, the spec is stating that the session-ID AVP could be in any position i=
n the message.

No, = it is stating that the AVP could be in any position in some message.= =A0 The syntax of the existing messages in RFC 3588 is defined by the assoc= iated BNF and in those messages the Session-Id AVP must immed= iately follow the Diameter header.

=A0

=A0<= /span>

Hope= this helps.

=A0<= /span>

=A0~= gwz


__________________= _____________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

=A0


--0016364c76fd711934048f22a392-- From dlehmann@ulticom.com Tue Aug 31 12:22:45 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837C23A6847 for ; Tue, 31 Aug 2010 12:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrPSszjsOWwQ for ; Tue, 31 Aug 2010 12:22:41 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id E45423A6862 for ; Tue, 31 Aug 2010 12:22:40 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 4EA0B07E81C00B68; Tue, 31 Aug 2010 15:23:06 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o7VJMmHW025376; Tue, 31 Aug 2010 15:23:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB4941.EA723786" Date: Tue, 31 Aug 2010 15:22:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC 3588 - fixed positioned session-ID AVPs Thread-Index: ActJOTlU5MSioJKpS2WADmXtpNTLhwAB9bdA References: <009f01cb4913$e76b5b50$b64211f0$@net> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 19:22:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB4941.EA723786 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So you are stating that the Diameter protocol itself does NOT require all session-ID AVPs to follow immediately after the message header, but a message's BNF may require it? =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 2:21 PM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 =20 On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann wrote: The existing text in 8.8 is contradicting the BNF. =20 =20 =20 Which BNF though ? There maybe apps beyond 3588 that may not necessarily put the session-id after the header in their BNF's. In that regard, the existing text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF. =20 my two cents, victor =20 =20 I am suggesting text that agrees and supports the BNF. =20 =20 If you don't want to modify the text to agree with the BNF, then I suggest removing the existing text which contradicts it. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 11:52 AM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 Hi David, On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann wrote: Glen, =20 That is not what the spec says. At least, the wording is not clear and, IMHO, is misleading. In which "some message" can the session-id AVP be in any position? =20 It seems to me that the wording in section 8.8 should be: "When present, the Session-Id MUST appear immediately following the Diameter Header (see Section 3)." =20 As Glen has mentioned, the BNF dictates the positioning of the AVP. If you add this text you are adding new rules beyond the BNF. =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Tuesday, August 31, 2010 9:54 AM To: David Lehmann Cc: dime@ietf.org Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 David Lehmann [mailto://dlehmann@ulticom.com] writes: =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) =20 Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. =20 =20 Hope this helps. =20 ~gwz =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 =20 ------_=_NextPart_001_01CB4941.EA723786 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So you are stating that the Diameter protocol itself does = NOT require all session-ID AVPs to follow immediately after the message = header, but a message’s BNF may require it? 

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 2:21 PM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 

 

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann = <dlehmann@ulticom.com> = wrote:

The existing text in 8.8 is contradicting the BNF. 

 

 

Which BNF though ? There maybe apps beyond 3588 = that may not necessarily put the session-id after the header in their BNF's. In that = regard, the existing text is not contradictory but is meant to be generalized = specially because it describes an AVP and is agnostic to any BNF.

 

my two cents,

victor

 

 

I am suggesting text that = agrees and supports the BNF. 

 

If you don’t want to = modify the text to agree with the BNF, then I suggest removing the existing text = which contradicts it.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <dlehmann@ulticom.com> wrote:

Glen,

 

That is not what the spec says.  At least, = the wording is not clear and, IMHO, is misleading.  In which = “some message” can the session-id AVP be in any = position?

 

It seems to me that the wording in section 8.8 = should be:  “When present, the Session-Id MUST appear immediately following = the Diameter Header (see Section 3).”

 <= /o:p>

As Glen has mentioned, the BNF dictates the positioning of the AVP. If you = add this text you are adding new rules beyond the BNF.

 <= /o:p>

regards,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

=

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

David Lehmann [mailto://dlehmann@ulticom.com] =
writes:




 





 










Hello,
Hello.
In RFC 3588 =
(and 3588bis), messages with session IDs are defined with the session ID =
AVPs with a fixed position which is immediately following the header. =
(e.g. section 8.3.1)  
Yes.
However, this =
is in contradiction with section 8.8 which states, “When present, =
the Session-Id SHOULD appear immediately following the Diameter Header =
(see Section 3).”
No.
By using =
“SHOULD”, the spec is stating that the session-ID AVP could =
be in any position in the message.

No, it is stating that the AVP = could be in any position in some message.  The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in = those messages the Session-Id AVP must immediately follow the Diameter = header.

 

 

Hope this = helps.

 

 ~gwz

=


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

 <= /o:p>

 

------_=_NextPart_001_01CB4941.EA723786-- From vf0213@gmail.com Tue Aug 31 13:24:44 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086933A6AFE for ; Tue, 31 Aug 2010 13:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR4GvuX+Xa8B for ; Tue, 31 Aug 2010 13:24:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B9A3B3A6AFF for ; Tue, 31 Aug 2010 13:24:40 -0700 (PDT) Received: by wyi11 with SMTP id 11so8847733wyi.31 for ; Tue, 31 Aug 2010 13:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JAXNKodTvI9SG1zfLeX9zXG1fv5TSkW8x97zrlRy+uA=; b=j0DVRN/UVno9QrtAm+g2gqpNyRyTpjcDNX4NlGpnKU1GTEq9dudyzr+R9uK5GD/Msm HsoO9sf0U29MFdf1Q+vpPEDCHU0mVktfZjMUguUYuXyOQF4UFTZhQOjut8bGT41toWGu PvOb1hVJvjYU84l4yF1DVEkCR+Dm/kqm1KdZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iIbgiPe9sZwDarD6ker7OzkWTvuSd+jBmnhYg+QUfQZ7IPLIZQ0EUrydw06Zn0DkR5 t2lcqjD7eDPyQnKnTi54v50rd5y5AWCff7Oemkj+SEAtcXSkLWolgcxjpUHZyOsr3A7d ve5ZWbkGDignhgy2BqDarSZANCHxRaNFjlZvI= MIME-Version: 1.0 Received: by 10.216.22.203 with SMTP id t53mr6878525wet.37.1283286310841; Tue, 31 Aug 2010 13:25:10 -0700 (PDT) Received: by 10.216.58.130 with HTTP; Tue, 31 Aug 2010 13:25:10 -0700 (PDT) In-Reply-To: References: <009f01cb4913$e76b5b50$b64211f0$@net> Date: Tue, 31 Aug 2010 16:25:10 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=0016364c7e37b3ee8e048f246055 Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 20:24:44 -0000 --0016364c7e37b3ee8e048f246055 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable yes. the BNF sets the positioning/sequencing rules. it's a common practice in BNFs to place session-id near the head to optimize msg processing .. etc. On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann wrote= : > So you are stating that the Diameter protocol itself does NOT require al= l > session-ID AVPs to follow immediately after the message header, but a > message=92s BNF may require it? > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 2:21 PM > > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > > > On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann > wrote: > > The existing text in 8.8 is contradicting the BNF. > > > > > > Which BNF though ? There maybe apps beyond 3588 that may not necessarily > put the session-id after the header in their BNF's. In that regard, the > existing text is not contradictory but is meant to be generalized special= ly > because it describes an AVP and is agnostic to any BNF. > > > > my two cents, > > victor > > > > > > I am suggesting text that agrees and supports the BNF. > > > > If you don=92t want to modify the text to agree with the BNF, then I sugg= est > removing the existing text which contradicts it. > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 11:52 AM > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > Hi David, > > On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann > wrote: > > Glen, > > > > That is not what the spec says. At least, the wording is not clear and, > IMHO, is misleading. In which =93*some* message=94 can the session-id AV= P be > in any position? > > > > It seems to me that the wording in section 8.8 should be: =93When presen= t, > the Session-Id MUST appear immediately following the Diameter Header (see > Section 3).=94 > > > > As Glen has mentioned, the BNF dictates the positioning of the AVP. If yo= u > add this text you are adding new rules beyond the BNF. > > > > regards, > > victor > > > > > > > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Glen Zorn [mailto:gwz@net-zen.net] > *Sent:* Tuesday, August 31, 2010 9:54 AM > *To:* David Lehmann > *Cc:* dime@ietf.org > *Subject:* RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > David Lehmann [mailto://dlehmann@ulticom.com] <[mailto://dlehmann@ulticom= .com%5d> writes: > > > > > > > > > > > > Hello, > > Hello. > > In RFC 3588 (and 3588bis), messages with session IDs are defined with the= session ID AVPs with a fixed position which is immediately following the h= eader. (e.g. section 8.3.1) > > Yes. > > However, this is in contradiction with section 8.8 which states, =93When = present, the Session-Id SHOULD appear immediately following the Diameter He= ader (see Section 3).=94 > > No. > > By using =93SHOULD=94, the spec is stating that the session-ID AVP could = be in any position in the message. > > No, it is stating that the AVP could be in any position in *some*message.= The syntax of the existing messages in RFC 3588 is defined by the > associated BNF and in *those* messages the Session-Id AVP *must*immediate= ly follow the Diameter header. > > > > > > Hope this helps. > > > > ~gwz > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > --0016364c7e37b3ee8e048f246055 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
yes. the BNF sets the positioning/sequencing rules. it's a common = practice=A0in=A0BNFs to place session-id=A0near the head to optimize msg pr= ocessing .. etc.

On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann <= span dir=3D"ltr"><dlehmann@ultic= om.com> wrote:

So y= ou are stating that the Diameter protocol itself does NOT require all sessi= on-ID AVPs to follow immediately after the message header, but a message=92= s BNF may require it?=A0

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 2:21 PM=20


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Sub= ject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs

=A0

=A0

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

The = existing text in 8.8 is contradicting the BNF.=A0

=A0

=A0

Which BNF though ? There maybe apps beyond 3588 that= may not necessarily put the session-id after the header in their BNF's= . In that regard, the existing text is not contradictory but is meant to be= generalized specially because it describes an AVP and is agnostic to any B= NF.

=A0

my two cents,

victor

=A0

=A0

I am= suggesting text that agrees and supports the BNF.=A0

=A0<= /span>

If y= ou don=92t want to modify the text to agree with the BNF, then I suggest re= moving the existing text which contradicts it.

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] R= FC 3588 - fixed positioned session-ID AVPs

=A0

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <= dlehmann@ulticom.= com> wrote:

Glen,

=A0

That is not what the = spec says.=A0 At least, the wording is not clear and, IMHO, is misleading.= =A0 In which =93some message=94 can the session-id AVP be in any pos= ition?

=A0

It seems to me that t= he wording in section 8.8 should be:=A0 =93When present, the Session= -Id MUST appear immediately following the Diameter Header (see Section 3).= =94

=A0

As Glen has mentioned, the BNF dictates the position= ing of the AVP. If you add this text you are adding new rules beyond the BN= F.

=A0

regards,

victor

=A0

=A0

=A0

=A0

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0

From:<= span style=3D"FONT-SIZE: 10pt"> Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, = August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - f= ixed positioned session-ID AVPs

=A0

David Lehmann [mailto://dlehmann@u=
lticom.com] writes:





=A0





=A0










Hello,
Hello.
In RFC 3588 (and 3588bis), messages with session IDs are def=
ined with the session ID AVPs with a fixed position which is immediately fo=
llowing the header. (e.g. section 8.3.1)=A0 
Yes.
However, this is =
in contradiction with section 8.8 which states, =93When present, the Sessio=
n-Id SHOULD appear immediately following the Diameter Header (see Section 3=
).=94
No.
By using =93SHOULD=
=94, the spec is stating that the session-ID AVP could be in any position i=
n the message.

No, = it is stating that the AVP could be in any position in some message.= =A0 The syntax of the existing messages in RFC 3588 is defined by the assoc= iated BNF and in those messages the Session-Id AVP must immed= iately follow the Diameter header.

=A0

=A0<= /span>

Hope= this helps.

=A0<= /span>

=A0~= gwz


__________________= _____________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

=A0

=A0


--0016364c7e37b3ee8e048f246055-- From gwz@net-zen.net Tue Aug 31 19:54:54 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A0D3A6358 for ; Tue, 31 Aug 2010 19:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.093 X-Spam-Level: X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuKfxTdGsGet for ; Tue, 31 Aug 2010 19:54:50 -0700 (PDT) Received: from p3plsmtpa01-01.prod.phx3.secureserver.net (p3plsmtpa01-01.prod.phx3.secureserver.net [72.167.82.81]) by core3.amsl.com (Postfix) with SMTP id D8A643A63EC for ; Tue, 31 Aug 2010 19:54:49 -0700 (PDT) Received: (qmail 16235 invoked from network); 1 Sep 2010 02:55:19 -0000 Received: from unknown (124.157.141.122) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 01 Sep 2010 02:55:18 -0000 From: "Glen Zorn" To: "'David Lehmann'" References: <009f01cb4913$e76b5b50$b64211f0$@net> In-Reply-To: Date: Wed, 1 Sep 2010 09:54:49 +0700 Organization: Network Zen Message-ID: <000b01cb4981$0cbd9130$2638b390$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01CB49BB.B91C6930" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActJDhHpu5bXx/dWT/OYD3e13pPP3QABIG/wAAF5JwAAGdiacA== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 02:54:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01CB49BB.B91C6930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Lehmann [mailto:dlehmann@ulticom.com] writes: Glen, That is not what the spec says. Actually, it's exactly what the spec says; please revisit RFC 2119 for the definition of the key word "SHOULD". At least, the wording is not clear and, IMHO, is misleading. In which "some message" can the session-id AVP be in any position? Sorry, maybe I was unclear. Let me try again: the definition of the Session-Id AVP does not preclude the definition of a Diameter message in which the Session-Id AVP does not immediately follow the Diameter header; that (AFAIK) no such message currently exists is irrelevant. It seems to me that the wording in section 8.8 should be: "When present, the Session-Id MUST appear immediately following the Diameter Header (see Section 3)." Why unnecessarily constrain the reuse of the AVP? -- David Lehmann Ulticom, Inc. 856-787-2952 From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Tuesday, August 31, 2010 9:54 AM To: David Lehmann Cc: dime@ietf.org Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs David Lehmann [mailto://dlehmann@ulticom.com] writes: Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. Hope this helps. ~gwz ------=_NextPart_000_000C_01CB49BB.B91C6930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David Lehmann [mailto:dlehmann@ulticom.com] writes:
Glen,

 

That is not what the = spec says. 

Actually, it’s exactly what the spec says; please revisit RFC 2119 for the definition of the key word “SHOULD”.

At least, the wording = is not clear and, IMHO, is misleading.  In which “some message” can the session-id AVP be in any = position?

Sorry, maybe I was unclear.  Let me try again: the definition of the = Session-Id AVP does not preclude the definition of a Diameter message in which the = Session-Id AVP does not immediately follow the Diameter header; that (AFAIK) no = such message currently exists is irrelevant.

It seems to me that = the wording in section 8.8 should be:  “When present, the = Session-Id MUST appear immediately following the Diameter Header (see Section = 3).”

Why unnecessarily constrain the reuse of the AVP?

--

David Lehmann

Ulticom, = Inc.

856-787-2952

 

From:= Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 

David =
Lehmann [mailto://dlehmann@ulticom.com] =
writes:









 
Hello,
= 
Hello.
In =
RFC 3588 (and 3588bis), messages with session IDs are defined with the =
session ID AVPs with a fixed position which is immediately following the =
header. (e.g. section 8.3.1)  
Yes.
Howev=
er, this is in contradiction with section 8.8 which states, “When =
present, the Session-Id SHOULD appear immediately following the Diameter =
Header (see Section 3).”
No.
By =
using “SHOULD”, the spec is stating that the session-ID AVP =
could be in any position in the message.

No, it is stating that the AVP could be in any position = in some message.  The syntax of the existing messages in RFC 3588 is = defined by the associated BNF and in those messages the Session-Id AVP = must immediately follow the Diameter header.

 

 

Hope this helps.

 

 ~gwz

------=_NextPart_000_000C_01CB49BB.B91C6930-- From gwz@net-zen.net Tue Aug 31 20:27:27 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B773A68E2 for ; Tue, 31 Aug 2010 20:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHQepRtA9Mm3 for ; Tue, 31 Aug 2010 20:27:25 -0700 (PDT) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id EAA953A6358 for ; Tue, 31 Aug 2010 20:27:24 -0700 (PDT) Received: (qmail 5122 invoked from network); 1 Sep 2010 03:27:53 -0000 Received: from unknown (124.157.141.122) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 01 Sep 2010 03:27:53 -0000 From: "Glen Zorn" To: "'David Lehmann'" , "'Victor Fajardo'" References: <009f01cb4913$e76b5b50$b64211f0$@net> In-Reply-To: Date: Wed, 1 Sep 2010 10:27:23 +0700 Organization: Network Zen Message-ID: <002001cb4985$99e1a110$cda4e330$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CB49C0.46407910" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActJOTlU5MSioJKpS2WADmXtpNTLhwAB9bdAABEV+RA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 03:27:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0021_01CB49C0.46407910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Lehmann [mailto:dlehmann@ulticom.com] writes: So you are stating that the Diameter protocol itself does NOT require all session-ID AVPs to follow immediately after the message header, but a message's BNF may require it? That's what the RFC says, yes. . ------=_NextPart_000_0021_01CB49C0.46407910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David Lehmann [mailto:dlehmann@ulticom.com] writes:
So you are stating that the Diameter protocol itself does = NOT require all session-ID AVPs to follow immediately after the message = header, but a message’s BNF may require it? 

That’s what the RFC says, yes.

…

------=_NextPart_000_0021_01CB49C0.46407910--