From radext-bounces@ietf.org Mon Oct 3 00:02:32 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9CA21F8906; Mon, 3 Oct 2011 00:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1317625352; bh=yBpKwJkhyoZUJOC9rboDITBhVlzjkb/GIjyKK/KqBi8=; h=From:Date:Message-Id:To:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=moXnjbRZTBYFte0SJo3MvlQg8TQwr96b7sHzKNaUGr3fNkya7C9xCMVDUPJNjuS02 PvJN2wY8h8KshepMaGDTotiT1+GZt0/Y4dzF8QSybP1mFjwMcBIUSU0xa8r0sSSZ1a UPaKg1TKAXT+pi2AjKjddhXWvbC+0VcllZ+IhSps= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133AA21F8906 for ; Mon, 3 Oct 2011 00:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlavNrxYOYkH for ; Mon, 3 Oct 2011 00:02:31 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 495F821F888A for ; Mon, 3 Oct 2011 00:02:28 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5424468bka.31 for ; Mon, 03 Oct 2011 00:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=yPS4lQVi25TBpMWIffsEfJ4Mjm+bnGOUfFt4Ah6EZAA=; b=fTvMGZBhUd50sjvfSkG6z2uu9CgtqifCXSC6udpBuu1bQo0ZdTh7pG6beDc5kXNL7k BrvdBk5U4jGyCJQgVyudSfkcBKkJBxP0X0zvITqjDUBxrKIZbat1LF81Eaw9KRwz4rUI NWlN3vFyDWymOawKWevbV/NvVDkjR8hi3lKdo= Received: by 10.204.134.3 with SMTP id h3mr9946359bkt.402.1317625529282; Mon, 03 Oct 2011 00:05:29 -0700 (PDT) Received: from jounis-imac.lan ([188.117.15.106]) by mx.google.com with ESMTPS id ex8sm12082184bkc.2.2011.10.03.00.05.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 00:05:28 -0700 (PDT) From: Jouni Date: Mon, 3 Oct 2011 10:05:25 +0300 Message-Id: To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Cc: Jouni Subject: [radext] testing X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org please ignore. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Mon Oct 3 00:02:32 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133AA21F8906 for ; Mon, 3 Oct 2011 00:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlavNrxYOYkH for ; Mon, 3 Oct 2011 00:02:31 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 495F821F888A for ; Mon, 3 Oct 2011 00:02:28 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5424468bka.31 for ; Mon, 03 Oct 2011 00:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=yPS4lQVi25TBpMWIffsEfJ4Mjm+bnGOUfFt4Ah6EZAA=; b=fTvMGZBhUd50sjvfSkG6z2uu9CgtqifCXSC6udpBuu1bQo0ZdTh7pG6beDc5kXNL7k BrvdBk5U4jGyCJQgVyudSfkcBKkJBxP0X0zvITqjDUBxrKIZbat1LF81Eaw9KRwz4rUI NWlN3vFyDWymOawKWevbV/NvVDkjR8hi3lKdo= Received: by 10.204.134.3 with SMTP id h3mr9946359bkt.402.1317625529282; Mon, 03 Oct 2011 00:05:29 -0700 (PDT) Received: from jounis-imac.lan ([188.117.15.106]) by mx.google.com with ESMTPS id ex8sm12082184bkc.2.2011.10.03.00.05.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 00:05:28 -0700 (PDT) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 3 Oct 2011 10:05:25 +0300 Message-Id: To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Cc: Jouni Subject: [radext] testing X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 07:02:32 -0000 please ignore. From jouni.nospam@gmail.com Mon Oct 3 07:55:30 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ACA21F8B88 for ; Mon, 3 Oct 2011 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5U3PeO8kU3e for ; Mon, 3 Oct 2011 07:55:29 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA7F321F8B8E for ; Mon, 3 Oct 2011 07:55:00 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5964124bka.31 for ; Mon, 03 Oct 2011 07:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=Wb+0n0zFZm4kcL9t4zO8QkXpEBcSM+TWGy52BroLBKE=; b=kuscfhP/LlrKC2jy1crepCsbvAWhFfH//HCRxSOZYCfCffF8h4oAPGfAGUV9T3w5Ia zUmEN++vDoeelYu4uW0vYLp4H22kJcXXrT59LVp5kRfDyzC+JwYE9k4oG3+bpSz3eVgf mcqpQdyzZjVSbDyFodyw+Rb6SfpW1WCKqM6yo= Received: by 10.204.141.148 with SMTP id m20mr22235bku.193.1317653882641; Mon, 03 Oct 2011 07:58:02 -0700 (PDT) Received: from a83-245-210-213.elisa-laajakaista.fi (a83-245-210-213.elisa-laajakaista.fi. [83.245.210.213]) by mx.google.com with ESMTPS id z9sm13493273bkn.7.2011.10.03.07.58.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 07:58:01 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Oct 2011 17:58:01 +0300 Message-Id: To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: jouni korhonen Subject: [radext] New old mailing list X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:55:30 -0000 Folks, As you might have noticed, you all have been migrated to a new RADEXT = mailing list under @ietf.org.. like we discussed in last IETF. So from = now on, please, use radext@ietf.org when mailing to the list. And don't = forget to update you email filters ;) - RADEXT co-chairs= From radext-bounces@ietf.org Mon Oct 3 07:55:32 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB2B21F8B88; Mon, 3 Oct 2011 07:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1317653732; bh=3ewYCWdbGjVrot9ESRDzNGhmhkTingCkOkdiYZPBu7o=; h=From:Date:Message-Id:To:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=nRxrL+yiJ2JwPJ212yCJgdL74h/qSUYuWsQoRsLdt8bY5WiHHsqAg5c68U+QEGGL9 5vRDHbXfbj32+L6GPosnoTLnGPIOFVnhajBYa2U3l2cfl1xB0kHk8JD4MPnydIOaYP g65wsDaoEEf25gHPwk/Wwrg6+B9lOXCBjha0It9Y= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ACA21F8B88 for ; Mon, 3 Oct 2011 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5U3PeO8kU3e for ; Mon, 3 Oct 2011 07:55:29 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA7F321F8B8E for ; Mon, 3 Oct 2011 07:55:00 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5964124bka.31 for ; Mon, 03 Oct 2011 07:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=Wb+0n0zFZm4kcL9t4zO8QkXpEBcSM+TWGy52BroLBKE=; b=kuscfhP/LlrKC2jy1crepCsbvAWhFfH//HCRxSOZYCfCffF8h4oAPGfAGUV9T3w5Ia zUmEN++vDoeelYu4uW0vYLp4H22kJcXXrT59LVp5kRfDyzC+JwYE9k4oG3+bpSz3eVgf mcqpQdyzZjVSbDyFodyw+Rb6SfpW1WCKqM6yo= Received: by 10.204.141.148 with SMTP id m20mr22235bku.193.1317653882641; Mon, 03 Oct 2011 07:58:02 -0700 (PDT) Received: from a83-245-210-213.elisa-laajakaista.fi (a83-245-210-213.elisa-laajakaista.fi. [83.245.210.213]) by mx.google.com with ESMTPS id z9sm13493273bkn.7.2011.10.03.07.58.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 07:58:01 -0700 (PDT) From: jouni korhonen Date: Mon, 3 Oct 2011 17:58:01 +0300 Message-Id: To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: jouni korhonen Subject: [radext] New old mailing list X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Folks, As you might have noticed, you all have been migrated to a new RADEXT mailing list under @ietf.org.. like we discussed in last IETF. So from now on, please, use radext@ietf.org when mailing to the list. And don't forget to update you email filters ;) - RADEXT co-chairs _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From owner-radiusext@ops.ietf.org Wed Oct 19 23:24:11 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBD921F84BC for ; Wed, 19 Oct 2011 23:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oym6d+8shlho for ; Wed, 19 Oct 2011 23:24:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C6D5621F84A3 for ; Wed, 19 Oct 2011 23:24:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RGlzx-00079a-7Q for radiusext-data0@psg.com; Thu, 20 Oct 2011 06:21:01 +0000 Received: from g6t0186.atlanta.hp.com ([15.193.32.63]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RGlzv-00079Q-0R for radiusext@ops.ietf.org; Thu, 20 Oct 2011 06:20:59 +0000 Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 62AE92C1FD; Thu, 20 Oct 2011 06:20:56 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 20 Oct 2011 06:19:40 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Thu, 20 Oct 2011 07:19:40 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" CC: "jouni.korhonen@nsn.com" Date: Thu, 20 Oct 2011 07:19:37 +0100 Subject: Agenda items for IETF 82 Thread-Topic: Agenda items for IETF 82 Thread-Index: AcyO8DkzsFFAIlfLR9Oz9jFo3mf9yw== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD0884E7F@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0884E7FGVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0884E7FGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RADEXT has been given a 2 hour time slot on Monday morning (11/14) from 09:= 00 to 11:00. Please send any requests for agenda slots to chairs. Thank you, Mauricio --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0884E7FGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RADEXT has been = given a 2 hour time slot on Monday morning (11/14) from 09:00 to 11:00.

 

= Please send any requests for agenda slots to chairs. 

<= p class=3DMsoNormal> 

Thank you,

