From rdroms.ietf@gmail.com Tue Oct 2 08:37:08 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0681B21F854C for ; Tue, 2 Oct 2012 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhI0TZ1ZRiUM for ; Tue, 2 Oct 2012 08:37:07 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 654CB21F8530 for ; Tue, 2 Oct 2012 08:37:07 -0700 (PDT) Received: by qcac10 with SMTP id c10so4055979qca.31 for ; Tue, 02 Oct 2012 08:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=jIPRarXTolTwVViaaUGrNJnqoaTkpGsO+5WtWnu7ga8=; b=h+9MG2Uaqaxd1Nn1/lpb/Xs9bHX4xHi7Qlgkve5/yFZhCIfsTfP/LR9tpxp+aKLDqh GpDARmUpOM9rR2fo4YQRmY6vhqDUf6zNP/bOh2sjg60c8Gw9/QGXOanG5pay1Q3en3MC vlqsMrRKeZz/YeUY5qP0SJy9MzK20amWUSKYOmQg89uOoQ/r0kLEd5N27EwcUjdiojNL zdkApSFebW+u1N7mQzPJc0ZGHhi7z2WltjdXfX90wNN1jc9CSFTv4M4Vc6BKcTk4Z1C6 sAOobXBPuFzVk3GnIjRdQo/SYgYENw4HgD3YJRji+VhqFEuEvrHv7GV16TboPDpCUuLw ahsg== Received: by 10.49.26.100 with SMTP id k4mr5735502qeg.58.1349192226841; Tue, 02 Oct 2012 08:37:06 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id dz9sm1716645qab.6.2012.10.02.08.37.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 08:37:06 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2012 11:37:07 -0400 Message-Id: To: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:37:08 -0000 draft-ietf-softwire-6rd-radius-attrib-06.txt has been submitted for = publication. As it defines a RADIUS attribute, I'd like to get a review = of the document from aaa-doctors. In particular, is the complex = datatype format of the attribute acceptable, or would some other format = such as String carrying the DHCP 6rd option as opaque data be more = appropriate? - Ralph From bernard_aboba@hotmail.com Tue Oct 2 09:48:26 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC7021F8489 for ; Tue, 2 Oct 2012 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.668 X-Spam-Level: X-Spam-Status: No, score=-101.668 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4scPsTXEmmpv for ; Tue, 2 Oct 2012 09:48:24 -0700 (PDT) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6918A21F847B for ; Tue, 2 Oct 2012 09:48:24 -0700 (PDT) Received: from BLU002-W224 ([65.55.111.72]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 09:48:23 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_97d969b0-f494-4f40-a416-b895623a0d3e_" X-Originating-IP: [131.107.0.125] From: Bernard Aboba To: Ralph Droms , "aaa-doctors@ietf.org" Date: Tue, 2 Oct 2012 09:48:24 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2012 16:48:23.0825 (UTC) FILETIME=[BCABC810:01CDA0BD] Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:48:26 -0000 --_97d969b0-f494-4f40-a416-b895623a0d3e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have some questions about this document.=20 RFC 5080 Section 2.1.1 lays out the requirements for use of a State attribu= te:=20 The only permissible values for a State attribute are values provided=0A= in an Access-Accept=2C Access-Challenge=2C CoA-Request or Disconnect-=0A= Request packet. A RADIUS client MUST use only those values for the=0A= State attribute that it has previously received from a server. An=0A= Access-Request sent as a result of a new or restarted authentication=0A= run MUST NOT include the State attribute=2C even if a State attribute=0A= has previously been received in an Access-Challenge for the same user=0A= and port. This requirement exists to ensure that a State attribute ties back to an au= thenticated RADIUS session. =20 Within the document=2C the flow diagram describes "cooperation between DHCP= and RADIUS": 6rd CE BNG AAA Server=0A= | | |=0A= |-------DHCPDISCOVER------>| |=0A= | |--Access-Request(6rd Attr)-->|=0A= | | |=0A= | |<--Access-Accept(6rd Attr)---|=0A= |<-------DHCPOFFER---------| |=0A= | | |=0A= |--------DHCPREQUEST------>| |=0A= | (6rd Option) | |=0A= |<--------DHCPACK----------| |=0A= | (6rd option) | |=0A= | | |=0A= DHCP RADIUS=0A= Figure 1: the cooperation between DHCP and RADIUS This=0A= diagram neither indicates that the RADIUS Access-Request/Accept =0A= sequence is authenticated=2C nor does it show any previous previous =0A= authenticated RADIUS interaction. It therefore appears to violate the =0A= RFC 5080 requirement.=20 > From: rdroms.ietf@gmail.com > Date: Tue=2C 2 Oct 2012 11:37:07 -0400 > To: aaa-doctors@ietf.org > Subject: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt >=20 > draft-ietf-softwire-6rd-radius-attrib-06.txt has been submitted for publi= cation. As it defines a RADIUS attribute=2C I'd like to get a review of th= e document from aaa-doctors. In particular=2C is the complex datatype form= at of the attribute acceptable=2C or would some other format such as String= carrying the DHCP 6rd option as opaque data be more appropriate? >=20 > - Ralph >=20 > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors = --_97d969b0-f494-4f40-a416-b895623a0d3e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have some questions about this= document.

RFC 5080 Section 2.1.1 lays out the requirements for use= of a State attribute: 

   The only permissible values for a St=
ate attribute are values provided=0A=
   in an Access-Accept=2C Access-Challenge=2C CoA-Request or Disconnect-=0A=
   Request packet.  A RADIUS client MUST use only those values for the=0A=
   State attribute that it has previously received from a server.  An=0A=
   Access-Request sent as a result of a new or restarted authentication=0A=
   run MUST NOT include the State attribute=2C even if a State attribute=0A=
   has previously been received in an Access-Challenge for the same user=0A=
   and port.

This requirement exists to ensure that a State attrib= ute ties back to an authenticated RADIUS session. =3B

Within th= e document=2C the flow diagram describes "cooperation between DHCP and RADI= US":

     6rd CE                       BNG   =
                    AAA Server=0A=
         |                          |                             |=0A=
         |-------DHCPDISCOVER------>=3B|                             |=0A=
         |                          |--Access-Request(6rd Attr)-->=3B|=0A=
         |                          |                             |=0A=
         |                          |<=3B--Access-Accept(6rd Attr)---|=0A=
         |<=3B-------DHCPOFFER---------|                             |=0A=
         |                          |                             |=0A=
         |--------DHCPREQUEST------>=3B|                             |=0A=
         |      (6rd Option)        |                             |=0A=
         |<=3B--------DHCPACK----------|                             |=0A=
         |      (6rd option)        |                             |=0A=
         |                          |                             |=0A=
                   DHCP                         RADIUS=0A=
                Figure 1: the cooperation between DHCP and RADIUS

= This=0A= diagram neither indicates that the RADIUS Access-Request/Accept =0A= sequence is authenticated=2C nor does it show any previous previous =0A= authenticated RADIUS interaction. =3B =3B It therefore appears to v= iolate the =0A= RFC 5080 requirement.



=
>=3B From: rdroms.ietf@gmail.com
>=3B Date: Tue=2C 2 Oct 2012 = 11:37:07 -0400
>=3B To: aaa-doctors@ietf.org
>=3B Subject: [AAA-D= OCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt
>=3B
>=3B d= raft-ietf-softwire-6rd-radius-attrib-06.txt has been submitted for publicat= ion. As it defines a RADIUS attribute=2C I'd like to get a review of the d= ocument from aaa-doctors. In particular=2C is the complex datatype format = of the attribute acceptable=2C or would some other format such as String ca= rrying the DHCP 6rd option as opaque data be more appropriate?
>=3B >=3B - Ralph
>=3B
>=3B _____________________________________= __________
>=3B AAA-DOCTORS mailing list
>=3B AAA-DOCTORS@ietf.or= g
>=3B https://www.ietf.org/mailman/listinfo/aaa-doctors
=
= --_97d969b0-f494-4f40-a416-b895623a0d3e_-- From aland@deployingradius.com Tue Oct 2 11:46:58 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412CB21F8585 for ; Tue, 2 Oct 2012 11:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61K9MbhfmNPH for ; Tue, 2 Oct 2012 11:46:57 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47CEE21F8574 for ; Tue, 2 Oct 2012 11:46:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6EF6A2240E49; Tue, 2 Oct 2012 20:46:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj5Le42mYsFo; Tue, 2 Oct 2012 20:46:20 +0200 (CEST) Received: from Thor.local (37-8-182-23.coucou-networks.fr [37.8.182.23]) by power.freeradius.org (Postfix) with ESMTPSA id 78F2622406BD; Tue, 2 Oct 2012 20:46:19 +0200 (CEST) Message-ID: <506B3687.9050803@deployingradius.com> Date: Tue, 02 Oct 2012 20:46:31 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Oct 2012 12:02:31 -0700 Cc: "aaa-doctors@ietf.org" , draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org, Ralph Droms Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:46:58 -0000 Bernard Aboba wrote: > I have some questions about this document. > > RFC 5080 Section 2.1.1 lays out the requirements for use of a State > attribute: ... > This requirement exists to ensure that a State attribute ties back to an > authenticated RADIUS session. The document references RFC 5080, and says: In the abovementioned scenario, the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17), thus according to [RFC5080] the Access-Request packet MUST contain a State attribute. They seem to have missed the paragraph you quoted. It is immediately above the paragraph requiring State for Authorize Only. > This diagram neither indicates that the RADIUS Access-Request/Accept > sequence is authenticated, nor does it show any previous previous > authenticated RADIUS interaction. It therefore appears to violate the > RFC 5080 requirement. The document repeatedly refers to "authentication", where no authentication is taking place: ... A 6rd configuration request may also be sent in the same message. If the user authentication is approved by the AAA server, There is no "user", and no credentials supplied for authentication. My reading is that State was added solely to satisfy portions of RFC 5080. I think it, and all references to 5080 should be removed from the draft. Since no user authentication is taking place, perhaps a better suggestion would be to allocate a new Service-Type, of IPv6-6rd-Configuration. The Access-Request could contain: Service-Type = IPv6-6rd-Configuration IPv6-6rd-Configuration = ... data ... RADIUS servers should be able to key off of the Service-Type to distinguish 6rd requests from all other RADIUS requests. They can then respond correctly, even though no user credentials are in the request. The draft should also replace the four references to "authentication" on page 4 with "authorization". The format of the IPv6-6rf-Configuration attribute is not ideal. This is OK, as the RADIUS extensions document has not been published. The only suggestions I would have are: - make the IPv4MaskLen field 32 bits long. RFC 6158 Section A.2.1 has this text forbidding 8-bit fields: * Unsigned integers of size other than 32 bits. SHOULD be replaced by an unsigned integer of 32 bits. There is insufficient justification to define a new size of integer. - make it clear that since the subtypes have values, they can appear in any order. e.g. subtype 1,2,3 is OK, but so is subtype order 2,3,1 and 3,2,1. - if new subtypes are envisioned, then an IANA registry for subtypes should be allocated, subject to expert review, or IETF consensus Alan DeKok. From rdroms.ietf@gmail.com Tue Oct 2 13:24:35 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A9B21F85BB for ; Tue, 2 Oct 2012 13:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7uM8d3Ueef8 for ; Tue, 2 Oct 2012 13:24:34 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB82221F849D for ; Tue, 2 Oct 2012 13:24:34 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so1055972qao.10 for ; Tue, 02 Oct 2012 13:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3rJDO5vFmrq0NzHUl7E02FDdzdMeBhp0JGE4XsR8Tz0=; b=uM4Oj6/ratNOYlEDoa0bygXvt4OOL6ozE2hoKIeHGaH691edEI7yA3/ywlI4+MrfYN PHQZTJ4CTT/kZ/ztPj+EhphFAUyMRGOOCrNH8CmmzedZ+olKhutdWJQ9NIHupS6OQLrC 3ytTREON7gikVvje7r0BZx3s8jQVGvbTT9fCNvUJQBUj5S8D5vbWxeLjgzCTV3bSEhrN zTgFugeVe1HXz+Ji3DKtSqLeWATNDWDuqocETp8jQ5Qwl6nJNbvxgcAXU3jrUYOWg+Xn nbw0t+gd9Y6SWP9+KjI8hwdi0TnxTo9er6RGw8VrZMvAJ2Bhaf4hfY2IpLHu3w2sHxkd nFrA== Received: by 10.49.71.77 with SMTP id s13mr7545976qeu.17.1349209474208; Tue, 02 Oct 2012 13:24:34 -0700 (PDT) Received: from rtp-rdroms-8919.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id ca8sm2307425qab.20.2012.10.02.13.24.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 13:24:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: <506B3687.9050803@deployingradius.com> Date: Tue, 2 Oct 2012 16:24:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506B3687.9050803@deployingradius.com> To: draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org X-Mailer: Apple Mail (2.1283) Cc: aaa-doctors@ietf.org, Softwire Chairs , Alan DeKok Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 20:24:35 -0000 Bernard, Alan - thanks for your feedback on = draft-ietf-softwire-6rd-radius-attrib-06 Authors - please review this feedback and revise your document = appropriately. Once the aaa-doctors are satisfied with the revisions, = I'll proceed with IETF last call and IESG review. =20 - Ralph On Oct 2, 2012, at 2:46 PM 10/2/12, Alan DeKok wrote: > Bernard Aboba wrote: >> I have some questions about this document. >>=20 >> RFC 5080 Section 2.1.1 lays out the requirements for use of a State >> attribute: > ... >> This requirement exists to ensure that a State attribute ties back to = an >> authenticated RADIUS session.=20 >=20 > The document references RFC 5080, and says: >=20 > In the abovementioned scenario, the Access-Request packet contains a > Service-Type attribute with the value Authorize Only (17), thus > according to [RFC5080] the Access-Request packet MUST contain a = State > attribute. >=20 > They seem to have missed the paragraph you quoted. It is immediately > above the paragraph requiring State for Authorize Only. >=20 >> This diagram neither indicates that the RADIUS Access-Request/Accept >> sequence is authenticated, nor does it show any previous previous >> authenticated RADIUS interaction. It therefore appears to violate = the >> RFC 5080 requirement. >=20 > The document repeatedly refers to "authentication", where no > authentication is taking place: >=20 > ... A 6rd configuration request may > also be sent in the same message. If the user authentication is > approved by the AAA server, >=20 > There is no "user", and no credentials supplied for authentication. >=20 > My reading is that State was added solely to satisfy portions of RFC > 5080. I think it, and all references to 5080 should be removed from = the > draft. >=20 > Since no user authentication is taking place, perhaps a better > suggestion would be to allocate a new Service-Type, of > IPv6-6rd-Configuration. The Access-Request could contain: >=20 > Service-Type =3D IPv6-6rd-Configuration > IPv6-6rd-Configuration =3D ... data ... >=20 > RADIUS servers should be able to key off of the Service-Type to > distinguish 6rd requests from all other RADIUS requests. They can = then > respond correctly, even though no user credentials are in the request. >=20 > The draft should also replace the four references to "authentication" > on page 4 with "authorization". >=20 > The format of the IPv6-6rf-Configuration attribute is not ideal. = This > is OK, as the RADIUS extensions document has not been published. The > only suggestions I would have are: >=20 > - make the IPv4MaskLen field 32 bits long. RFC 6158 Section A.2.1 has > this text forbidding 8-bit fields: >=20 > * Unsigned integers of size other than 32 bits. > SHOULD be replaced by an unsigned integer of 32 bits. There is > insufficient justification to define a new size of integer. >=20 > - make it clear that since the subtypes have values, they can appear = in > any order. e.g. subtype 1,2,3 is OK, but so is subtype order 2,3,1 = and > 3,2,1. >=20 > - if new subtypes are envisioned, then an IANA registry for subtypes > should be allocated, subject to expert review, or IETF consensus >=20 > Alan DeKok. From bclaise@cisco.com Fri Oct 5 00:28:28 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9321F8467; Fri, 5 Oct 2012 00:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.702 X-Spam-Level: X-Spam-Status: No, score=-8.702 tagged_above=-999 required=5 tests=[AWL=1.897, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs7hm9IIFevD; Fri, 5 Oct 2012 00:28:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id ECBD721F8437; Fri, 5 Oct 2012 00:28:26 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q957SKGb025985; Fri, 5 Oct 2012 09:28:21 +0200 (CEST) Received: from [10.55.81.34] (dhcp-10-55-81-34.cisco.com [10.55.81.34]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q957SJwI011192; Fri, 5 Oct 2012 09:28:20 +0200 (CEST) Message-ID: <506E8C13.40700@cisco.com> Date: Fri, 05 Oct 2012 09:28:19 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20121004215637.3452.17430.idtracker@ietfa.amsl.com> In-Reply-To: <20121004215637.3452.17430.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121004215637.3452.17430.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AAA-DOCTORS] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2012-10-11 IESG Teleconference X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 07:28:28 -0000 Dear all, Please find below the agenda of the October 11th IESG telechat. Please send your questions, comments and concerns before October 11 COB. Thanks and Regards, Benoit. ============================================= INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2012-10-11 IESG Teleconference This agenda was generated at 2012-10-04 14:56:09 PDT Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-storm-iscsi-cons-07 iSCSI Protocol (Consolidated) (Proposed Standard) Note: David Black (david.black@emc.com) is the document shepherd. Token: Martin Stiemerling o draft-ietf-fecframe-ldpc-03 Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME (Proposed Standard) Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd Token: Martin Stiemerling o draft-ietf-manet-olsrv2-16 The Optimized Link State Routing Protocol version 2 (Proposed Standard) Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-6man-dad-proxy-05 Duplicate Address Detection Proxy (Proposed Standard) Note: Bob Hinden (bob.hinden@gmail.com) is the Document Shepherd. Token: Brian Haberman o draft-ietf-v6ops-ivi-icmp-address-06 Stateless Source Address Mapping for ICMPv6 Packets (Best Current Practice) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ronald Bonica o draft-ietf-dnsext-rfc6195bis-04 Domain Name System (DNS) IANA Considerations (Best Current Practice) Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd. Token: Ralph Droms o draft-ietf-sipcore-proxy-feature-11 Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP) (Proposed Standard) Note: Paul Kyzivat (pkyzivat@alum.mit.edu) is the Document Shepherd Token: Robert Sparks o draft-ietf-abfab-gss-eap-naming-06 Name Attributes for the GSS-API EAP mechanism (Proposed Standard) Token: Stephen Farrell o draft-ietf-6man-udpchecksums-04 UDP Checksums for Tunneled Packets (Proposed Standard) Token: Brian Haberman 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-fecframe-pseudo-cdp-04 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework (Informational) Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd Token: Martin Stiemerling o draft-ietf-6man-udpzero-06 IPv6 UDP Checksum Considerations (Informational) Token: Brian Haberman 3.1.2 Returning Items o draft-ietf-avtext-splicing-for-rtp-09 Content Splicing for RTP Sessions (Informational) Note: Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd. Token: Gonzalo Camarillo 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o conflict-review-mme-trill-fcoe-01 IETF conflict review for draft-mme-trill-fcoe (None) Token: Ralph Droms 3.3.2 Returning Items NONE 3.3.3 For Action o conflict-review-pornin-deterministic-dsa-00 IETF conflict review for draft-pornin-deterministic-dsa (None) Token: Sean Turner 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Bidirectional Forwarding Detection (bfd) 4.2.2 Proposed for Approval o Operations and Management Area Working Group (opsawg) From aland@freeradius.org Sat Oct 6 16:32:09 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58C021F84C4 for ; Sat, 6 Oct 2012 16:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9nezKeetoxw for ; Sat, 6 Oct 2012 16:32:09 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50A6F21F84BF for ; Sat, 6 Oct 2012 16:32:08 -0700 (PDT) Received: by power.freeradius.org (Postfix, from userid 1000) id A10132240D6A; Sun, 7 Oct 2012 01:32:06 +0200 (CEST) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.2) Message-Id: <20121006233206.A10132240D6A@power.freeradius.org> Date: Sun, 7 Oct 2012 01:32:06 +0200 (CEST) Subject: [AAA-DOCTORS] Automatic tech report for Sun Oct 7 01:32:06 CEST 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 23:32:09 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-arch-03 Active draft-ietf-abfab-gss-eap-09 In IESG processing - ID Tracker state draft-ietf-dhc-dhcpv6-radius-opt-01 Active draft-ietf-netmod-system-mgmt-03 Active draft-ietf-softwire-6rd-radius-attrib-06 In IESG processing - ID Tracker state From jiangsheng@huawei.com Sun Oct 7 20:04:24 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD58D21F849B for ; Sun, 7 Oct 2012 20:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN8PAJZYpl10 for ; Sun, 7 Oct 2012 20:04:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 479EB21F867E for ; Sun, 7 Oct 2012 20:04:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKJ68427; Mon, 08 Oct 2012 03:04:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 04:04:08 +0100 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 04:04:18 +0100 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Mon, 8 Oct 2012 11:04:14 +0800 From: Sheng Jiang To: Ralph Droms , "draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org" Thread-Topic: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt Thread-Index: AQHNoM5FBqSX0AFThUqAIbLEQ1aCsZel8CCAgAjA3UA= Date: Mon, 8 Oct 2012 03:04:14 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F56F8F@szxeml545-mbx.china.huawei.com> References: <506B3687.9050803@deployingradius.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 08 Oct 2012 00:33:17 -0700 Cc: "aaa-doctors@ietf.org" , Softwire Chairs , Alan DeKok Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 03:04:25 -0000 QmVybmFyZCwgQWxhbiBhbmQgUmFscGggLSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21t ZW50cy4gV2UgYXJlIHdvcmtpbmcgb24gdGhlIHJldmlzaW9uIGFjY29yZGluZ2x5LiBXZSB3aWxs IGFzayB5b3VyIGNvbmZpcm1hdGlvbiBiZWZvcmUgc3VibWlzc2lvbiBhIG5ldyB2ZXJzaW9uLiA6 KQ0KDQpNYW55IHRoYW5rcyBhbmQgYmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBSYWxwaCBEcm9tcyBbbWFpbHRvOnJkcm9tcy5pZXRm QGdtYWlsLmNvbV0NCj5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDMsIDIwMTIgNDoyNCBBTQ0K PlRvOiBkcmFmdC1pZXRmLXNvZnR3aXJlLTZyZC1yYWRpdXMtYXR0cmliQHRvb2xzLmlldGYub3Jn DQo+Q2M6IFNvZnR3aXJlIENoYWlyczsgQmVybmFyZCBBYm9iYTsgYWFhLWRvY3RvcnNAaWV0Zi5v cmc7IEFsYW4gRGVLb2sNCj5TdWJqZWN0OiBSZTogW0FBQS1ET0NUT1JTXSBkcmFmdC1pZXRmLXNv ZnR3aXJlLTZyZC1yYWRpdXMtYXR0cmliLTA2LnR4dA0KPg0KPkJlcm5hcmQsIEFsYW4gLSB0aGFu a3MgZm9yIHlvdXIgZmVlZGJhY2sgb24NCj5kcmFmdC1pZXRmLXNvZnR3aXJlLTZyZC1yYWRpdXMt YXR0cmliLTA2DQo+DQo+QXV0aG9ycyAtIHBsZWFzZSByZXZpZXcgdGhpcyBmZWVkYmFjayBhbmQg cmV2aXNlIHlvdXIgZG9jdW1lbnQgYXBwcm9wcmlhdGVseS4NCj5PbmNlIHRoZSBhYWEtZG9jdG9y cyBhcmUgc2F0aXNmaWVkIHdpdGggdGhlIHJldmlzaW9ucywgSSdsbCBwcm9jZWVkIHdpdGggSUVU Rg0KPmxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcuDQo+DQo+LSBSYWxwaA0KPg0KPk9uIE9jdCAy LCAyMDEyLCBhdCAyOjQ2IFBNIDEwLzIvMTIsIEFsYW4gRGVLb2sgd3JvdGU6DQo+DQo+PiBCZXJu YXJkIEFib2JhIHdyb3RlOg0KPj4+IEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGlzIGRv Y3VtZW50Lg0KPj4+DQo+Pj4gUkZDIDUwODAgU2VjdGlvbiAyLjEuMSBsYXlzIG91dCB0aGUgcmVx dWlyZW1lbnRzIGZvciB1c2Ugb2YgYSBTdGF0ZQ0KPj4+IGF0dHJpYnV0ZToNCj4+IC4uLg0KPj4+ IFRoaXMgcmVxdWlyZW1lbnQgZXhpc3RzIHRvIGVuc3VyZSB0aGF0IGEgU3RhdGUgYXR0cmlidXRl IHRpZXMgYmFjayB0byBhbg0KPj4+IGF1dGhlbnRpY2F0ZWQgUkFESVVTIHNlc3Npb24uDQo+Pg0K Pj4gIFRoZSBkb2N1bWVudCByZWZlcmVuY2VzIFJGQyA1MDgwLCBhbmQgc2F5czoNCj4+DQo+PiAg IEluIHRoZSBhYm92ZW1lbnRpb25lZCBzY2VuYXJpbywgdGhlIEFjY2Vzcy1SZXF1ZXN0IHBhY2tl dCBjb250YWlucyBhDQo+PiAgIFNlcnZpY2UtVHlwZSBhdHRyaWJ1dGUgd2l0aCB0aGUgdmFsdWUg QXV0aG9yaXplIE9ubHkgKDE3KSwgdGh1cw0KPj4gICBhY2NvcmRpbmcgdG8gW1JGQzUwODBdIHRo ZSBBY2Nlc3MtUmVxdWVzdCBwYWNrZXQgTVVTVCBjb250YWluIGEgU3RhdGUNCj4+ICAgYXR0cmli dXRlLg0KPj4NCj4+ICBUaGV5IHNlZW0gdG8gaGF2ZSBtaXNzZWQgdGhlIHBhcmFncmFwaCB5b3Ug cXVvdGVkLiAgSXQgaXMgaW1tZWRpYXRlbHkNCj4+IGFib3ZlIHRoZSBwYXJhZ3JhcGggcmVxdWly aW5nIFN0YXRlIGZvciBBdXRob3JpemUgT25seS4NCj4+DQo+Pj4gVGhpcyBkaWFncmFtIG5laXRo ZXIgaW5kaWNhdGVzIHRoYXQgdGhlIFJBRElVUyBBY2Nlc3MtUmVxdWVzdC9BY2NlcHQNCj4+PiBz ZXF1ZW5jZSBpcyBhdXRoZW50aWNhdGVkLCBub3IgZG9lcyBpdCBzaG93IGFueSBwcmV2aW91cyBw cmV2aW91cw0KPj4+IGF1dGhlbnRpY2F0ZWQgUkFESVVTIGludGVyYWN0aW9uLiAgIEl0IHRoZXJl Zm9yZSBhcHBlYXJzIHRvIHZpb2xhdGUgdGhlDQo+Pj4gUkZDIDUwODAgcmVxdWlyZW1lbnQuDQo+ Pg0KPj4gIFRoZSBkb2N1bWVudCByZXBlYXRlZGx5IHJlZmVycyB0byAiYXV0aGVudGljYXRpb24i LCB3aGVyZSBubw0KPj4gYXV0aGVudGljYXRpb24gaXMgdGFraW5nIHBsYWNlOg0KPj4NCj4+ICAg Li4uIEEgNnJkIGNvbmZpZ3VyYXRpb24gcmVxdWVzdCBtYXkNCj4+ICAgYWxzbyBiZSBzZW50IGlu IHRoZSBzYW1lIG1lc3NhZ2UuIElmIHRoZSB1c2VyIGF1dGhlbnRpY2F0aW9uIGlzDQo+PiAgIGFw cHJvdmVkIGJ5IHRoZSBBQUEgc2VydmVyLA0KPj4NCj4+ICBUaGVyZSBpcyBubyAidXNlciIsIGFu ZCBubyBjcmVkZW50aWFscyBzdXBwbGllZCBmb3IgYXV0aGVudGljYXRpb24uDQo+Pg0KPj4gIE15 IHJlYWRpbmcgaXMgdGhhdCBTdGF0ZSB3YXMgYWRkZWQgc29sZWx5IHRvIHNhdGlzZnkgcG9ydGlv bnMgb2YgUkZDDQo+PiA1MDgwLiAgSSB0aGluayBpdCwgYW5kIGFsbCByZWZlcmVuY2VzIHRvIDUw ODAgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUNCj4+IGRyYWZ0Lg0KPj4NCj4+ICBTaW5jZSBu byB1c2VyIGF1dGhlbnRpY2F0aW9uIGlzIHRha2luZyBwbGFjZSwgcGVyaGFwcyBhIGJldHRlcg0K Pj4gc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBhbGxvY2F0ZSBhIG5ldyBTZXJ2aWNlLVR5cGUsIG9m DQo+PiBJUHY2LTZyZC1Db25maWd1cmF0aW9uLiAgVGhlIEFjY2Vzcy1SZXF1ZXN0IGNvdWxkIGNv bnRhaW46DQo+Pg0KPj4gCVNlcnZpY2UtVHlwZSA9IElQdjYtNnJkLUNvbmZpZ3VyYXRpb24NCj4+ IAlJUHY2LTZyZC1Db25maWd1cmF0aW9uID0gLi4uIGRhdGEgLi4uDQo+Pg0KPj4gIFJBRElVUyBz ZXJ2ZXJzIHNob3VsZCBiZSBhYmxlIHRvIGtleSBvZmYgb2YgdGhlIFNlcnZpY2UtVHlwZSB0bw0K Pj4gZGlzdGluZ3Vpc2ggNnJkIHJlcXVlc3RzIGZyb20gYWxsIG90aGVyIFJBRElVUyByZXF1ZXN0 cy4gIFRoZXkgY2FuIHRoZW4NCj4+IHJlc3BvbmQgY29ycmVjdGx5LCBldmVuIHRob3VnaCBubyB1 c2VyIGNyZWRlbnRpYWxzIGFyZSBpbiB0aGUgcmVxdWVzdC4NCj4+DQo+PiAgVGhlIGRyYWZ0IHNo b3VsZCBhbHNvIHJlcGxhY2UgdGhlIGZvdXIgcmVmZXJlbmNlcyB0byAiYXV0aGVudGljYXRpb24i DQo+PiBvbiBwYWdlIDQgd2l0aCAiYXV0aG9yaXphdGlvbiIuDQo+Pg0KPj4gIFRoZSBmb3JtYXQg b2YgdGhlIElQdjYtNnJmLUNvbmZpZ3VyYXRpb24gYXR0cmlidXRlIGlzIG5vdCBpZGVhbC4gIFRo aXMNCj4+IGlzIE9LLCBhcyB0aGUgUkFESVVTIGV4dGVuc2lvbnMgZG9jdW1lbnQgaGFzIG5vdCBi ZWVuIHB1Ymxpc2hlZC4gIFRoZQ0KPj4gb25seSBzdWdnZXN0aW9ucyBJIHdvdWxkIGhhdmUgYXJl Og0KPj4NCj4+IC0gbWFrZSB0aGUgSVB2NE1hc2tMZW4gZmllbGQgMzIgYml0cyBsb25nLiAgUkZD IDYxNTggU2VjdGlvbiBBLjIuMSBoYXMNCj4+IHRoaXMgdGV4dCBmb3JiaWRkaW5nIDgtYml0IGZp ZWxkczoNCj4+DQo+PiAgICAgICogVW5zaWduZWQgaW50ZWdlcnMgb2Ygc2l6ZSBvdGhlciB0aGFu IDMyIGJpdHMuDQo+PiAgICAgICAgU0hPVUxEIGJlIHJlcGxhY2VkIGJ5IGFuIHVuc2lnbmVkIGlu dGVnZXIgb2YgMzIgYml0cy4gIFRoZXJlIGlzDQo+PiAgICAgICAgaW5zdWZmaWNpZW50IGp1c3Rp ZmljYXRpb24gdG8gZGVmaW5lIGEgbmV3IHNpemUgb2YgaW50ZWdlci4NCj4+DQo+PiAtIG1ha2Ug aXQgY2xlYXIgdGhhdCBzaW5jZSB0aGUgc3VidHlwZXMgaGF2ZSB2YWx1ZXMsIHRoZXkgY2FuIGFw cGVhciBpbg0KPj4gYW55IG9yZGVyLiAgZS5nLiBzdWJ0eXBlIDEsMiwzIGlzIE9LLCBidXQgc28g aXMgc3VidHlwZSBvcmRlciAyLDMsMSBhbmQNCj4+IDMsMiwxLg0KPj4NCj4+IC0gaWYgbmV3IHN1 YnR5cGVzIGFyZSBlbnZpc2lvbmVkLCB0aGVuIGFuIElBTkEgcmVnaXN0cnkgZm9yIHN1YnR5cGVz DQo+PiBzaG91bGQgYmUgYWxsb2NhdGVkLCBzdWJqZWN0IHRvIGV4cGVydCByZXZpZXcsIG9yIElF VEYgY29uc2Vuc3VzDQo+Pg0KPj4gIEFsYW4gRGVLb2suDQoNCg== From leaf.y.yeh@huawei.com Mon Oct 8 04:48:43 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BF121F8625 for ; Mon, 8 Oct 2012 04:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUXk1sGa1W6q for ; Mon, 8 Oct 2012 04:48:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF13721F8620 for ; Mon, 8 Oct 2012 04:48:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALK75288; Mon, 08 Oct 2012 11:48:40 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 12:48:10 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 12:48:34 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.192]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 8 Oct 2012 19:48:28 +0800 From: Leaf yeh To: Alan DeKok , Bernard Aboba Thread-Topic: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt Thread-Index: AQHNoLPLuS2Ult0dNUCV/uJZ6N/lWJels/UAgAAhAYCACVYWYA== Date: Mon, 8 Oct 2012 11:48:28 +0000 Message-ID: References: <506B3687.9050803@deployingradius.com> In-Reply-To: <506B3687.9050803@deployingradius.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "aaa-doctors@ietf.org" , "draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org" , Ralph Droms Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:48:43 -0000 a. Alan - The format of the IPv6-6rf-Configuration attribute is not ide= al. This is OK, as the RADIUS extensions document has not been published... - make it clear that since the subtypes have values, they can appear in any order. e.g. subtype 1,2,3 is OK, but so is subtype order 2,3,1 and 3,2,1. I tend to suggest draft-ietf-softwire-6rd-radius-attrib-06 to adopt the dat= a type of TLV newly defined in draft-ietf-radext-radius-extensions. b. draft-ietf-softwire-6rd-radius-attrib-06 - ... the Access-Request p= acket contains a Service-Type attribute with the value Authorize Only (17), thus according to [RFC5080] the Access-Request packet MUST contain a State attribute. Alan - There is no "user", and no credentials supplied for authenti= cation. My reading is that State was added solely to satisfy portions of RFC 5080. I think it, and all references to 5080 should be removed from the draft. Since no user authentication is taking place, perhaps a better suggestion would be to allocate a new Service-Type, of IPv6-6rd-Configuration. The Access-Request could contain: Service-Type =3D IPv6-6rd-Configuration IPv6-6rd-Configuration =3D ... data ... RADIUS servers should be able to key off of the Service-Type to distinguish 6rd requests from all other RADIUS requests. They can then respond correctly, even though no user credentials are in the request. There is almost the same description in section 3 of RFC 6519. Quoted as fo= llows: 'In the scenario depicted in Figure 2, the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17); thus, according to [RFC5080], the Access-Request packet MUST contain a State attribute.' Is it an Errata here? c. IPv6-6rd-Configuration sounds not in the category of Service-Type (6) pe= r the following records @ http://www.iana.org/assignments/radius-types/radi= us-types.xml. 1 Login =20 2 Framed =20 3 Callback Login =20 4 Callback Framed =20 5 Outbound =20 6 Administrative =20 7 NAS Prompt =20 8 Authenticate Only =20 9 Callback NAS Prompt =20 10 Call Check =20 11 Callback Administrative =20 12 Voice=20 13 Fax 14 Modem Relay 15 IAPP-Register 16 IAPP-AP-Check 17 Authorize Only [RFC3576]=20 18 Framed-Management Do we really find the suitable registry for the attribute of 6rd Configurat= ion? d. How about replace the type name of this newly designed attribute to be '= 6rd-configuration'? Best Regards, Leaf -----Original Message----- From: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On= Behalf Of Alan DeKok Sent: Wednesday, October 03, 2012 2:47 AM To: Bernard Aboba Cc: aaa-doctors@ietf.org; draft-ietf-softwire-6rd-radius-attrib@tools.ietf.= org; Ralph Droms Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt Bernard Aboba wrote: > I have some questions about this document. >=20 > RFC 5080 Section 2.1.1 lays out the requirements for use of a State > attribute: ... > This requirement exists to ensure that a State attribute ties back to an > authenticated RADIUS session.=20 The document references RFC 5080, and says: In the abovementioned scenario, the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17), thus according to [RFC5080] the Access-Request packet MUST contain a State attribute. They seem to have missed the paragraph you quoted. It is immediately above the paragraph requiring State for Authorize Only. > This diagram neither indicates that the RADIUS Access-Request/Accept > sequence is authenticated, nor does it show any previous previous > authenticated RADIUS interaction. It therefore appears to violate the > RFC 5080 requirement. The document repeatedly refers to "authentication", where no authentication is taking place: ... A 6rd configuration request may also be sent in the same message. If the user authentication is approved by the AAA server, There is no "user", and no credentials supplied for authentication. My reading is that State was added solely to satisfy portions of RFC 5080. I think it, and all references to 5080 should be removed from the draft. Since no user authentication is taking place, perhaps a better suggestion would be to allocate a new Service-Type, of IPv6-6rd-Configuration. The Access-Request could contain: Service-Type =3D IPv6-6rd-Configuration IPv6-6rd-Configuration =3D ... data ... RADIUS servers should be able to key off of the Service-Type to distinguish 6rd requests from all other RADIUS requests. They can then respond correctly, even though no user credentials are in the request. The draft should also replace the four references to "authentication" on page 4 with "authorization". The format of the IPv6-6rf-Configuration attribute is not ideal. This is OK, as the RADIUS extensions document has not been published. The only suggestions I would have are: - make the IPv4MaskLen field 32 bits long. RFC 6158 Section A.2.1 has this text forbidding 8-bit fields: * Unsigned integers of size other than 32 bits. SHOULD be replaced by an unsigned integer of 32 bits. There is insufficient justification to define a new size of integer. - make it clear that since the subtypes have values, they can appear in any order. e.g. subtype 1,2,3 is OK, but so is subtype order 2,3,1 and 3,2,1. - if new subtypes are envisioned, then an IANA registry for subtypes should be allocated, subject to expert review, or IETF consensus Alan DeKok. _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors From aland@deployingradius.com Mon Oct 8 05:46:28 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C421F8776 for ; Mon, 8 Oct 2012 05:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuXUKcHfRJ9H for ; Mon, 8 Oct 2012 05:46:27 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E8EFC21F875B for ; Mon, 8 Oct 2012 05:46:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1E54A2240B9C; Mon, 8 Oct 2012 14:46:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdRr+LUTZXmp; Mon, 8 Oct 2012 14:46:22 +0200 (CEST) Received: from Thor.local (206-47-95-94.dsl.ncf.ca [206.47.95.94]) by power.freeradius.org (Postfix) with ESMTPSA id 4E0F322406F6; Mon, 8 Oct 2012 14:46:21 +0200 (CEST) Message-ID: <5072CB3B.40503@deployingradius.com> Date: Mon, 08 Oct 2012 08:46:51 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <506B3687.9050803@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "aaa-doctors@ietf.org" , "draft-ietf-softwire-6rd-radius-attrib@tools.ietf.org" , Ralph Droms Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-6rd-radius-attrib-06.txt X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 12:46:28 -0000 Leaf yeh wrote: > I tend to suggest draft-ietf-softwire-6rd-radius-attrib-06 to adopt the data type of TLV newly defined in draft-ietf-radext-radius-extensions. The extensions document isn't published, so this draft can't use the TLV data type. However, it can use the *format*, which is OK. > There is almost the same description in section 3 of RFC 6519. Quoted as follows: 'In the scenario depicted in Figure 2, the Access-Request packet > contains a Service-Type attribute with the value Authorize Only (17); > thus, according to [RFC5080], the Access-Request packet MUST contain > a State attribute.' Is it an Errata here? I submitted one. It's wrong. > c. IPv6-6rd-Configuration sounds not in the category of Service-Type (6) per the following records @ http://www.iana.org/assignments/radius-types/radius-types.xml. ... > Do we really find the suitable registry for the attribute of 6rd Configuration? I suggest using "Call Check". Alan DeKok. From bclaise@cisco.com Mon Oct 8 15:32:46 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC9D21F87BF for ; Mon, 8 Oct 2012 15:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.769 X-Spam-Level: X-Spam-Status: No, score=-8.769 tagged_above=-999 required=5 tests=[AWL=1.830, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2eWL0nc1tej for ; Mon, 8 Oct 2012 15:32:41 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7F121F87BE for ; Mon, 8 Oct 2012 15:32:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q98MWefU000324 for ; Tue, 9 Oct 2012 00:32:40 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q98MWcMl009767 for ; Tue, 9 Oct 2012 00:32:38 +0200 (CEST) Message-ID: <50735486.5080606@cisco.com> Date: Tue, 09 Oct 2012 00:32:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AAA-DOCTORS] draft-ietf-abfab-gss-eap-naming-06 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 22:32:46 -0000 Dear all, draft-ietf-abfab-gss-eap-naming-06, currently in IESG review, speaks of RADIUS. Can an AAA expert have a look if there are any concerns with that document? Regards, Benoit. From aland@freeradius.org Sat Oct 13 16:32:09 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF951F0381 for ; Sat, 13 Oct 2012 16:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx5wXkS55uZy for ; Sat, 13 Oct 2012 16:32:09 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E64521F844E for ; Sat, 13 Oct 2012 16:32:08 -0700 (PDT) Received: by power.freeradius.org (Postfix, from userid 1000) id AE2902240314; Sun, 14 Oct 2012 01:32:06 +0200 (CEST) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.2) Message-Id: <20121013233206.AE2902240314@power.freeradius.org> Date: Sun, 14 Oct 2012 01:32:06 +0200 (CEST) Subject: [AAA-DOCTORS] Automatic tech report for Sun Oct 14 01:32:06 CEST 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 23:32:09 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-arch-03 Active draft-ietf-abfab-gss-eap-09 In IESG processing - ID Tracker state draft-ietf-dhc-dhcpv6-radius-opt-01 Active draft-ietf-netmod-system-mgmt-03 Active draft-ietf-softwire-6rd-radius-attrib-07 In IESG processing - ID Tracker state From aland@deployingradius.com Sun Oct 14 04:12:58 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB6E21F8480 for ; Sun, 14 Oct 2012 04:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMj0FYPi9LI5 for ; Sun, 14 Oct 2012 04:12:58 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B07BF21F8459 for ; Sun, 14 Oct 2012 04:12:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6653F224029E; Sun, 14 Oct 2012 13:12:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhtli-qRq5Yf; Sun, 14 Oct 2012 13:12:54 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id 1CD642240274; Sun, 14 Oct 2012 13:12:54 +0200 (CEST) Message-ID: <507A9E35.1010401@deployingradius.com> Date: Sun, 14 Oct 2012 13:12:53 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise References: <50735486.5080606@cisco.com> In-Reply-To: <50735486.5080606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "aaa-doctors@ietf.org" Subject: Re: [AAA-DOCTORS] draft-ietf-abfab-gss-eap-naming-06 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 11:12:58 -0000 Benoit Claise wrote: > Dear all, > > draft-ietf-abfab-gss-eap-naming-06, currently in IESG review, speaks of > RADIUS. > Can an AAA expert have a look if there are any concerns with that document? It references RADIUS, but doesn't really use RADIUS. I think it's OK. Alan DeKok. From bclaise@cisco.com Fri Oct 19 06:21:33 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BC921F868A; Fri, 19 Oct 2012 06:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmtBO0phhMgw; Fri, 19 Oct 2012 06:21:30 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id CC6DD21F8686; Fri, 19 Oct 2012 06:21:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9JDLTPv017842; Fri, 19 Oct 2012 09:21:30 -0400 (EDT) Received: from [10.21.166.15] ([10.21.166.15]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9JDLSJJ022757; Fri, 19 Oct 2012 09:21:29 -0400 (EDT) Message-ID: <508153D9.6020705@cisco.com> Date: Fri, 19 Oct 2012 06:21:29 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20121019001319.31258.25924.idtracker@ietfa.amsl.com> In-Reply-To: <20121019001319.31258.25924.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121019001319.31258.25924.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [AAA-DOCTORS] Fwd: PRELIMINARY Agenda and Package for the October 25, 2012 IESG Teleconference X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:21:33 -0000 Dear all, Please find below the agenda of the October25th IESG telechat. Please send your questions, comments and concerns before October 24th COB. Regards, Benoit -------- Original Message -------- 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-ccamp-rfc5787bis-06 ASON Routing for OSPFv2 Protocols (Proposed Standard) Note: Deborah Brungard (dbrungard@att.com) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-ccamp-gmpls-ted-mib-14 Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS (Proposed Standard) Note: Lou Berger (lberger@labn.net) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-appsawg-media-type-suffix-regs-06 Additional Media Type Structured Syntax Suffixes (Proposed Standard) Note: Murray Kucherawy is the document shepherd. Token: Barry Leiba o draft-ietf-pkix-rfc5280-clarifications-10 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Proposed Standard) Note: Steve Kent (kent@bbn.com) is the Document Shepherd Token: Sean Turner o draft-ietf-dhc-client-id-06 Client Identifier Option in DHCP Server Replies (Proposed Standard) Note: Ted Lemon (Ted.Lemon@nominum.com) is the Document Shepherd. Token: Ralph Droms o draft-ietf-geopriv-local-civic-09 Specifying Civic Address Extensions in PIDF-LO (Proposed Standard) Note: Alissa Cooper (acooper@cdt.org) is the document shepherd. Token: Robert Sparks 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-snell-http-prefer-15 Prefer Header for HTTP (Proposed Standard) Note: Mark Nottingham is the document shepherd. Token: Barry Leiba o draft-gp-intarea-obsolete-ipv4-options-iana-02 Formally Deprecating some IPv4 Options (Proposed Standard) Note: Scott Bradner (sob@harvard.edu) is the document shepherd. Token: Ronald Bonica 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-softwire-dslite-deployment-06 Deployment Considerations for Dual-Stack Lite (Informational) Note: Yong Cui (cuiyong@tsinghua.edu.cn) is the Document Shepherd. Token: Ralph Droms o draft-ietf-softwire-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions (Informational) Note: Yong Cui (cuiyong@tsinghua.edu.cn) is the Document Shepherd. Token: Ralph Droms 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o conflict-review-secure-cookie-session-protocol-00 IETF conflict review for draft-secure-cookie-session-protocol (None) Token: Barry Leiba 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Bidirectional Forwarding Detection (bfd) From aland@freeradius.org Sat Oct 20 16:32:09 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6286B21F891C for ; Sat, 20 Oct 2012 16:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+g790WZv6K0 for ; Sat, 20 Oct 2012 16:32:09 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D35A021F87DD for ; Sat, 20 Oct 2012 16:32:08 -0700 (PDT) Received: by power.freeradius.org (Postfix, from userid 1000) id 585B92240C73; Sun, 21 Oct 2012 01:32:06 +0200 (CEST) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.2) Message-Id: <20121020233206.585B92240C73@power.freeradius.org> Date: Sun, 21 Oct 2012 01:32:06 +0200 (CEST) Subject: [AAA-DOCTORS] Automatic tech report for Sun Oct 21 01:32:06 CEST 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 23:32:09 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-arch-03 Active draft-ietf-abfab-gss-eap-09 In IESG processing - ID Tracker state draft-ietf-dhc-dhcpv6-radius-opt-02 Active draft-ietf-netmod-system-mgmt-03 Active draft-ietf-softwire-6rd-radius-attrib-07 In IESG processing - ID Tracker state From bclaise@cisco.com Fri Oct 26 05:04:38 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D58021F84DF for ; Fri, 26 Oct 2012 05:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.412 X-Spam-Level: X-Spam-Status: No, score=-9.412 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mfSVXHaVNgS for ; Fri, 26 Oct 2012 05:04:37 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35821F84D2 for ; Fri, 26 Oct 2012 05:04:37 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9QC1ZfV021597 for ; Fri, 26 Oct 2012 14:01:35 +0200 (CEST) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9QC1YK7002290 for ; Fri, 26 Oct 2012 14:01:34 +0200 (CEST) Message-ID: <508A7B9F.6010901@cisco.com> Date: Fri, 26 Oct 2012 14:01:35 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" References: <80A0822C5E9A4440A5117C2F4CD36A64045094C3@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64045094C3@DEMUEXC006.nsn-intra.net> X-Forwarded-Message-Id: <80A0822C5E9A4440A5117C2F4CD36A64045094C3@DEMUEXC006.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------080505070209040805040608" Subject: [AAA-DOCTORS] Fwd: Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 12:04:38 -0000 This is a multi-part message in MIME format. --------------080505070209040805040608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit AAA doctors, I won't be able to participate to the AAA lunch, traditionally planned on Thursday, as I have to be in the COMAN side discussion. Sorry about that. Regards, Benoit. -------- Original Message -------- Subject: Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00 Date: Mon, 22 Oct 2012 12:58:02 +0200 From: Ersue, Mehmet (NSN - DE/Munich) To: CC: ext Benoit Claise Hi All, we planned a Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00. Topics will -02 draft in general, constrained device classes, class of networks in focus, management of constrainedness and the requirements section, etc. PS: This is just an adhoc discussion. There will be no jabber, no recording. I will provide some minutes. PS2: The room request has been approved but the IETF secretary did not assign a room yet. Cheers, Mehmet --------------080505070209040805040608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit AAA doctors,

I won't be able to participate to the AAA lunch, traditionally planned on Thursday, as I have to be in the COMAN side discussion.
Sorry about that.

Regards, Benoit.

-------- Original Message --------
Subject: Coman side discussion on November 8th, 2012 Thursday 11:30 - 13:00
Date: Mon, 22 Oct 2012 12:58:02 +0200
From: Ersue, Mehmet (NSN - DE/Munich) <mehmet.ersue@nsn.com>
To: <coman@ietf.org>
CC: ext Benoit Claise <bclaise@cisco.com> 


Hi All,

we planned a Coman side discussion on November 8th, 2012 Thursday 11:30
- 13:00. 

Topics will -02 draft in general, constrained device classes, class of
networks in focus, management of constrainedness and the requirements
section, etc.

PS: This is just an adhoc discussion. There will be no jabber, no
recording. I will provide some minutes.
PS2: The room request has been approved but the IETF secretary did not
assign a room yet.

Cheers, 
Mehmet



--------------080505070209040805040608-- From aland@freeradius.org Sat Oct 27 16:32:09 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306A821F85C5 for ; Sat, 27 Oct 2012 16:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpC3VBlgHcfU for ; Sat, 27 Oct 2012 16:32:08 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29021F8509 for ; Sat, 27 Oct 2012 16:32:08 -0700 (PDT) Received: by power.freeradius.org (Postfix, from userid 1000) id 3C1AA2241018; Sun, 28 Oct 2012 01:32:06 +0200 (CEST) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.2) Message-Id: <20121027233206.3C1AA2241018@power.freeradius.org> Date: Sun, 28 Oct 2012 01:32:06 +0200 (CEST) Subject: [AAA-DOCTORS] Automatic tech report for Sun Oct 28 01:32:06 CEST 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 23:32:09 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-arch-04 Active draft-ietf-abfab-gss-eap-09 In IESG processing - ID Tracker state draft-ietf-dhc-dhcpv6-radius-opt-03 Active draft-ietf-netmod-system-mgmt-03 Active draft-ietf-softwire-6rd-radius-attrib-07 In IESG processing - ID Tracker state