Mauricio

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD0884E7FGVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From radext-bounces@ietf.org Sat Oct 22 21:31:38 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFCD21F8B08; Sat, 22 Oct 2011 21:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319344298; bh=nR4OzYJavGzJEdjTLiPyiQf7sosH+7OyHdfzyMZlvb8=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=eVM85+DqzwbMyv5mBycSzmky++eHaZAdyyWPl27PXbOwsMBXby8nLhgOR+9irAozm NG6Trh8EhiJPLgd/mKrBevDLtovwjc9Es+fQ91bRgHvLXNo1IVF4mHplIzX1zxOXuK 9Kr4TBy8/Kq6ma8mFEW9duee0mJamcDa+a9cHb/4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D369F21F8B05 for ; Sat, 22 Oct 2011 21:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id greCFsEXw2Hr for ; Sat, 22 Oct 2011 21:31:36 -0700 (PDT) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E221F8B04 for ; Sat, 22 Oct 2011 21:31:35 -0700 (PDT) Received: from BLU152-W1 ([65.55.111.73]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Oct 2011 21:31:31 -0700 Message-ID: X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Sat, 22 Oct 2011 21:31:31 -0700 Importance: Normal In-Reply-To: <20111023043053.1200.91299.idtracker@ietfa.amsl.com> References: <20111023043053.1200.91299.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2011 04:31:31.0722 (UTC) FILETIME=[A3B07EA0:01CC913C] Subject: [radext] FW: New Version Notification for draft-aboba-radext-wlan-15.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3829557665040477068==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============3829557665040477068== Content-Type: multipart/alternative; boundary="_1a9d394e-4ce8-4c0f-a67f-ee73f1e0c6e6_" --_1a9d394e-4ce8-4c0f-a67f-ee73f1e0c6e6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > A new version of I-D=2C draft-aboba-radext-wlan-15.txt has been successfu= lly submitted by Bernard Aboba and posted to the IETF repository. >=20 > Filename: draft-aboba-radext-wlan > Revision: 15 > Title: RADIUS Attributes for IEEE 802 Networks > Creation date: 2011-10-22 > WG ID: Individual Submission > Number of pages: 18 >=20 > Abstract: > RFC 3580 provides guidelines for the use of the Remote Authentication > Dialin User Service (RADIUS) within IEEE 802 local area networks > (LANs). This document proposes additional attributes for use within > IEEE 802 networks=2C as well as providing clarifications on the usage > of the EAP-Key-Name attribute=2C updating RFC 4072. The attributes > defined in this document are usable both within RADIUS and Diameter. >=20 > = =20 >=20 >=20 > The IETF Secretariat = --_1a9d394e-4ce8-4c0f-a67f-ee73f1e0c6e6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B A new version of I-D=2C draft-aboba-radext-wlan-15.txt has = been successfully submitted by Bernard Aboba and posted to the IETF reposit= ory.
>=3B
>=3B Filename: draft-aboba-radext-wlan
>=3B Revi= sion: 15
>=3B Title: RADIUS Attributes for IEEE 802 Networks
>= =3B Creation date: 2011-10-22
>=3B WG ID: Individual Submission
= >=3B Number of pages: 18
>=3B
>=3B Abstract:
>=3B RFC = 3580 provides guidelines for the use of the Remote Authentication
>=3B= Dialin User Service (RADIUS) within IEEE 802 local area networks
>= =3B (LANs). This document proposes additional attributes for use within=
>=3B IEEE 802 networks=2C as well as providing clarifications on t= he usage
>=3B of the EAP-Key-Name attribute=2C updating RFC 4072. = The attributes
>=3B defined in this document are usable both within= RADIUS and Diameter.
>=3B
>=3B =
>=3B
>=3B >=3B The IETF Secretariat
= --_1a9d394e-4ce8-4c0f-a67f-ee73f1e0c6e6_-- --===============3829557665040477068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3829557665040477068==-- From bernard_aboba@hotmail.com Sat Oct 22 21:31:36 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D369F21F8B05 for ; Sat, 22 Oct 2011 21:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id greCFsEXw2Hr for ; Sat, 22 Oct 2011 21:31:36 -0700 (PDT) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E221F8B04 for ; Sat, 22 Oct 2011 21:31:35 -0700 (PDT) Received: from BLU152-W1 ([65.55.111.73]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Oct 2011 21:31:31 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1a9d394e-4ce8-4c0f-a67f-ee73f1e0c6e6_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Sat, 22 Oct 2011 21:31:31 -0700 Importance: Normal In-Reply-To: <20111023043053.1200.91299.idtracker@ietfa.amsl.com> References: <20111023043053.1200.91299.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2011 04:31:31.0722 (UTC) FILETIME=[A3B07EA0:01CC913C] Subject: [radext] FW: New Version Notification for draft-aboba-radext-wlan-15.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 04:31:36 -0000 --_1a9d394e-4ce8-4c0f-a67f-ee73f1e0c6e6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > A new version of I-D=2C draft-aboba-radext-wlan-15.txt has been successfu= lly submitted by Bernard Aboba and posted to the IETF repository. >=20 > Filename: draft-aboba-radext-wlan > Revision: 15 > Title: RADIUS Attributes for IEEE 802 Networks > Creation date: 2011-10-22 > WG ID: Individual Submission > Number of pages: 18 >=20 > Abstract: > RFC 3580 provides guidelines for the use of the Remote Authentication > Dialin User Service (RADIUS) within IEEE 802 local area networks > (LANs). This document proposes additional attributes for use within > IEEE 802 networks=2C as well as providing clarifications on the usage > of the EAP-Key-Name attribute=2C updating RFC 4072. The attributes > defined in this document are usable both within RADIUS and Diameter. >=20 > = =20 >=20 >=20 > The IETF Secretariat = --_1a9d394e-4ce8-4c0f-a67f-ee73f1e0c6e6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B A new version of I-D=2C draft-aboba-radext-wlan-15.txt has = been successfully submitted by Bernard Aboba and posted to the IETF reposit= ory.
>=3B
>=3B Filename: draft-aboba-radext-wlan
>=3B Revi= sion: 15
>=3B Title: RADIUS Attributes for IEEE 802 Networks
>= =3B Creation date: 2011-10-22
>=3B WG ID: Individual Submission
= >=3B Number of pages: 18
>=3B
>=3B Abstract:
>=3B RFC = 3580 provides guidelines for the use of the Remote Authentication
>=3B= Dialin User Service (RADIUS) within IEEE 802 local area networks
>= =3B (LANs). This document proposes additional attributes for use within=
>=3B IEEE 802 networks=2C as well as providing clarifications on t= he usage
>=3B of the EAP-Key-Name attribute=2C updating RFC 4072. = The attributes
>=3B defined in this document are usable both within= RADIUS and Diameter.
>=3B
>=3B =
>=3B
>=3B >=3B The IETF Secretariat
= --_1a9d394e-4ce8-4c0f-a67f-ee73f1e0c6e6_-- From mauricio.sanchez@hp.com Mon Oct 24 19:18:25 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF7821F8CD1 for ; Mon, 24 Oct 2011 19:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+iYOwTqkR8A for ; Mon, 24 Oct 2011 19:18:25 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78F21F8CD0 for ; Mon, 24 Oct 2011 19:18:25 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id A894038263; Tue, 25 Oct 2011 02:18:24 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 25 Oct 2011 02:17:49 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 25 Oct 2011 03:17:48 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Tue, 25 Oct 2011 03:17:47 +0100 Thread-Topic: 2nd call : Agenda items for IETF 82 Thread-Index: AcySvCVJNjm2fvNlQwagnGkmPL/fcg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD091E6A2@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jouni.korhonen@nsn.com" Subject: [radext] 2nd call : Agenda items for IETF 82 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 02:18:25 -0000 SECOND CALL ----------------- RADEXT has been given a 2 hour time slot on Monday morning (11/14) from 09:= 00 to 11:00.=20 Please send any requests for agenda slots to chairs.=A0=20 Thank you, Mauricio=20 From radext-bounces@ietf.org Mon Oct 24 19:18:26 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD0A21F8CD1; Mon, 24 Oct 2011 19:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319509106; bh=r1Y2BHVUkUXLUhTQx0S6bg9Jnt5YCYwKe47ubwGpFHY=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=LMNxMeXWCUyDaRAHwjnzIiW63Kw0E2XAfL7izvrEhrmaIFRwrZdper7qvHOXfsrmI Y9GrcJ178JnqGh2vHtHV4EcTAdzLUTcKagAMY3fZovvl9Wm8KXWPZmiAboYn1zIokm ugVd/dN0MZHRxmKA/SrgRxMTD1T+pu5hYHggF6eQ= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF7821F8CD1 for ; Mon, 24 Oct 2011 19:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+iYOwTqkR8A for ; Mon, 24 Oct 2011 19:18:25 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78F21F8CD0 for ; Mon, 24 Oct 2011 19:18:25 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id A894038263; Tue, 25 Oct 2011 02:18:24 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 25 Oct 2011 02:17:49 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 25 Oct 2011 03:17:48 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Tue, 25 Oct 2011 03:17:47 +0100 Thread-Topic: 2nd call : Agenda items for IETF 82 Thread-Index: AcySvCVJNjm2fvNlQwagnGkmPL/fcg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD091E6A2@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "jouni.korhonen@nsn.com" Subject: [radext] 2nd call : Agenda items for IETF 82 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org SECOND CALL ----------------- RADEXT has been given a 2 hour time slot on Monday morning (11/14) from 09:= 00 to 11:00. = Please send any requests for agenda slots to chairs.=A0 = Thank you, Mauricio = _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Tue Oct 25 08:29:28 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8538821F8B89 for ; Tue, 25 Oct 2011 08:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfKIKG-4OmCs for ; Tue, 25 Oct 2011 08:29:26 -0700 (PDT) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by ietfa.amsl.com (Postfix) with ESMTP id 992BE21F8B88 for ; Tue, 25 Oct 2011 08:29:26 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id 414F31459A for ; Tue, 25 Oct 2011 15:29:26 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 25 Oct 2011 15:28:20 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Tue, 25 Oct 2011 16:28:20 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Tue, 25 Oct 2011 16:28:04 +0100 Thread-Topic: RADEXT WG Last Call: "RADIUS attributes for IPv6 Access Networks" Thread-Index: AcyTKjamrHXyVwMQSQSIWnx0IrLTJA== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7GVW0671EXCame_" MIME-Version: 1.0 Subject: [radext] RADEXT WG Last Call: "RADIUS attributes for IPv6 Access Networks" X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:29:28 -0000 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on "RADIUS attributes for IP= v6 Access Networks", prior to sending the document to the IESG for publicat= ion as a proposed standard RFC. The document is available for inspection here: http://tools.ietf.org/wg/radext/draft-ietf-radext-ipv6-access/ The RADEXT WG last call will last until November 8, 2011. If you have com= ments on the document, please file using TRAC system. See below for summar= y of instructions. Thanks, Mauricio --------------------------------- 1. To submit an issue in TRAC, you first need to login to the RADEXT = WG site on the tools server: http://tools.ietf.org/wg/radext/trac/login 2. If you don't already have a login ID, you can obtain one by naviga= ting to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can fil= e an issue by navigating to the ticket entry form: http://trac.tools.ietf.= org/wg/radext/trac/newticket 4. When opening an issue: a. The Type: field should be set to "defect" for an issue with the cu= rrent document text, or "enhancement" for a proposed addition of functional= ity (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. Fo= r example, editorial issues are typically "minor" or "trivial". c. The Milestone: field should be set to milestone1 (useless, I know)= . d. The Component: field should be set to the document you are filing t= he issue on. e. The Version: field should be set to "1.0". f. The Severity: field should be set to based on the status of the d= ocument (e.g. "In WG Last Call" for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you. h. The Assign To: field is generally filled in with the email address = of the editor. 5. Typically it won't be necessary to enclose a file with the ticket,= but if you need to, select "I have files to attach to this ticket". 6. If you want to preview your Issue, click on the "Preview" button. = When you're ready to submit the issue, click on the "Create Ticket" button= . 7. If you want to update an issue, go to the "View Tickets" page: htt= p://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # you = want to update, and then modify the ticket fields as required --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEXT WG last call on "RADIUS attributes for = IPv6 Access Networks", prior to sending the document to the IESG for p= ublication as a proposed standard RFC.

The document is available fo= r inspection here:

http://tools.ietf.org/wg/radext/draft-ietf-radext-ipv6-access/

The RADEXT WG la= st call will last until November 8, 2011.   If you have comments = on the document, please file using TRAC system.  See below for summary= of instructions.

Thanks,
Mauricio

---------------------------------

1.    &nb= sp;  To submit an issue in TRAC, you first need to login to the RADEXT= WG site on the tools server:  http://tools.ietf.org/wg/radext/trac/login

2. &nbs= p;     If you don’t already have a login ID, you = can obtain one by navigating to this site:   http://trac.tools.ietf.org/newlogin

=

<= span style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>3. =       Once you have obtained an account, and have = logged in, you can file an issue by navigating to the  ticket entry fo= rm: http://= trac.tools.ietf.org/wg/radext/trac/newticket

<= /p>

4.    &= nbsp;  When opening an issue:
a.      = ; The Type: field should be set to “defect” for an issue with t= he current document text, or “enhancement” for a proposed addit= ion of functionality (such as an additional requirement).
b.  = ;    The Priority: field is set based on the severity of the= Issue.   For example, editorial issues are typically “mino= r” or “trivial”.
c.     &nbs= p; The Milestone: field should be set to milestone1 (useless, I know).
= d.      The Component: field should be set to the = document you are filing the issue on. 
e.    &= nbsp; The Version: field should be set to “1.0”.
f. &n= bsp;      The Severity: field should be set to bas= ed on the status of the document (e.g. “In WG Last Call” for a = document in WG last call)
g.        T= he Keywords: and CC: fields can be left blank unless inspiration seizes you= .
h.      The Assign To: field is generally fi= lled in with the email address of the editor.

5.    &nb= sp;  Typically it won’t be necessary to enclose a file with the = ticket, but if you need to, select “I have files to attach to this ti= cket”.

6.       If you want to preview = your Issue, click on the “Preview” button.  When you’= ;re ready to submit the issue, click on the “Create Ticket” but= ton.

7.       If you want to update a= n issue, go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/= trac/report/1  Click on the ticket # you want to update, and then = modify the ticket fields as required

 

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7GVW0671EXCame_-- From radext-bounces@ietf.org Tue Oct 25 08:29:30 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D021F8BA0; Tue, 25 Oct 2011 08:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319556570; bh=TVHP+gvd2paV1/FZIn8GBR0uuWYckWVM/DTNUljVD8Q=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=adb3t9I45f3TbynFTPLzE6X73vWctWpDO88lfbkju2rR25v7h5sPj4qaMUjsaDTOx 6EpaMx3i36C8DbxJmwE1386HSC818BA5ke/ERyE/C+ZJ6QDnkIeVDuNDliXi4Z7nkr eTc+znZ+YWqH6coAN0fHkkX45yfakIUyFLJ26LmA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8538821F8B89 for ; Tue, 25 Oct 2011 08:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfKIKG-4OmCs for ; Tue, 25 Oct 2011 08:29:26 -0700 (PDT) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by ietfa.amsl.com (Postfix) with ESMTP id 992BE21F8B88 for ; Tue, 25 Oct 2011 08:29:26 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id 414F31459A for ; Tue, 25 Oct 2011 15:29:26 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 25 Oct 2011 15:28:20 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Tue, 25 Oct 2011 16:28:20 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Tue, 25 Oct 2011 16:28:04 +0100 Thread-Topic: RADEXT WG Last Call: "RADIUS attributes for IPv6 Access Networks" Thread-Index: AcyTKjamrHXyVwMQSQSIWnx0IrLTJA== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] RADEXT WG Last Call: "RADIUS attributes for IPv6 Access Networks" X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7638531609393197686==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============7638531609393197686== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7GVW0671EXCame_" --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on "RADIUS attributes for IP= v6 Access Networks", prior to sending the document to the IESG for publicat= ion as a proposed standard RFC. The document is available for inspection here: http://tools.ietf.org/wg/radext/draft-ietf-radext-ipv6-access/ The RADEXT WG last call will last until November 8, 2011. If you have com= ments on the document, please file using TRAC system. See below for summar= y of instructions. Thanks, Mauricio --------------------------------- 1. To submit an issue in TRAC, you first need to login to the RADEXT = WG site on the tools server: http://tools.ietf.org/wg/radext/trac/login 2. If you don't already have a login ID, you can obtain one by naviga= ting to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can fil= e an issue by navigating to the ticket entry form: http://trac.tools.ietf.= org/wg/radext/trac/newticket 4. When opening an issue: a. The Type: field should be set to "defect" for an issue with the cu= rrent document text, or "enhancement" for a proposed addition of functional= ity (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. Fo= r example, editorial issues are typically "minor" or "trivial". c. The Milestone: field should be set to milestone1 (useless, I know)= . d. The Component: field should be set to the document you are filing t= he issue on. e. The Version: field should be set to "1.0". f. The Severity: field should be set to based on the status of the d= ocument (e.g. "In WG Last Call" for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you. h. The Assign To: field is generally filled in with the email address = of the editor. 5. Typically it won't be necessary to enclose a file with the ticket,= but if you need to, select "I have files to attach to this ticket". 6. If you want to preview your Issue, click on the "Preview" button. = When you're ready to submit the issue, click on the "Create Ticket" button= . 7. If you want to update an issue, go to the "View Tickets" page: htt= p://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # you = want to update, and then modify the ticket fields as required --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEXT WG last call on "RADIUS attributes for = IPv6 Access Networks", prior to sending the document to the IESG for p= ublication as a proposed standard RFC.

The document is available fo= r inspection here:

http://tools.ietf.org/wg/radext/draft-ietf-radext-ipv6-access/

The RADEXT WG la= st call will last until November 8, 2011.   If you have comments = on the document, please file using TRAC system.  See below for summary= of instructions.

Thanks,
Mauricio

---------------------------------

1.    &nb= sp;  To submit an issue in TRAC, you first need to login to the RADEXT= WG site on the tools server:  http://tools.ietf.org/wg/radext/trac/login

2. &nbs= p;     If you don’t already have a login ID, you = can obtain one by navigating to this site:   http://trac.tools.ietf.org/newlogin

=

<= span style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>3. =       Once you have obtained an account, and have = logged in, you can file an issue by navigating to the  ticket entry fo= rm: http://= trac.tools.ietf.org/wg/radext/trac/newticket

<= /p>

4.    &= nbsp;  When opening an issue:
a.      = ; The Type: field should be set to “defect” for an issue with t= he current document text, or “enhancement” for a proposed addit= ion of functionality (such as an additional requirement).
b.  = ;    The Priority: field is set based on the severity of the= Issue.   For example, editorial issues are typically “mino= r” or “trivial”.
c.     &nbs= p; The Milestone: field should be set to milestone1 (useless, I know).
= d.      The Component: field should be set to the = document you are filing the issue on. 
e.    &= nbsp; The Version: field should be set to “1.0”.
f. &n= bsp;      The Severity: field should be set to bas= ed on the status of the document (e.g. “In WG Last Call” for a = document in WG last call)
g.        T= he Keywords: and CC: fields can be left blank unless inspiration seizes you= .
h.      The Assign To: field is generally fi= lled in with the email address of the editor.

5.    &nb= sp;  Typically it won’t be necessary to enclose a file with the = ticket, but if you need to, select “I have files to attach to this ti= cket”.

6.       If you want to preview = your Issue, click on the “Preview” button.  When you’= ;re ready to submit the issue, click on the “Create Ticket” but= ton.

7.       If you want to update a= n issue, go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/= trac/report/1  Click on the ticket # you want to update, and then = modify the ticket fields as required

 

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5CD091E9A7GVW0671EXCame_-- --===============7638531609393197686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============7638531609393197686==-- From radext-bounces@ietf.org Tue Oct 25 10:56:03 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE85321F84A3; Tue, 25 Oct 2011 10:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319565363; bh=ENLaUm+EBiRcFt60ddilBADZks9H53B+rBeZZBa6www=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=XtcPaE8zk5duLgvi7QzAL5IWi9alG6A2EFGAdY+hOuLMJG0kOv1ab0ZnMjupMviVB O4Dr8lD+igMYBER2SLW9VDKQKfwpgyp6IkkzYbGSbA1kT1nkiAe0JBxCLoH9oExBMS XXUktBIQhCeA6oPodcG65IFhhKkv37JS6eryVN8Q= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E9C21F8496 for ; Tue, 25 Oct 2011 10:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeoeEf8Tcomf for ; Tue, 25 Oct 2011 10:56:02 -0700 (PDT) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id CA88821F84A3 for ; Tue, 25 Oct 2011 10:56:01 -0700 (PDT) Received: from BLU152-W50 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 10:56:01 -0700 Message-ID: X-Originating-IP: [131.107.0.114] From: Bernard Aboba To: Date: Tue, 25 Oct 2011 10:56:00 -0700 Importance: Normal In-Reply-To: <066.4896d189d81ed4299493f866d2d586f9@trac.tools.ietf.org> References: <066.4896d189d81ed4299493f866d2d586f9@trac.tools.ietf.org> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2011 17:56:01.0263 (UTC) FILETIME=[5B676FF0:01CC933F] Subject: [radext] TRAC not configured for new RADEXT WG mailing list (fwd) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1040584989029133361==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============1040584989029133361== Content-Type: multipart/alternative; boundary="_8d1ac615-5adb-4be4-97ab-f67563bd5cf5_" --_8d1ac615-5adb-4be4-97ab-f67563bd5cf5_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Note that TRAC is still sending messages to the old (and now discontinued) = RADEXT WG list. =20 > From: trac+radext@trac.tools.ietf.org > CC: radiusext@ops.ietf.org > To: blourdel@cisco.com=3B bernard_aboba@hotmail.com > Date: Tue=2C 25 Oct 2011 16:17:41 +0000 > Subject: [radext] #107: Section 1 >=20 > #107: Section 1 >=20 > I'd suggest not trying to explain the distinction between RFC 3162 > attributes and the ones in this document in Section 1=2C but rather with= in > the specific sections used for that purpose (e.g. Sections 2.1=2C 2.3=2C > etc.). With this material moved elsewhere=2C Section 1 can be rewritten= as > follows: >=20 > This document specifies additional RADIUS attributes used to support > configuration of DHCPv6 and/or ICMPv6 parameters on a per-user basis. > The attributes=2C which complement those defined in [RFC3162] and > [RFC4818]=2C support the following: >=20 > o Assignment of specific IPv6 addresses to hosts via DHCPv6. >=20 > o Assignment of an IPv6 DNS server address=2C via DHCPv6 or [RFC5006= ]. >=20 > o Configuration of more specific routes to be announced to the user > via the Route Information Option defined in [RFC4191] Section 2.3. >=20 > o The assignment of a named delegated prefix pool for use with "IPv6 > Prefix Options for DHCPv6" [RFC3633]. >=20 > o The assignment of a named stateful address pool for use with > DHCPv6 stateful address assignment [RFC3315] >=20 > --=20 > -----------------------------+------------------------ > Reporter: bernard_aboba@=85 | Owner: blourdel@=85 > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: ipv6-access | Version: 1.0 > Severity: In WG Last Call | Keywords: > -----------------------------+------------------------ >=20 > Ticket URL: > radext >=20 = --_8d1ac615-5adb-4be4-97ab-f67563bd5cf5_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Note that TRAC is still sending messages to the old (and now discontinued) = RADEXT WG list. =3B

>=3B From: trac+radext@trac.tools.ie= tf.org
>=3B CC: radiusext@ops.ietf.org
>=3B To: blourdel@cisco.co= m=3B bernard_aboba@hotmail.com
>=3B Date: Tue=2C 25 Oct 2011 16:17:41 = +0000
>=3B Subject: [radext] #107: Section 1
>=3B
>=3B #107= : Section 1
>=3B
>=3B I'd suggest not trying to explain the dis= tinction between RFC 3162
>=3B attributes and the ones in this docume= nt in Section 1=2C but rather within
>=3B the specific sections used = for that purpose (e.g. Sections 2.1=2C 2.3=2C
>=3B etc.). With this = material moved elsewhere=2C Section 1 can be rewritten as
>=3B follow= s:
>=3B
>=3B This document specifies additional RADIUS attri= butes used to support
>=3B configuration of DHCPv6 and/or ICMPv6 p= arameters on a per-user basis.
>=3B The attributes=2C which comple= ment those defined in [RFC3162] and
>=3B [RFC4818]=2C support the = following:
>=3B
>=3B o Assignment of specific IPv6 addresse= s to hosts via DHCPv6.
>=3B
>=3B o Assignment of an IPv6 DN= S server address=2C via DHCPv6 or [RFC5006].
>=3B
>=3B o Co= nfiguration of more specific routes to be announced to the user
>=3B = via the Route Information Option defined in [RFC4191] Section 2.3.>=3B
>=3B o The assignment of a named delegated prefix pool f= or use with "IPv6
>=3B Prefix Options for DHCPv6" [RFC3633].>=3B
>=3B o The assignment of a named stateful address pool f= or use with
>=3B DHCPv6 stateful address assignment [RFC3315]>=3B
>=3B --
>=3B -----------------------------+-----------= -------------
>=3B Reporter: bernard_aboba@=85 | Owner: blour= del@=85
>=3B Type: defect | Status: new
>=3B= Priority: minor | Milestone: milestone1
>=3B Component= : ipv6-access | Version: 1.0
>=3B Severity: In WG Last Cal= l | Keywords:
>=3B -----------------------------+------------------= ------
>=3B
>=3B Ticket URL: <=3Bhttp://trac.tools.ietf.org/wg= /radext/trac/ticket/107>=3B
>=3B radext <=3Bhttp://tools.ietf.org/= radext/>=3B
>=3B
= --_8d1ac615-5adb-4be4-97ab-f67563bd5cf5_-- --===============1040584989029133361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1040584989029133361==-- From bernard_aboba@hotmail.com Tue Oct 25 10:56:02 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E9C21F8496 for ; Tue, 25 Oct 2011 10:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeoeEf8Tcomf for ; Tue, 25 Oct 2011 10:56:02 -0700 (PDT) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id CA88821F84A3 for ; Tue, 25 Oct 2011 10:56:01 -0700 (PDT) Received: from BLU152-W50 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 10:56:01 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8d1ac615-5adb-4be4-97ab-f67563bd5cf5_" X-Originating-IP: [131.107.0.114] From: Bernard Aboba To: Date: Tue, 25 Oct 2011 10:56:00 -0700 Importance: Normal In-Reply-To: <066.4896d189d81ed4299493f866d2d586f9@trac.tools.ietf.org> References: <066.4896d189d81ed4299493f866d2d586f9@trac.tools.ietf.org> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2011 17:56:01.0263 (UTC) FILETIME=[5B676FF0:01CC933F] Subject: [radext] TRAC not configured for new RADEXT WG mailing list (fwd) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:56:02 -0000 --_8d1ac615-5adb-4be4-97ab-f67563bd5cf5_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Note that TRAC is still sending messages to the old (and now discontinued) = RADEXT WG list. =20 > From: trac+radext@trac.tools.ietf.org > CC: radiusext@ops.ietf.org > To: blourdel@cisco.com=3B bernard_aboba@hotmail.com > Date: Tue=2C 25 Oct 2011 16:17:41 +0000 > Subject: [radext] #107: Section 1 >=20 > #107: Section 1 >=20 > I'd suggest not trying to explain the distinction between RFC 3162 > attributes and the ones in this document in Section 1=2C but rather with= in > the specific sections used for that purpose (e.g. Sections 2.1=2C 2.3=2C > etc.). With this material moved elsewhere=2C Section 1 can be rewritten= as > follows: >=20 > This document specifies additional RADIUS attributes used to support > configuration of DHCPv6 and/or ICMPv6 parameters on a per-user basis. > The attributes=2C which complement those defined in [RFC3162] and > [RFC4818]=2C support the following: >=20 > o Assignment of specific IPv6 addresses to hosts via DHCPv6. >=20 > o Assignment of an IPv6 DNS server address=2C via DHCPv6 or [RFC5006= ]. >=20 > o Configuration of more specific routes to be announced to the user > via the Route Information Option defined in [RFC4191] Section 2.3. >=20 > o The assignment of a named delegated prefix pool for use with "IPv6 > Prefix Options for DHCPv6" [RFC3633]. >=20 > o The assignment of a named stateful address pool for use with > DHCPv6 stateful address assignment [RFC3315] >=20 > --=20 > -----------------------------+------------------------ > Reporter: bernard_aboba@=85 | Owner: blourdel@=85 > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: ipv6-access | Version: 1.0 > Severity: In WG Last Call | Keywords: > -----------------------------+------------------------ >=20 > Ticket URL: > radext >=20 = --_8d1ac615-5adb-4be4-97ab-f67563bd5cf5_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Note that TRAC is still sending messages to the old (and now discontinued) = RADEXT WG list. =3B

>=3B From: trac+radext@trac.tools.ie= tf.org
>=3B CC: radiusext@ops.ietf.org
>=3B To: blourdel@cisco.co= m=3B bernard_aboba@hotmail.com
>=3B Date: Tue=2C 25 Oct 2011 16:17:41 = +0000
>=3B Subject: [radext] #107: Section 1
>=3B
>=3B #107= : Section 1
>=3B
>=3B I'd suggest not trying to explain the dis= tinction between RFC 3162
>=3B attributes and the ones in this docume= nt in Section 1=2C but rather within
>=3B the specific sections used = for that purpose (e.g. Sections 2.1=2C 2.3=2C
>=3B etc.). With this = material moved elsewhere=2C Section 1 can be rewritten as
>=3B follow= s:
>=3B
>=3B This document specifies additional RADIUS attri= butes used to support
>=3B configuration of DHCPv6 and/or ICMPv6 p= arameters on a per-user basis.
>=3B The attributes=2C which comple= ment those defined in [RFC3162] and
>=3B [RFC4818]=2C support the = following:
>=3B
>=3B o Assignment of specific IPv6 addresse= s to hosts via DHCPv6.
>=3B
>=3B o Assignment of an IPv6 DN= S server address=2C via DHCPv6 or [RFC5006].
>=3B
>=3B o Co= nfiguration of more specific routes to be announced to the user
>=3B = via the Route Information Option defined in [RFC4191] Section 2.3.>=3B
>=3B o The assignment of a named delegated prefix pool f= or use with "IPv6
>=3B Prefix Options for DHCPv6" [RFC3633].>=3B
>=3B o The assignment of a named stateful address pool f= or use with
>=3B DHCPv6 stateful address assignment [RFC3315]>=3B
>=3B --
>=3B -----------------------------+-----------= -------------
>=3B Reporter: bernard_aboba@=85 | Owner: blour= del@=85
>=3B Type: defect | Status: new
>=3B= Priority: minor | Milestone: milestone1
>=3B Component= : ipv6-access | Version: 1.0
>=3B Severity: In WG Last Cal= l | Keywords:
>=3B -----------------------------+------------------= ------
>=3B
>=3B Ticket URL: <=3Bhttp://trac.tools.ietf.org/wg= /radext/trac/ticket/107>=3B
>=3B radext <=3Bhttp://tools.ietf.org/= radext/>=3B
>=3B
= --_8d1ac615-5adb-4be4-97ab-f67563bd5cf5_-- From bernard_aboba@hotmail.com Tue Oct 25 10:56:44 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42A21F8B9F for ; Tue, 25 Oct 2011 10:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFMlY1JigTqu for ; Tue, 25 Oct 2011 10:56:43 -0700 (PDT) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by ietfa.amsl.com (Postfix) with ESMTP id 60A1521F8B9C for ; Tue, 25 Oct 2011 10:56:43 -0700 (PDT) Received: from BLU152-W15 ([65.55.111.71]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 10:56:42 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_cdee83d2-3edf-42e9-a9a5-77752fafd316_" X-Originating-IP: [131.107.0.114] From: Bernard Aboba To: Date: Tue, 25 Oct 2011 10:56:41 -0700 Importance: Normal In-Reply-To: <066.1923484d92fc28741af4326bb28cfeda@trac.tools.ietf.org> References: <066.1923484d92fc28741af4326bb28cfeda@trac.tools.ietf.org> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2011 17:56:42.0964 (UTC) FILETIME=[74428140:01CC933F] Subject: [radext] FW: #105: Section 2.3 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:56:44 -0000 --_cdee83d2-3edf-42e9-a9a5-77752fafd316_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > From: trac+radext@trac.tools.ietf.org > CC: radiusext@ops.ietf.org > To: blourdel@cisco.com=3B bernard_aboba@hotmail.com > Date: Tue=2C 25 Oct 2011 16:10:32 +0000 > Subject: [radext] #105: Section 2.3 >=20 > #105: Section 2.3 >=20 > In Section 2.3 it says: >=20 > The distinction and separation between this attribute and the Framed- > IPv6-Route attribute defined in [RFC3162] is needed due to the need > to have the information carried by this attribute advertised (in > binary format as per RFC4191) to an attaching client=2C rather than > intended for the NAS itself. >=20 > [BA] My suggestion is that this be replaced by the text from Section 1= =2C > which is more clear: >=20 > While the Framed-IPv6-Prefix Attribute defined in [RFC3162] > Section 2.3 causes the route to be advertised in an RA=2C it > cannot be used to configure more specific routes. While the > Framed-IPv6-Route Attribute defined in [RFC3162] Section 2.5 > causes the route to be configured on the NAS=2C and potentially > announced via an IGP=2C depending on the value of Framed-Routin= g=2C > it does not result in the route being announced in an RA. >=20 > --=20 > -----------------------------+------------------------ > Reporter: bernard_aboba@=85 | Owner: blourdel@=85 > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: ipv6-access | Version: 1.0 > Severity: In WG Last Call | Keywords: > -----------------------------+------------------------ >=20 > Ticket URL: > radext >=20 = --_cdee83d2-3edf-42e9-a9a5-77752fafd316_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


>=3B From: trac+radext@trac.tools.ietf.org
>=3B CC: rad= iusext@ops.ietf.org
>=3B To: blourdel@cisco.com=3B bernard_aboba@hotma= il.com
>=3B Date: Tue=2C 25 Oct 2011 16:10:32 +0000
>=3B Subject:= [radext] #105: Section 2.3
>=3B
>=3B #105: Section 2.3
>= =3B
>=3B In Section 2.3 it says:
>=3B
>=3B The distin= ction and separation between this attribute and the Framed-
>=3B I= Pv6-Route attribute defined in [RFC3162] is needed due to the need
>= =3B to have the information carried by this attribute advertised (in>=3B binary format as per RFC4191) to an attaching client=2C rather = than
>=3B intended for the NAS itself.
>=3B
>=3B [BA] = My suggestion is that this be replaced by the text from Section 1=2C
>= =3B which is more clear:
>=3B
>=3B While the Framed-I= Pv6-Prefix Attribute defined in [RFC3162]
>=3B Section 2.3 c= auses the route to be advertised in an RA=2C it
>=3B cannot = be used to configure more specific routes. While the
>=3B F= ramed-IPv6-Route Attribute defined in [RFC3162] Section 2.5
>=3B = causes the route to be configured on the NAS=2C and potentially
>= =3B announced via an IGP=2C depending on the value of Framed-Rout= ing=2C
>=3B it does not result in the route being announced = in an RA.
>=3B
>=3B --
>=3B -----------------------------+= ------------------------
>=3B Reporter: bernard_aboba@=85 | Ow= ner: blourdel@=85
>=3B Type: defect | Status: ne= w
>=3B Priority: major | Milestone: milestone1
>= =3B Component: ipv6-access | Version: 1.0
>=3B Severity: I= n WG Last Call | Keywords:
>=3B -----------------------------+-----= -------------------
>=3B
>=3B Ticket URL: <=3Bhttp://trac.tool= s.ietf.org/wg/radext/trac/ticket/105>=3B
>=3B radext <=3Bhttp://to= ols.ietf.org/radext/>=3B
>=3B
= --_cdee83d2-3edf-42e9-a9a5-77752fafd316_-- From radext-bounces@ietf.org Tue Oct 25 10:56:45 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD82021F8B9C; Tue, 25 Oct 2011 10:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319565405; bh=+fxOGUqUnkt4b0qD3tlgmVwtU/O9ZVT5MQeMpYoE1gg=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=ooDPx62XeXL5JqN+//3sWqqZmFuOs/iOlZxa3EPqe8trcMkV3Jx8yxbwP0MedsAFP AJvgArlBGfObPN5ITxMDKV4550jC2umwvbVca/yTzeMt9gQbb5KPiZ4SZxlHfv7xjl 2pM3hgtXhF7m9z6LOdCJ0gsu3RfqO/p519w8aoE4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42A21F8B9F for ; Tue, 25 Oct 2011 10:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFMlY1JigTqu for ; Tue, 25 Oct 2011 10:56:43 -0700 (PDT) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by ietfa.amsl.com (Postfix) with ESMTP id 60A1521F8B9C for ; Tue, 25 Oct 2011 10:56:43 -0700 (PDT) Received: from BLU152-W15 ([65.55.111.71]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 10:56:42 -0700 Message-ID: X-Originating-IP: [131.107.0.114] From: Bernard Aboba To: Date: Tue, 25 Oct 2011 10:56:41 -0700 Importance: Normal In-Reply-To: <066.1923484d92fc28741af4326bb28cfeda@trac.tools.ietf.org> References: <066.1923484d92fc28741af4326bb28cfeda@trac.tools.ietf.org> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2011 17:56:42.0964 (UTC) FILETIME=[74428140:01CC933F] Subject: [radext] FW: #105: Section 2.3 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0455218736412370741==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============0455218736412370741== Content-Type: multipart/alternative; boundary="_cdee83d2-3edf-42e9-a9a5-77752fafd316_" --_cdee83d2-3edf-42e9-a9a5-77752fafd316_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > From: trac+radext@trac.tools.ietf.org > CC: radiusext@ops.ietf.org > To: blourdel@cisco.com=3B bernard_aboba@hotmail.com > Date: Tue=2C 25 Oct 2011 16:10:32 +0000 > Subject: [radext] #105: Section 2.3 >=20 > #105: Section 2.3 >=20 > In Section 2.3 it says: >=20 > The distinction and separation between this attribute and the Framed- > IPv6-Route attribute defined in [RFC3162] is needed due to the need > to have the information carried by this attribute advertised (in > binary format as per RFC4191) to an attaching client=2C rather than > intended for the NAS itself. >=20 > [BA] My suggestion is that this be replaced by the text from Section 1= =2C > which is more clear: >=20 > While the Framed-IPv6-Prefix Attribute defined in [RFC3162] > Section 2.3 causes the route to be advertised in an RA=2C it > cannot be used to configure more specific routes. While the > Framed-IPv6-Route Attribute defined in [RFC3162] Section 2.5 > causes the route to be configured on the NAS=2C and potentially > announced via an IGP=2C depending on the value of Framed-Routin= g=2C > it does not result in the route being announced in an RA. >=20 > --=20 > -----------------------------+------------------------ > Reporter: bernard_aboba@=85 | Owner: blourdel@=85 > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: ipv6-access | Version: 1.0 > Severity: In WG Last Call | Keywords: > -----------------------------+------------------------ >=20 > Ticket URL: > radext >=20 = --_cdee83d2-3edf-42e9-a9a5-77752fafd316_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


>=3B From: trac+radext@trac.tools.ietf.org
>=3B CC: rad= iusext@ops.ietf.org
>=3B To: blourdel@cisco.com=3B bernard_aboba@hotma= il.com
>=3B Date: Tue=2C 25 Oct 2011 16:10:32 +0000
>=3B Subject:= [radext] #105: Section 2.3
>=3B
>=3B #105: Section 2.3
>= =3B
>=3B In Section 2.3 it says:
>=3B
>=3B The distin= ction and separation between this attribute and the Framed-
>=3B I= Pv6-Route attribute defined in [RFC3162] is needed due to the need
>= =3B to have the information carried by this attribute advertised (in>=3B binary format as per RFC4191) to an attaching client=2C rather = than
>=3B intended for the NAS itself.
>=3B
>=3B [BA] = My suggestion is that this be replaced by the text from Section 1=2C
>= =3B which is more clear:
>=3B
>=3B While the Framed-I= Pv6-Prefix Attribute defined in [RFC3162]
>=3B Section 2.3 c= auses the route to be advertised in an RA=2C it
>=3B cannot = be used to configure more specific routes. While the
>=3B F= ramed-IPv6-Route Attribute defined in [RFC3162] Section 2.5
>=3B = causes the route to be configured on the NAS=2C and potentially
>= =3B announced via an IGP=2C depending on the value of Framed-Rout= ing=2C
>=3B it does not result in the route being announced = in an RA.
>=3B
>=3B --
>=3B -----------------------------+= ------------------------
>=3B Reporter: bernard_aboba@=85 | Ow= ner: blourdel@=85
>=3B Type: defect | Status: ne= w
>=3B Priority: major | Milestone: milestone1
>= =3B Component: ipv6-access | Version: 1.0
>=3B Severity: I= n WG Last Call | Keywords:
>=3B -----------------------------+-----= -------------------
>=3B
>=3B Ticket URL: <=3Bhttp://trac.tool= s.ietf.org/wg/radext/trac/ticket/105>=3B
>=3B radext <=3Bhttp://to= ols.ietf.org/radext/>=3B
>=3B
= --_cdee83d2-3edf-42e9-a9a5-77752fafd316_-- --===============0455218736412370741== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0455218736412370741==-- From owner-radiusext@ops.ietf.org Tue Oct 25 11:05:53 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0832921F8C00 for ; Tue, 25 Oct 2011 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XguZCoeQ7bxE for ; Tue, 25 Oct 2011 11:05:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 67A7321F8BFE for ; Tue, 25 Oct 2011 11:05:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RIlKg-0001G2-Ke for radiusext-data0@psg.com; Tue, 25 Oct 2011 18:02:38 +0000 Received: from ufisa.uninett.no ([2001:700:1:2:158:38:152:126]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RIlKe-0001Fp-76 for radiusext@ops.ietf.org; Tue, 25 Oct 2011 18:02:36 +0000 Received: from [10.33.12.70] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 471A57FE9; Tue, 25 Oct 2011 20:02:31 +0200 (CEST) Message-ID: <4EA6F9B0.4030403@venaas.com> Date: Tue, 25 Oct 2011 11:02:24 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 CC: jouni korhonen , radext mailing list , "Mauricio (HP Networking) Sanchez" , Stefan Winter Subject: Re: WGLC for draft-ietf-radext-radsec-09 References: <5237C2DA-4D15-41AD-80C4-F6E12CCB1CFE@gmail.com> <6BC3DBF9-C864-435E-B8C2-21AE2B19664D@gmail.com> <4E7C6C87.5080302@deployingradius.com> In-Reply-To: <4E7C6C87.5080302@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On 9/23/2011 4:24 AM, Alan DeKok wrote: > jouni korhonen wrote: >> The WGLC for this I-D completed yesterday. There were no comments, which I am not too comfortable with. However, again the I-D has been around for 2 years and 10 months.. so I guess those who had something to say have already done that. We'll move the I-D forward. What's the status of this now? It passed wglc? According to the tracker it is still waiting for the writeup? Stig > There are 3-4 interoperable implementations. So the document > describes what is in use today. > > Alan DeKok. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From internet-drafts@ietf.org Tue Oct 25 12:40:28 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607D421F8BA6; Tue, 25 Oct 2011 12:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt5kxAwIklKH; Tue, 25 Oct 2011 12:40:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA2821F8B85; Tue, 25 Oct 2011 12:40:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025194027.27188.43289.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 12:40:27 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 19:40:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-02.txt Pages : 57 Date : 2011-10-25 The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit attribute type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-02.t= xt From radext-bounces@ietf.org Tue Oct 25 12:40:31 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9076421F8BAE; Tue, 25 Oct 2011 12:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319571631; bh=DprXGsODVj5tcdnsKSZ3jkpz6QEeTeQ5JfURtV//JyA=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Tmxq3iv/21zXfPOVbMbvBu0OtF26fMlPyh0fq4+G+KBNnPKVerIzx9FzZJowDMutQ 4axGUYhrqKvDeXJ5/1elBAIFc+h9/hQPLyXVMy1piau6nw0yCGH0KcJR9DsxZIPI5P lrGA2fyVc8I2Irb9nFthEKsXOLMU0ATw53/lS8TU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607D421F8BA6; Tue, 25 Oct 2011 12:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt5kxAwIklKH; Tue, 25 Oct 2011 12:40:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA2821F8B85; Tue, 25 Oct 2011 12:40:27 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025194027.27188.43289.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 12:40:27 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Remote Authentication Dial In User Service (RADIUS) Protocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-02.txt Pages : 57 Date : 2011-10-25 The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit attribute type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-02.txt _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From owner-radiusext@ops.ietf.org Tue Oct 25 12:44:51 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66C121F8C0C for ; Tue, 25 Oct 2011 12:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCKKFDgzGEPn for ; Tue, 25 Oct 2011 12:44:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CA5C921F8C04 for ; Tue, 25 Oct 2011 12:44:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RImsO-0004Wt-4q for radiusext-data0@psg.com; Tue, 25 Oct 2011 19:41:33 +0000 Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RImsL-0004Wf-Li for radiusext@ops.ietf.org; Tue, 25 Oct 2011 19:41:30 +0000 Message-ID: <4EA710E3.7010206@deployingradius.com> Date: Tue, 25 Oct 2011 21:41:23 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 References: <4E64DD35.4030306@deployingradius.com> ,<94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: I've submitted -02 which addresses the concerns below. All SHOULD / MAY / MUST / etc. has been removed from the IANA considerations section. It repeated text elsewhere in the document, so there is no loss. Alan DeKok. Bernard Aboba wrote: > Here are my comments: > > The IANA Considerations section needs to be revised. It is recommended > that the IANA considerations section be rewritten according to the > recommendations of RFC 5226, and that this be cited as a normative > reference. > > Some issues: > > 1. The IANA considerations section does not specify how attributes are > to be allocated from the extended space, using policy terms defined in > RFC 5226. > 2. Normative language terms "SHOULD"/"SHOULD NOT" are used in Sections > 9.1 and 9.5. > > The IANA is not a policy making body and therefore is not capable of handling MAY, SHOULD or SHOULD NOT directives. > > > 9.1. Attribute Allocations > > > > IANA is requested to move the "Unassigned" numbers in the range > 144-191 from "Unassigned" to "Deprecated". This status means that > allocations SHOULD NOT be made from this space. Instead, allocations > SHOULD be taken from the Extended Type space, starting with lower > numbered attributes. However, allocation from the "Deprecated" space > MAY still be performed by publication of an IETF specification, where > that specification requests allocation from the "Deprecated" space, > and gives reasons why use of the Extended Type space is impossible. > > > [BA] > > It seems that the goal is to still allow allocation from the Unassigned range, while preferring allocation from the Extended Type space. > > A more implementable way of accomplishing this might be to say that unless specifically requested to allocate from the Standard RADIUS space, > IANA should make allocations from the extended type space. > > > 9.5. Extending the RADIUS Attribute Type Space > > > > The extended RADIUS Attribute Type space may eventually approach > exhaustion. When necessary, the space SHOULD be extended by > publication of a specification which allocates new attributes of > either the "Extended Type", or the "Extended Type with flags" format. > > [BA] This material relates to IETF not IANA processing, and so is not > appropriate for an IANA considerations section. The IANA cannot handle > the policy decisions that are implied here. > > > The specification SHOULD request allocation of a specific number from > the "Reserved" RADIUS Attribute type space, such as 247. The > attribute(s) SHOULD be given a name which follows the naming > convention used in this document. The Extended-Type value of 26 MUST > be allocated to a "Vendor Specific" attribute, of data type "esv". > The Extended-Type values of 241 through 255 MUST be marked as > "Reserved". > > IANA SHOULD allocate the attribute(s) as requested. For example, if > allocation of attribute 247 is requested, the following definitions > MUST be made in the specification, and allocated by IANA. > > * 247.1 Extended-Attribute-7 > * 247.{1-25} Unassigned > * 247.26 Extended-Vendor-Specific-7 > * 247.{27-240} Unassigned > * 247.{241-255} Reserved > > We note,however, that the above list is an example, and we do not > request or perform allocation of attribute 247 in this document. > > > > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 26 04:31:44 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D893121F8ABB for ; Wed, 26 Oct 2011 04:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPGedVSBZsoS for ; Wed, 26 Oct 2011 04:31:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 17B1C21F84A0 for ; Wed, 26 Oct 2011 04:31:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJ1fD-000658-Dx for radiusext-data0@psg.com; Wed, 26 Oct 2011 11:28:55 +0000 Received: from mail-bw0-f52.google.com ([209.85.214.52]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJ1fA-00064w-Lp for radiusext@ops.ietf.org; Wed, 26 Oct 2011 11:28:52 +0000 Received: by bkbzs2 with SMTP id zs2so2017207bkb.11 for ; Wed, 26 Oct 2011 04:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KXW3YeUWEkvA1zbfB/9bjt1IDZb/JZciKl8ACqK5V0s=; b=Tn/SZPM7Od4PDQKkIyo8oAjJeuHMinha9QYrdcLWrldjVKsfGHj60QKqNOZIK7V3At kt+PAdCKIwOhdIPy/U1kq/yYhIpV4xYxYbsUfflvQ1lojfshZBFfd7OHuewfih6CjDOl CZK8ZcKVXuAE2ieGMAZwettnUXEiyjrB1Fvr8= Received: by 10.204.142.76 with SMTP id p12mr24627485bku.64.1319628530623; Wed, 26 Oct 2011 04:28:50 -0700 (PDT) Received: from a88-114-66-59.elisa-laajakaista.fi (a88-114-66-59.elisa-laajakaista.fi. [88.114.66.59]) by mx.google.com with ESMTPS id r12sm1704719bkw.5.2011.10.26.04.28.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Oct 2011 04:28:49 -0700 (PDT) Subject: Re: WGLC for draft-ietf-radext-radsec-09 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4EA6F9B0.4030403@venaas.com> Date: Wed, 26 Oct 2011 14:28:58 +0300 Cc: radext mailing list , "Mauricio (HP Networking) Sanchez" , Stefan Winter Content-Transfer-Encoding: quoted-printable Message-Id: References: <5237C2DA-4D15-41AD-80C4-F6E12CCB1CFE@gmail.com> <6BC3DBF9-C864-435E-B8C2-21AE2B19664D@gmail.com> <4E7C6C87.5080302@deployingradius.com> <4EA6F9B0.4030403@venaas.com> To: Stig Venaas X-Mailer: Apple Mail (2.1084) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Stig, WGLC passed and waiting for a writeup. - Jouni On Oct 25, 2011, at 9:02 PM, Stig Venaas wrote: > On 9/23/2011 4:24 AM, Alan DeKok wrote: >> jouni korhonen wrote: >>> The WGLC for this I-D completed yesterday. There were no comments, = which I am not too comfortable with. However, again the I-D has been = around for 2 years and 10 months.. so I guess those who had something to = say have already done that. We'll move the I-D forward. >=20 > What's the status of this now? It passed wglc? According to the = tracker > it is still waiting for the writeup? >=20 > Stig >=20 >> There are 3-4 interoperable implementations. So the document >> describes what is in use today. >>=20 >> Alan DeKok. >>=20 >> -- >> to unsubscribe send a message to radiusext-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 28 04:50:57 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5972021F8B6C for ; Fri, 28 Oct 2011 04:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hc3zB1GqNK+h for ; Fri, 28 Oct 2011 04:50:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7241021F8B63 for ; Fri, 28 Oct 2011 04:50:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJkrP-000Pmi-M4 for radiusext-data0@psg.com; Fri, 28 Oct 2011 11:44:31 +0000 Received: from szxga03-in.huawei.com ([58.251.152.66]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJkrK-000Plv-Ad for radiusext@ops.ietf.org; Fri, 28 Oct 2011 11:44:27 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTR00EUTXXGMH@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Fri, 28 Oct 2011 19:44:04 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTR001LYXXGG2@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Fri, 28 Oct 2011 19:44:04 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEM78375; Fri, 28 Oct 2011 19:44:02 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 28 Oct 2011 19:43:55 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 19:43:53 +0800 Date: Fri, 28 Oct 2011 11:43:52 +0000 From: Leaf yeh Subject: RE: WGLC for draft-ietf-radext-radius-extensions-01 In-reply-to: <4EA710E3.7010206@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok , Bernard Aboba Cc: "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Qianguofeng Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: WGLC for draft-ietf-radext-radius-extensions-01 Thread-index: AQHMk05tNjKbkL0LBUiGG0kT0OH4opWRItIA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: A. Comments & question: 1. Section 9. I am Not sure that the following words are necessary in section 9, ' However, allocation from the "Deprecated" space can still be performed by publication of an IETF specification, where that specification requests allocation from the "Deprecated" space, and gives reasons why use of the Extended Type space is impossible.' I can't see any reason why use of the Extended Type space is impossible, when the new allocation intends to use the code from 144 to 191 in the above "Deprecated" space. I regard the space of 144-191 sounds the equal-right space as the extended space defined in the draft. Am I right? 2. Section 2.1 - Length ' If a client or server receives an Extended Attribute with a Length of 2 or 3, then that Attribute MUST be deemed to be an "invalid attribute", it SHOULD be silently discarded. If it is not discarded, it MUST NOT be handled in the same manner as a well-formed attribute. Note that an "invalid attribute" does not cause the entire packet to be discarded, or to be treated as a negative acknowledgement. Instead, only the "invalid attribute" is discarded.' How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded? Then how to delimit the next attribute? 3. Section 2.3 - TLV-Length ' If a client or server receives a TLV with an invalid TLV-Length, then the attribute which encapsulates that TLV MUST be deemed to be an "invalid attribute", it SHOULD be silently discarded. ' TLV date type sounds a sub-attribute here. Why do we need discard the whole attribute if we adopt the same logic described above, in section 2.1? B. Editorials: 1. Section 2.2 ' When the More flag is set (1), ... 255; it MUST NOT have a length Field of of value 4; ...' Supposed one 'of' should be here. 2. Section 2.3 (The same case happened in section 2.4.) ' We define a new data type in RADIUS, called "tlv". The "tlv" data type is an encapsulation layer which which permits the "Value" field of an Attribute to contain new sub-Attributes. ' Supposed one 'which' should be here. 3. Section 2.3 - TLV-Type 'As with Extended-Type above, the TLV-Type is meaningful only within a context defined by "Type" fields of the encapsulating Attributes.' Supposed the above should be '...within a context defined by "Extended-Type" field of the encapsulating Attribute.'. 4. Section 2.5 'The expected use og this data type is within Accounting-Request packets, but this data type SHOULD be used in any packet where 32-bit integers are expected to be insufficient.' Supposed the above 'og' should be 'of'. 5. Section 3.1 -String (The same case happened in Section 3.2, 3.3, 3.4, 3.5, 3.6) 'String The String field is one or more octets...' Supposed the above should be 'Value The Value field is one or more octets...' 6. Section 3.5 (The same case happened in Section 3.6) 'Length >= 4' Supposed the above should be ' Length >= 5'. Best Regards, Leaf -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok Sent: Wednesday, October 26, 2011 3:41 AM To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 I've submitted -02 which addresses the concerns below. All SHOULD / MAY / MUST / etc. has been removed from the IANA considerations section. It repeated text elsewhere in the document, so there is no loss. Alan DeKok. Bernard Aboba wrote: > Here are my comments: > > The IANA Considerations section needs to be revised. It is recommended > that the IANA considerations section be rewritten according to the > recommendations of RFC 5226, and that this be cited as a normative > reference. > > Some issues: > > 1. The IANA considerations section does not specify how attributes are > to be allocated from the extended space, using policy terms defined in > RFC 5226. > 2. Normative language terms "SHOULD"/"SHOULD NOT" are used in Sections > 9.1 and 9.5. > > The IANA is not a policy making body and therefore is not capable of handling MAY, SHOULD or SHOULD NOT directives. > > > 9.1. Attribute Allocations > > > > IANA is requested to move the "Unassigned" numbers in the range > 144-191 from "Unassigned" to "Deprecated". This status means that > allocations SHOULD NOT be made from this space. Instead, allocations > SHOULD be taken from the Extended Type space, starting with lower > numbered attributes. However, allocation from the "Deprecated" space > MAY still be performed by publication of an IETF specification, where > that specification requests allocation from the "Deprecated" space, > and gives reasons why use of the Extended Type space is impossible. > > > [BA] > > It seems that the goal is to still allow allocation from the Unassigned range, while preferring allocation from the Extended Type space. > > A more implementable way of accomplishing this might be to say that unless specifically requested to allocate from the Standard RADIUS space, > IANA should make allocations from the extended type space. > > > 9.5. Extending the RADIUS Attribute Type Space > > > > The extended RADIUS Attribute Type space may eventually approach > exhaustion. When necessary, the space SHOULD be extended by > publication of a specification which allocates new attributes of > either the "Extended Type", or the "Extended Type with flags" format. > > [BA] This material relates to IETF not IANA processing, and so is not > appropriate for an IANA considerations section. The IANA cannot handle > the policy decisions that are implied here. > > > The specification SHOULD request allocation of a specific number from > the "Reserved" RADIUS Attribute type space, such as 247. The > attribute(s) SHOULD be given a name which follows the naming > convention used in this document. The Extended-Type value of 26 MUST > be allocated to a "Vendor Specific" attribute, of data type "esv". > The Extended-Type values of 241 through 255 MUST be marked as > "Reserved". > > IANA SHOULD allocate the attribute(s) as requested. For example, if > allocation of attribute 247 is requested, the following definitions > MUST be made in the specification, and allocated by IANA. > > * 247.1 Extended-Attribute-7 > * 247.{1-25} Unassigned > * 247.26 Extended-Vendor-Specific-7 > * 247.{27-240} Unassigned > * 247.{241-255} Reserved > > We note,however, that the above list is an example, and we do not > request or perform allocation of attribute 247 in this document. > > > > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 28 05:43:17 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3365621F8B8B for ; Fri, 28 Oct 2011 05:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PEaiM3-icru for ; Fri, 28 Oct 2011 05:43:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 63FF021F8B81 for ; Fri, 28 Oct 2011 05:43:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJljR-0001me-2o for radiusext-data0@psg.com; Fri, 28 Oct 2011 12:40:21 +0000 Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJljO-0001lr-6G for radiusext@ops.ietf.org; Fri, 28 Oct 2011 12:40:18 +0000 Message-ID: <4EAAA2A9.9050708@deployingradius.com> Date: Fri, 28 Oct 2011 14:40:09 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh CC: Bernard Aboba , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Qianguofeng Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Leaf yeh wrote: > I am Not sure that the following words are necessary in section 9, > > ' However, allocation from the "Deprecated" space > can still be performed by publication of an IETF specification, where > that specification requests allocation from the "Deprecated" space, > and gives reasons why use of the Extended Type space is impossible.' > > I can't see any reason why use of the Extended Type space is impossible, when the new allocation intends to use the code from 144 to 191 in the above "Deprecated" space. Neither can I. But it gives people the ability to use the range 144..191 if they *really* need it. > I regard the space of 144-191 sounds the equal-right space as the extended space defined in the draft. Am I right? No. The above text says its "Deprecated". It SHOULD NOT be used. It's deprecated because the extended format does more, and has more attributes available. We wish to reserve the 144..191 space for future extensions, or for specifications which can't use the extended space. The alternative is to allow allocation from 144..191. What will happen is that no one will use the extended space, and the 144..11 space will quickly be completely allocated. > 2. Section 2.1 - Length > > ' If a client or server receives an Extended > Attribute with a Length of 2 or 3, then that Attribute MUST be > deemed to be an "invalid attribute", it SHOULD be silently > discarded. If it is not discarded, it MUST NOT be handled in the > same manner as a well-formed attribute. > > Note that an "invalid attribute" does not cause the entire packet > to be discarded, or to be treated as a negative acknowledgement. > Instead, only the "invalid attribute" is discarded.' > > How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded? I have no idea what that means. > Then how to delimit the next attribute? I don't know what that means, either. > 3. Section 2.3 - TLV-Length > > ' If a client or server > receives a TLV with an invalid TLV-Length, then the attribute > which encapsulates that TLV MUST be deemed to be an "invalid > attribute", it SHOULD be silently discarded. ' > > TLV date type sounds a sub-attribute here. Yes... it's defined that way in the document. > Why do we need discard the whole attribute if we adopt the same logic described above, in section 2.1? We discard the TLV that is invalid. We don't discard the attribute which encapsulates it. > B. Editorials: > > 1. Section 2.2 > > ' When the More > flag is set (1), ... > 255; it MUST NOT have a length Field of of value 4; ...' > > Supposed one 'of' should be here. Fixed, thanks. > 2. Section 2.3 (The same case happened in section 2.4.) > > ' We define a new data type in RADIUS, called "tlv". The "tlv" data > type is an encapsulation layer which which permits the "Value" field > of an Attribute to contain new sub-Attributes. ' > > Supposed one 'which' should be here. Fixed, thanks. > 3. Section 2.3 - TLV-Type > > 'As with Extended-Type above, the TLV-Type is meaningful only > within a context defined by "Type" fields of the encapsulating > Attributes.' > > Supposed the above should be '...within a context defined by "Extended-Type" field of the encapsulating Attribute.'. It says "Type field*s*". > 4. Section 2.5 > > 'The expected use > og this data type is within Accounting-Request packets, but this data > type SHOULD be used in any packet where 32-bit integers are expected > to be insufficient.' > > Supposed the above 'og' should be 'of'. Fixed, thanks. > 5. Section 3.1 -String (The same case happened in Section 3.2, 3.3, 3.4, 3.5, 3.6) > > 'String > > The String field is one or more octets...' > > Supposed the above should be 'Value > The Value field is one or more octets...' Fixed, thanks. > 6. Section 3.5 (The same case happened in Section 3.6) > > 'Length > > >= 4' > > Supposed the above should be ' Length >= 5'. Fixed, thanks. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 28 20:41:22 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3B41F0C44 for ; Fri, 28 Oct 2011 20:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHqdRP5jAcde for ; Fri, 28 Oct 2011 20:41:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 61AD51F0C36 for ; Fri, 28 Oct 2011 20:41:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJzjk-0006xg-4w for radiusext-data0@psg.com; Sat, 29 Oct 2011 03:37:36 +0000 Received: from szxga01-in.huawei.com ([119.145.14.64]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RJzjd-0006xV-BK for radiusext@ops.ietf.org; Sat, 29 Oct 2011 03:37:32 +0000 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 <0LTT000WB62391@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Sat, 29 Oct 2011 11:37:15 +0800 (CST) Received: from szxrg02-dlp.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 <0LTT008BW621X3@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Sat, 29 Oct 2011 11:37:15 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEM99041; Sat, 29 Oct 2011 11:37:11 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 29 Oct 2011 11:37:00 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Sat, 29 Oct 2011 11:37:04 +0800 Date: Sat, 29 Oct 2011 03:37:04 +0000 From: Leaf yeh Subject: RE: WGLC for draft-ietf-radext-radius-extensions-01 In-reply-to: <4EAAA2A9.9050708@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok Cc: Bernard Aboba , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Qianguofeng Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: WGLC for draft-ietf-radext-radius-extensions-01 Thread-index: AQHMk05tNjKbkL0LBUiGG0kT0OH4opWRItIAgAAN6YCAAV+GAA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> <4EAAA2A9.9050708@deployingradius.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok - We wish to reserve the 144..191 space for future extensions, or for specifications which can't use the extended space. Can we suppose the following codes are reserved for the future extension? 192-223 Experimental Use [RFC3575] 224-240 Implementation Specific [RFC3575] 247-255 Reserved [RFC3575] Note: 241-246 Extended type [Defined in draft-ietf-radext-radius-extensions] I meant the space of 144-191 doesn't really deserve to be ' Deprecated'. Alan DeKok - The alternative is to allow allocation from 144..191. What will happen is that no one will use the extended space, and the 144..11 space will quickly be completely allocated. Understand, but it looks harmless even we expect that happen. Leaf - > 2. Section 2.1 - Length > 'If a client or server receives an Extended > Attribute with a Length of 2 or 3, then that Attribute MUST be > deemed to be an "invalid attribute", it SHOULD be silently > discarded. If it is not discarded, it MUST NOT be handled in the > same manner as a well-formed attribute. > > Note that an "invalid attribute" does not cause the entire packet > to be discarded, or to be treated as a negative acknowledgement. > Instead, only the "invalid attribute" is discarded.' > How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded? Alan DeKok - I have no idea what that means. I meant ' If a client or server receives an Extended Attribute with a Length of 2 or 3, then that Attribute MUST be deemed to be an "invalid attribute", it SHOULD be silently discarded.', then how to do discard this attribute? Does it mean the octets, per the Length of the attribute, eg. 2 or 3, from the 1st octet of 'Type', will be discarded? Can we trust all the attributes followed this 'invalid' attribute' in the Radius packet, if the delimitation of these attributes turns to be some kind of suspicious or difficult? Leaf - > Then how to delimit the next attribute? Alan DeKok - I don't know what that means, either. I meant how to figure out the beginning octet of the next attribute followed this 'invalid' attribute'? Alan DeKok - We discard the TLV that is invalid. We don't discard the attribute which encapsulates it. There exists the same issue described above. ------------------------------------- One more Editorial 7. Section 2.4 ' 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | String .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... String The String field is one or more octets. ...' Would you mind to change the above 'String's to be 'Value's? That might mean more replacements in section 4.1, 4.2, 4.3, 4.4, 4.5 & 4.6. Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Friday, October 28, 2011 8:40 PM To: Leaf yeh Cc: Bernard Aboba; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang; Qianguofeng Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 Leaf yeh wrote: > I am Not sure that the following words are necessary in section 9, > > ' However, allocation from the "Deprecated" space > can still be performed by publication of an IETF specification, where > that specification requests allocation from the "Deprecated" space, > and gives reasons why use of the Extended Type space is impossible.' > > I can't see any reason why use of the Extended Type space is impossible, when the new allocation intends to use the code from 144 to 191 in the above "Deprecated" space. Neither can I. But it gives people the ability to use the range 144..191 if they *really* need it. > I regard the space of 144-191 sounds the equal-right space as the extended space defined in the draft. Am I right? No. The above text says its "Deprecated". It SHOULD NOT be used. It's deprecated because the extended format does more, and has more attributes available. We wish to reserve the 144..191 space for future extensions, or for specifications which can't use the extended space. The alternative is to allow allocation from 144..191. What will happen is that no one will use the extended space, and the 144..11 space will quickly be completely allocated. > 2. Section 2.1 - Length > > ' If a client or server receives an Extended > Attribute with a Length of 2 or 3, then that Attribute MUST be > deemed to be an "invalid attribute", it SHOULD be silently > discarded. If it is not discarded, it MUST NOT be handled in the > same manner as a well-formed attribute. > > Note that an "invalid attribute" does not cause the entire packet > to be discarded, or to be treated as a negative acknowledgement. > Instead, only the "invalid attribute" is discarded.' > > How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded? I have no idea what that means. > Then how to delimit the next attribute? I don't know what that means, either. > 3. Section 2.3 - TLV-Length > > ' If a client or server > receives a TLV with an invalid TLV-Length, then the attribute > which encapsulates that TLV MUST be deemed to be an "invalid > attribute", it SHOULD be silently discarded. ' > > TLV date type sounds a sub-attribute here. Yes... it's defined that way in the document. > Why do we need discard the whole attribute if we adopt the same logic described above, in section 2.1? We discard the TLV that is invalid. We don't discard the attribute which encapsulates it. > B. Editorials: > > 1. Section 2.2 > > ' When the More > flag is set (1), ... > 255; it MUST NOT have a length Field of of value 4; ...' > > Supposed one 'of' should be here. Fixed, thanks. > 2. Section 2.3 (The same case happened in section 2.4.) > > ' We define a new data type in RADIUS, called "tlv". The "tlv" data > type is an encapsulation layer which which permits the "Value" field > of an Attribute to contain new sub-Attributes. ' > > Supposed one 'which' should be here. Fixed, thanks. > 3. Section 2.3 - TLV-Type > > 'As with Extended-Type above, the TLV-Type is meaningful only > within a context defined by "Type" fields of the encapsulating > Attributes.' > > Supposed the above should be '...within a context defined by "Extended-Type" field of the encapsulating Attribute.'. It says "Type field*s*". > 4. Section 2.5 > > 'The expected use > og this data type is within Accounting-Request packets, but this data > type SHOULD be used in any packet where 32-bit integers are expected > to be insufficient.' > > Supposed the above 'og' should be 'of'. Fixed, thanks. > 5. Section 3.1 -String (The same case happened in Section 3.2, 3.3, 3.4, 3.5, 3.6) > > 'String > > The String field is one or more octets...' > > Supposed the above should be 'Value > The Value field is one or more octets...' Fixed, thanks. > 6. Section 3.5 (The same case happened in Section 3.6) > > 'Length > > >= 4' > > Supposed the above should be ' Length >= 5'. Fixed, thanks. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 28 23:54:15 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A71911E8081 for ; Fri, 28 Oct 2011 23:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 105o+dQnAFOH for ; Fri, 28 Oct 2011 23:54:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4E91411E807F for ; Fri, 28 Oct 2011 23:54:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RK2jz-000CKz-TY for radiusext-data0@psg.com; Sat, 29 Oct 2011 06:50:06 +0000 Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RK2js-000CKW-4c for radiusext@ops.ietf.org; Sat, 29 Oct 2011 06:49:56 +0000 Message-ID: <4EABA20C.6000901@deployingradius.com> Date: Sat, 29 Oct 2011 08:49:48 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh CC: Bernard Aboba , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Qianguofeng Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> <4EAAA2A9.9050708@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Leaf yeh wrote: > Alan DeKok - We wish to reserve the 144..191 space for future extensions, or for specifications which can't use the extended space. > > Can we suppose the following codes are reserved for the future extension? Yes, they are. > I meant the space of 144-191 doesn't really deserve to be ' Deprecated'. I explained my reasons. Saying they don't "deserver" to be deprecated isn't a useful response. > Alan DeKok - The alternative is to allow allocation from 144..191. > What will happen is that no one will use the extended space, and the 144..11 space will quickly be completely allocated. > > Understand, but it looks harmless even we expect that happen. By the same argument, there's no harm in requiring people to use the extended space. >> How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded? > Alan DeKok - I have no idea what that means. > > I meant ' If a client or server receives an Extended Attribute with a Length of 2 or 3, then that Attribute MUST be deemed to be an "invalid attribute", it SHOULD be silently discarded.', then how to do discard this attribute? Does it mean the octets, per the Length of the attribute, eg. 2 or 3, from the 1st octet of 'Type', will be discarded? Your question assumes that the input packet is edited to remove the attribute. This is not true. When the text says "discard the attribute", it means "ignore it". > Can we trust all the attributes followed this 'invalid' attribute' in the Radius packet, if the delimitation of these attributes turns to be some kind of suspicious or difficult? I have no idea what that means. > Leaf - > Then how to delimit the next attribute? > Alan DeKok - I don't know what that means, either. > > I meant how to figure out the beginning octet of the next attribute followed this 'invalid' attribute'? You haven't read the draft, then. The "invalid attribute" is correctly formed, so that the entire packet can be correctly decoded. The text says this explicitly. So your question above is based on an incorrect assumption: the "invalid attribute" means "malformed RADIUS packet". > Alan DeKok - We discard the TLV that is invalid. We don't discard the attribute which encapsulates it. > > There exists the same issue described above. The same misunderstanding applies here, too. > One more Editorial .. > Would you mind to change the above 'String's to be 'Value's? > > That might mean more replacements in section 4.1, 4.2, 4.3, 4.4, 4.5 & 4.6. Already done. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Oct 29 03:49:05 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BC821F8AD8 for ; Sat, 29 Oct 2011 03:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWghAEOrq2sq for ; Sat, 29 Oct 2011 03:49:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id BB48321F8AD6 for ; Sat, 29 Oct 2011 03:49:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RK6Q6-000I3b-Uh for radiusext-data0@psg.com; Sat, 29 Oct 2011 10:45:46 +0000 Received: from szxga01-in.huawei.com ([119.145.14.64]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RK6Px-000I3H-RQ for radiusext@ops.ietf.org; Sat, 29 Oct 2011 10:45:39 +0000 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 <0LTT0014YPVY7U@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Sat, 29 Oct 2011 18:45:34 +0800 (CST) Received: from szxrg02-dlp.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 <0LTT00DSOPVWIC@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Sat, 29 Oct 2011 18:45:34 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEN15000; Sat, 29 Oct 2011 18:45:31 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 29 Oct 2011 18:45:20 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Sat, 29 Oct 2011 18:45:21 +0800 Date: Sat, 29 Oct 2011 10:45:21 +0000 From: Leaf yeh Subject: RE: WGLC for draft-ietf-radext-radius-extensions-01 In-reply-to: <4EABA20C.6000901@deployingradius.com> X-Originating-IP: [10.70.39.98] To: Alan DeKok Cc: Bernard Aboba , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Qianguofeng Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: WGLC for draft-ietf-radext-radius-extensions-01 Thread-index: AQHMk05tNjKbkL0LBUiGG0kT0OH4opWRItIAgAAN6YCAAV+GAP//0OwAgACH+RA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> <4EAAA2A9.9050708@deployingradius.com> <4EABA20C.6000901@deployingradius.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok - Saying they don't "deserver" to be deprecated isn't a useful response. It was just my argument, sorry for that. Let's wait for the decision made by the WG or IESG. Alan DeKok - Your question assumes that the input packet is edited to remove the attribute. This is not true. When the text says "discard the attribute", it means "ignore it". Yes. 'Ignore' sounds better, but the question in technique seems still there. I guess the implementation might have some different treatment here: 1. ignore the whole packet; then request the 2nd time; or 2. ignore the attributes followed this invalid attribute; or 3. ignore only this invalid attribute, and delimit the next attribute per the 'length' field of this invalid attribute; Does the 3rd one means 'silently discard' in your text? Alan DeKok - The "invalid attribute" is correctly formed, so that the entire packet can be correctly decoded. The text says this explicitly. Could you show me the explicit text in your draft mentioned above? Leaf - >3. Section 2.3 - TLV-Length > ' If a client or server > receives a TLV with an invalid TLV-Length, then the attribute > which encapsulates that TLV MUST be deemed to be an "invalid > attribute", it SHOULD be silently discarded. ' Alan DeKok - We discard the TLV that is invalid. We don't discard the attribute which encapsulates it. But the above text sounds to discard the whole encapsulating attribute. Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Saturday, October 29, 2011 2:50 PM To: Leaf yeh Cc: Bernard Aboba; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang; Qianguofeng Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 Leaf yeh wrote: > Alan DeKok - We wish to reserve the 144..191 space for future extensions, or for specifications which can't use the extended space. > > Can we suppose the following codes are reserved for the future extension? Yes, they are. > I meant the space of 144-191 doesn't really deserve to be ' Deprecated'. I explained my reasons. Saying they don't "deserver" to be deprecated isn't a useful response. > Alan DeKok - The alternative is to allow allocation from 144..191. > What will happen is that no one will use the extended space, and the 144..11 space will quickly be completely allocated. > > Understand, but it looks harmless even we expect that happen. By the same argument, there's no harm in requiring people to use the extended space. >> How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded? > Alan DeKok - I have no idea what that means. > > I meant ' If a client or server receives an Extended Attribute with a Length of 2 or 3, then that Attribute MUST be deemed to be an "invalid attribute", it SHOULD be silently discarded.', then how to do discard this attribute? Does it mean the octets, per the Length of the attribute, eg. 2 or 3, from the 1st octet of 'Type', will be discarded? Your question assumes that the input packet is edited to remove the attribute. This is not true. When the text says "discard the attribute", it means "ignore it". > Can we trust all the attributes followed this 'invalid' attribute' in the Radius packet, if the delimitation of these attributes turns to be some kind of suspicious or difficult? I have no idea what that means. > Leaf - > Then how to delimit the next attribute? > Alan DeKok - I don't know what that means, either. > > I meant how to figure out the beginning octet of the next attribute followed this 'invalid' attribute'? You haven't read the draft, then. The "invalid attribute" is correctly formed, so that the entire packet can be correctly decoded. The text says this explicitly. So your question above is based on an incorrect assumption: the "invalid attribute" means "malformed RADIUS packet". > Alan DeKok - We discard the TLV that is invalid. We don't discard the attribute which encapsulates it. > > There exists the same issue described above. The same misunderstanding applies here, too. > One more Editorial .. > Would you mind to change the above 'String's to be 'Value's? > > That might mean more replacements in section 4.1, 4.2, 4.3, 4.4, 4.5 & 4.6. Already done. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Oct 29 04:30:02 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B12221F84B3 for ; Sat, 29 Oct 2011 04:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFLSsB82FSQI for ; Sat, 29 Oct 2011 04:30:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 629CD21F86FF for ; Sat, 29 Oct 2011 04:30:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RK73r-000J9W-VG for radiusext-data0@psg.com; Sat, 29 Oct 2011 11:26:51 +0000 Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RK73l-000J9H-M3 for radiusext@ops.ietf.org; Sat, 29 Oct 2011 11:26:46 +0000 Message-ID: <4EABE2EF.3040803@deployingradius.com> Date: Sat, 29 Oct 2011 13:26:39 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh CC: Bernard Aboba , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Qianguofeng Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> <4EAAA2A9.9050708@deployingradius.com> <4EABA20C.6000901@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Leaf yeh wrote: > Alan DeKok - Your question assumes that the input packet is edited to remove the attribute. This is not true. When the text says "discard the attribute", it means "ignore it". > > Yes. 'Ignore' sounds better, but the question in technique seems still there. I guess the implementation might have some different treatment here: No. The document describes the correct behavior. There are no implementation choices. > 1. ignore the whole packet; then request the 2nd time; or > 2. ignore the attributes followed this invalid attribute; or > 3. ignore only this invalid attribute, and delimit the next attribute per the 'length' field of this invalid attribute; > > Does the 3rd one means 'silently discard' in your text? Possibly. I still don't understand why the text is unclear. You're focused on parsing the RADIUS packet. The text about "invalid attribute" is talking about the *attribute*, not the *packet*. > Alan DeKok - The "invalid attribute" is correctly formed, so that the entire packet can be correctly decoded. The text says this explicitly. > > Could you show me the explicit text in your draft mentioned above? The text which defines the "invalid attribute" term at the top of the document. It says that the Length field is valid, but the *Value* field is wrong. Since the Length field is valid, the packet can be parsed correctly. So the entire packet is correctly formed. Again, the term "invalid attribute" refers to the *Value* field of an attribute. It has nothing to do with parsing the packet. I really don't know how to make this any clearer. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From radext-bounces@ietf.org Mon Oct 31 21:07:58 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C2211E80D9; Mon, 31 Oct 2011 21:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320120478; bh=YCnvQ6EDYeB1MAG+d9/ieSpLhUwMl6Sjb9BQ7JEwevY=; h=Date:From:To:Message-id:MIME-version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=f/ylLWaSPm8B7akI//3bbI2IG9UPryHmvTZqJxOveibtHFPuXPKsAdrgULpw6iDYY ZkKD5FCaOyQ522c2j0rvHV030BnCFeGneL6Mzf04L5IM+mO+Tw98tULaTQtUUz7Vvm /RRjC6Cu3cje0uTKMoPsIAMjyRb8UM2s3w7IgAPw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980FA11E8104 for ; Mon, 31 Oct 2011 21:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edakfnSfvwNQ for ; Mon, 31 Oct 2011 21:07:57 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id EA30111E80D9 for ; Mon, 31 Oct 2011 21:07:56 -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 <0LTY0090QRH6NM@szxga05-in.huawei.com> for radext@ietf.org; Tue, 01 Nov 2011 12:07:54 +0800 (CST) Received: from szxrg02-dlp.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 <0LTY00D62RH48B@szxga05-in.huawei.com> for radext@ietf.org; Tue, 01 Nov 2011 12:07:54 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ87999; Tue, 01 Nov 2011 12:07:00 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 12:06:56 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 12:06:24 +0800 Date: Tue, 01 Nov 2011 04:06:23 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.98] To: "radext@ietf.org" Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt Thread-index: AQHMl+QiiReMBYEM7kerhuuvwl6FBJWXO4+AgAApTyCAAAKAEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Dear Group, 1. draft-yeh-radext-ext-traffic-statistics-01 is ready for your comment on whether it deserves a WG item at RADEXT. 2. It defined 8 new attributes of traffic statistics for the separate IPv4 & IPv6 stack (queue or counter), and employed the new date type of integer64, but the format of new attributes might be still a question now. It has 2 options now: a. the traditional format defined in [RFC2865]; b. the new extended format defined in [draft-ietf-radext-radius-extensions-02]. Anyway, they are looking forward to your further discussion now. Best Regards, Leaf -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 31, 2011 11:45 PM To: Leaf yeh Cc: Leaf yeh Subject: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt A new version of I-D, draft-yeh-radext-ext-traffic-statistics-01.txt has been successfully submitted by Leaf Yeh and posted to the IETF repository. Filename: draft-yeh-radext-ext-traffic-statistics Revision: 01 Title: RADIUS Accounting Extensions of Traffic Statistics Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 11 Abstract: This document specifies the RADIUS attributes extensions of IPv4 and IPv6 traffic statistics for the differentiated accounting policies and traffic recording on the AAA server. The IETF Secretariat _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Mon Oct 31 21:07:57 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980FA11E8104 for ; Mon, 31 Oct 2011 21:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edakfnSfvwNQ for ; Mon, 31 Oct 2011 21:07:57 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id EA30111E80D9 for ; Mon, 31 Oct 2011 21:07:56 -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 <0LTY0090QRH6NM@szxga05-in.huawei.com> for radext@ietf.org; Tue, 01 Nov 2011 12:07:54 +0800 (CST) Received: from szxrg02-dlp.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 <0LTY00D62RH48B@szxga05-in.huawei.com> for radext@ietf.org; Tue, 01 Nov 2011 12:07:54 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ87999; Tue, 01 Nov 2011 12:07:00 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 12:06:56 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 12:06:24 +0800 Date: Tue, 01 Nov 2011 04:06:23 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.98] To: "radext@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt Thread-index: AQHMl+QiiReMBYEM7kerhuuvwl6FBJWXO4+AgAApTyCAAAKAEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [radext] FW: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 04:07:57 -0000 Dear Group, 1. draft-yeh-radext-ext-traffic-statistics-01 is ready for your comment on whether it deserves a WG item at RADEXT. 2. It defined 8 new attributes of traffic statistics for the separate IPv4 & IPv6 stack (queue or counter), and employed the new date type of integer64, but the format of new attributes might be still a question now. It has 2 options now: a. the traditional format defined in [RFC2865]; b. the new extended format defined in [draft-ietf-radext-radius-extensions-02]. Anyway, they are looking forward to your further discussion now. Best Regards, Leaf -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 31, 2011 11:45 PM To: Leaf yeh Cc: Leaf yeh Subject: New Version Notification for draft-yeh-radext-ext-traffic-statistics-01.txt A new version of I-D, draft-yeh-radext-ext-traffic-statistics-01.txt has been successfully submitted by Leaf Yeh and posted to the IETF repository. Filename: draft-yeh-radext-ext-traffic-statistics Revision: 01 Title: RADIUS Accounting Extensions of Traffic Statistics Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 11 Abstract: This document specifies the RADIUS attributes extensions of IPv4 and IPv6 traffic statistics for the differentiated accounting policies and traffic recording on the AAA server. The IETF Secretariat From leaf.y.yeh@huawei.com Mon Oct 31 23:15:33 2011 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE8711E80B2 for ; Mon, 31 Oct 2011 23:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEwHTsj7berO for ; Mon, 31 Oct 2011 23:15:32 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95F11E80DD for ; Mon, 31 Oct 2011 23:15:32 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY006RNXA3BS@szxga03-in.huawei.com> for radext@ietf.org; Tue, 01 Nov 2011 14:13:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY00956X9TWS@szxga03-in.huawei.com> for radext@ietf.org; Tue, 01 Nov 2011 14:13:15 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ96364; Tue, 01 Nov 2011 14:13:14 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 14:13:12 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 14:13:05 +0800 Date: Tue, 01 Nov 2011 06:13:04 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.98] To: "radext@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: WGLC for draft-ietf-radext-radius-extensions-01 Thread-index: AQHMk05tNjKbkL0LBUiGG0kT0OH4opWRItIAgAAN6YCAAV+GAP//0OwAgACH+RD//8VggIADAuswgAHiNOA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> <4EAAA2A9.9050708@deployingradius.com> <4EABA20C.6000901@deployingradius.com> <4EABE2EF.3040803@deployingradius.com> Cc: Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 06:15:33 -0000 One more editorial on the title of the draft, remember someone express the same in the ML, I just repeat it here. 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions ' But RFC2869 has the title of 'RADIUS Extensions'. They looks very similarly. How about to re-title your draft? My suggesting might be 'RADIUS Extension Plus on the Type Space of Attributes with more Data Types', just for your reference. ---------------------------------------------------------- One more argument on the text in section 9.1 'New allocations are normally taken from the Extended Type space, starting with lower numbered attributes.' But the attributes, including 241.26 Extended-Vendor-Specific-1 242.26 Extended-Vendor-Specific-2 243.26 Extended-Vendor-Specific-3 244.26 Extended-Vendor-Specific-4 245.26 Extended-Vendor-Specific-5 246.26 Extended-Vendor-Specific-6 seem not follow the above words. Could it let to be decided by IANA? Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Saturday, October 29, 2011 7:27 PM To: Leaf yeh Cc: Bernard Aboba; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang; Qianguofeng Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 Leaf yeh wrote: > Alan DeKok - Your question assumes that the input packet is edited to remove the attribute. This is not true. When the text says "discard the attribute", it means "ignore it". > > Yes. 'Ignore' sounds better, but the question in technique seems still there. I guess the implementation might have some different treatment here: No. The document describes the correct behavior. There are no implementation choices. > 1. ignore the whole packet; then request the 2nd time; or > 2. ignore the attributes followed this invalid attribute; or > 3. ignore only this invalid attribute, and delimit the next attribute per the 'length' field of this invalid attribute; > > Does the 3rd one means 'silently discard' in your text? Possibly. I still don't understand why the text is unclear. You're focused on parsing the RADIUS packet. The text about "invalid attribute" is talking about the *attribute*, not the *packet*. > Alan DeKok - The "invalid attribute" is correctly formed, so that the entire packet can be correctly decoded. The text says this explicitly. > > Could you show me the explicit text in your draft mentioned above? The text which defines the "invalid attribute" term at the top of the document. It says that the Length field is valid, but the *Value* field is wrong. Since the Length field is valid, the packet can be parsed correctly. So the entire packet is correctly formed. Again, the term "invalid attribute" refers to the *Value* field of an attribute. It has nothing to do with parsing the packet. I really don't know how to make this any clearer. Alan DeKok. From radext-bounces@ietf.org Mon Oct 31 23:15:34 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A9E11E80DD; Mon, 31 Oct 2011 23:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1320128134; bh=i/uaaJyInFwtVRbKCo5qGPNKG3hnjmcciDDgLgLM9aw=; h=Date:From:To:Message-id:MIME-version:References:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=VPD1gzE5qprL+weYOXjqxY26RoCLyNyx9tMrb7U8B5GUyYaVdAGBw3MdG7igm7Xo9 xqeE6jb/i8VpZTdaZCJiiBPrJ+/HGF4/KePn5/w6j9vqH1FZkkX1vGMg5VgLUcTVof gPyPIG6V1afZymGATdSl2JBZ6f4PKYcGOfMszG58= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE8711E80B2 for ; Mon, 31 Oct 2011 23:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEwHTsj7berO for ; Mon, 31 Oct 2011 23:15:32 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95F11E80DD for ; Mon, 31 Oct 2011 23:15:32 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY006RNXA3BS@szxga03-in.huawei.com> for radext@ietf.org; Tue, 01 Nov 2011 14:13:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY00956X9TWS@szxga03-in.huawei.com> for radext@ietf.org; Tue, 01 Nov 2011 14:13:15 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ96364; Tue, 01 Nov 2011 14:13:14 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 14:13:12 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 14:13:05 +0800 Date: Tue, 01 Nov 2011 06:13:04 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.98] To: "radext@ietf.org" Message-id: MIME-version: 1.0 Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: WGLC for draft-ietf-radext-radius-extensions-01 Thread-index: AQHMk05tNjKbkL0LBUiGG0kT0OH4opWRItIAgAAN6YCAAV+GAP//0OwAgACH+RD//8VggIADAuswgAHiNOA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E64DD35.4030306@deployingradius.com> <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> <4EA710E3.7010206@deployingradius.com> <4EAAA2A9.9050708@deployingradius.com> <4EABA20C.6000901@deployingradius.com> <4EABE2EF.3040803@deployingradius.com> Cc: Alan DeKok Subject: Re: [radext] WGLC for draft-ietf-radext-radius-extensions-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org One more editorial on the title of the draft, remember someone express the same in the ML, I just repeat it here. 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions ' But RFC2869 has the title of 'RADIUS Extensions'. They looks very similarly. How about to re-title your draft? My suggesting might be 'RADIUS Extension Plus on the Type Space of Attributes with more Data Types', just for your reference. ---------------------------------------------------------- One more argument on the text in section 9.1 'New allocations are normally taken from the Extended Type space, starting with lower numbered attributes.' But the attributes, including 241.26 Extended-Vendor-Specific-1 242.26 Extended-Vendor-Specific-2 243.26 Extended-Vendor-Specific-3 244.26 Extended-Vendor-Specific-4 245.26 Extended-Vendor-Specific-5 246.26 Extended-Vendor-Specific-6 seem not follow the above words. Could it let to be decided by IANA? Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Saturday, October 29, 2011 7:27 PM To: Leaf yeh Cc: Bernard Aboba; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang; Qianguofeng Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 Leaf yeh wrote: > Alan DeKok - Your question assumes that the input packet is edited to remove the attribute. This is not true. When the text says "discard the attribute", it means "ignore it". > > Yes. 'Ignore' sounds better, but the question in technique seems still there. I guess the implementation might have some different treatment here: No. The document describes the correct behavior. There are no implementation choices. > 1. ignore the whole packet; then request the 2nd time; or > 2. ignore the attributes followed this invalid attribute; or > 3. ignore only this invalid attribute, and delimit the next attribute per the 'length' field of this invalid attribute; > > Does the 3rd one means 'silently discard' in your text? Possibly. I still don't understand why the text is unclear. You're focused on parsing the RADIUS packet. The text about "invalid attribute" is talking about the *attribute*, not the *packet*. > Alan DeKok - The "invalid attribute" is correctly formed, so that the entire packet can be correctly decoded. The text says this explicitly. > > Could you show me the explicit text in your draft mentioned above? The text which defines the "invalid attribute" term at the top of the document. It says that the Length field is valid, but the *Value* field is wrong. Since the Length field is valid, the packet can be parsed correctly. So the entire packet is correctly formed. Again, the term "invalid attribute" refers to the *Value* field of an attribute. It has nothing to do with parsing the packet. I really don't know how to make this any clearer. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext