From nobody Sat Mar  1 16:32:50 2014
Return-Path: <aland@freeradius.org>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDE01A0B38 for <aaa-doctors@ietfa.amsl.com>; Sat,  1 Mar 2014 16:32:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.548
X-Spam-Level: 
X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBKiI3ORJQAz for <aaa-doctors@ietfa.amsl.com>; Sat,  1 Mar 2014 16:32:41 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 981951A0316 for <aaa-doctors@ietf.org>; Sat,  1 Mar 2014 16:32:41 -0800 (PST)
Received: by power.freeradius.org (Postfix, from userid 1000) id 92D64224018F; Sun,  2 Mar 2014 01:32:08 +0100 (CET)
From: aland@freeradius.org
To: <aaa-doctors@ietf.org>
X-Mailer: mail (GNU Mailutils 2.2)
Message-Id: <20140302003208.92D64224018F@power.freeradius.org>
Date: Sun,  2 Mar 2014 01:32:08 +0100 (CET)
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/Ia5YyiFSVveTXDiHtlxRIVWF6T4
Subject: [AAA-DOCTORS] Automatic tech report for Sun Mar 2 01:32:08 CET 2014
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Mar 2014 00:32:44 -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-aaa-saml-09                      Active	
draft-ietf-abfab-arch-12                          In IESG processing - ID Tracker state <IESG Evaluation - Defer>	
draft-ietf-netmod-system-mgmt-13                  In IESG processing - ID Tracker state <IESG Evaluation>	
draft-ietf-softwire-map-radius-01                 Active	


From nobody Sat Mar  8 16:32:21 2014
Return-Path: <aland@freeradius.org>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8C41A02DE for <aaa-doctors@ietfa.amsl.com>; Sat,  8 Mar 2014 16:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.548
X-Spam-Level: 
X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcLsL-lZWGPh for <aaa-doctors@ietfa.amsl.com>; Sat,  8 Mar 2014 16:32:14 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3655D1A02DB for <aaa-doctors@ietf.org>; Sat,  8 Mar 2014 16:32:14 -0800 (PST)
Received: by power.freeradius.org (Postfix, from userid 1000) id 5BF562240272; Sun,  9 Mar 2014 01:32:07 +0100 (CET)
From: aland@freeradius.org
To: <aaa-doctors@ietf.org>
X-Mailer: mail (GNU Mailutils 2.2)
Message-Id: <20140309003207.5BF562240272@power.freeradius.org>
Date: Sun,  9 Mar 2014 01:32:07 +0100 (CET)
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/7qokfkl9pHecyEp4k2HjW2MRorc
Subject: [AAA-DOCTORS] Automatic tech report for Sun Mar 9 01:32:07 CET 2014
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2014 00:32:16 -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-aaa-saml-09                      Active	
draft-ietf-abfab-arch-12                          In IESG processing - ID Tracker state <IESG Evaluation - Defer>	
draft-ietf-netmod-system-mgmt-13                  In IESG processing - ID Tracker state <IESG Evaluation>	
draft-ietf-softwire-map-radius-01                 Active	


From nobody Mon Mar 10 03:07:33 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFB11A040A for <aaa-doctors@ietfa.amsl.com>; Mon, 10 Mar 2014 03:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3numB0RxKKa9 for <aaa-doctors@ietfa.amsl.com>; Mon, 10 Mar 2014 03:07:30 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE971A0404 for <aaa-doctors@ietf.org>; Mon, 10 Mar 2014 03:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=266; q=dns/txt; s=iport; t=1394446045; x=1395655645; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hiHaPDNWBhWPgloWnQ/Tjj1inLyRwhH0ZvM6BYjjKw4=; b=MI3ToFDXjQEFoZhM7TOasYtrDirRlE5N9h3oB+BRLwah8REnuLmHIQB6 yu+071DcrA9G8H/HI9fnTM5pLqKj7+sYPiPO/tWKjJjngszUf/BbDWB/x RpObqGhJlk7SVT7DAvfCWqaQBidW1qI6d0OdWQqKFj/tFRJgMBY3YAFuC 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAMuNHVOQ/khR/2dsb2JhbABagwbCTYEbFnSCJQEBAQMBOEABBQsLIRYPCQMCAQIBRQYNAQcBAYdtCM9IF45bB4Q4AQOYRYZMi2GDLT0
X-IronPort-AV: E=Sophos;i="4.97,622,1389744000";  d="scan'208";a="3373323"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-3.cisco.com with ESMTP; 10 Mar 2014 10:07:24 +0000
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2AA7Omt000833; Mon, 10 Mar 2014 10:07:24 GMT
Message-ID: <531D8EDC.9010106@cisco.com>
Date: Mon, 10 Mar 2014 10:07:24 +0000
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>
References: <530BD115.7020902@cisco.com>
In-Reply-To: <530BD115.7020902@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/viRY1ro6r6ssZtwKYHlX4sSgLcE
Cc: Joel jaeggli <joelja@bogus.com>
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 10:07:31 -0000

Dear all,

No one, really?

Regards, B.

> Dear AAA doctors,
>
> I would appreciate if one of you, at least, would review 
> draft-ietf-abfab-arch.
> It contains some AAA aspects. The draft is on the IESG telechat on 
> March 20th.
>
> Regards, Benoit


From nobody Sat Mar 15 17:32:51 2014
Return-Path: <aland@freeradius.org>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7D1A02B4 for <aaa-doctors@ietfa.amsl.com>; Sat, 15 Mar 2014 17:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.548
X-Spam-Level: 
X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDVYhCMzcwtq for <aaa-doctors@ietfa.amsl.com>; Sat, 15 Mar 2014 17:32:46 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC5A1A02B0 for <aaa-doctors@ietf.org>; Sat, 15 Mar 2014 17:32:46 -0700 (PDT)
Received: by power.freeradius.org (Postfix, from userid 1000) id D40EC2240170; Sun, 16 Mar 2014 01:32:07 +0100 (CET)
From: aland@freeradius.org
To: <aaa-doctors@ietf.org>
X-Mailer: mail (GNU Mailutils 2.2)
Message-Id: <20140316003207.D40EC2240170@power.freeradius.org>
Date: Sun, 16 Mar 2014 01:32:07 +0100 (CET)
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/htj4HbdbnGbekhlk4Eg7AqBT2k4
Subject: [AAA-DOCTORS] Automatic tech report for Sun Mar 16 01:32:07 CET 2014
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 00:32:48 -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-aaa-saml-09                      Active	
draft-ietf-abfab-arch-12                          In IESG processing - ID Tracker state <IESG Evaluation - Defer>	
draft-ietf-netmod-system-mgmt-13                  In IESG processing - ID Tracker state <IESG Evaluation>	
draft-ietf-softwire-map-radius-01                 Active	


From nobody Tue Mar 18 04:33:52 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6CB1A06E0 for <aaa-doctors@ietfa.amsl.com>; Tue, 18 Mar 2014 04:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLq1JNjUvMa3 for <aaa-doctors@ietfa.amsl.com>; Tue, 18 Mar 2014 04:33:48 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 684DD1A06D9 for <aaa-doctors@ietf.org>; Tue, 18 Mar 2014 04:33:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=391; q=dns/txt; s=iport; t=1395142420; x=1396352020; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4mAgL1lMRpYiXoUAmTeRiV5bmiHf/cS4Z3LqnK+w2VY=; b=WTd3APRFZioJfQgXwoLchOUetFnn6niBfqWwPlmfyxf81D7n8ze1uNe4 bXxSz838BNGFV6GD9/Xxyg2zsW/AmI5OqYB4PR7xmjvBwtJSlGhRi5wNu 5lP1g0q/7XXm2ONXAQdWpjhcHAhXzLbVqYwTKRnU47o9b+/LHdIQTfUHE A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQFAL0uKFOQ/khM/2dsb2JhbABagwbDM4ElFnSCJgEBBDhBEAshJQ8CRgYNAQcBAYd10UkXjmIHhDgBA5hGhkyLZIMuPA
X-IronPort-AV: E=Sophos;i="4.97,677,1389744000";  d="scan'208";a="9027500"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 18 Mar 2014 11:33:39 +0000
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2IBXdcF029740; Tue, 18 Mar 2014 11:33:39 GMT
Message-ID: <53282F13.207@cisco.com>
Date: Tue, 18 Mar 2014 12:33:39 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>
References: <530BD115.7020902@cisco.com> <531D8EDC.9010106@cisco.com>
In-Reply-To: <531D8EDC.9010106@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/HqKHZ6MYr2aVNtHPrYwbPeWWTk4
Cc: Joel jaeggli <joelja@bogus.com>
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 11:33:50 -0000

No one, really?

Did this directory lose all its energy? Time to close an move on?

Regards, Benoit
> Dear all,
>
> No one, really?
>
> Regards, B.
>
>> Dear AAA doctors,
>>
>> I would appreciate if one of you, at least, would review 
>> draft-ietf-abfab-arch.
>> It contains some AAA aspects. The draft is on the IESG telechat on 
>> March 20th.
>>
>> Regards, Benoit
>


From nobody Tue Mar 18 06:16:39 2014
Return-Path: <aland@deployingradius.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832F31A03F8 for <aaa-doctors@ietfa.amsl.com>; Tue, 18 Mar 2014 06:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOaBoKEvXGn6 for <aaa-doctors@ietfa.amsl.com>; Tue, 18 Mar 2014 06:16:35 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 969071A03C9 for <aaa-doctors@ietf.org>; Tue, 18 Mar 2014 06:16:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id AAA002240152; Tue, 18 Mar 2014 14:16:26 +0100 (CET)
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 kjsNzwy+aDzH; Tue, 18 Mar 2014 14:16:26 +0100 (CET)
Received: from Thor.local (unknown [70.50.218.22]) by power.freeradius.org (Postfix) with ESMTPSA id 1F44D2240137; Tue, 18 Mar 2014 14:16:26 +0100 (CET)
Message-ID: <53284729.3040503@deployingradius.com>
Date: Tue, 18 Mar 2014 09:16:25 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <530BD115.7020902@cisco.com> <531D8EDC.9010106@cisco.com> <53282F13.207@cisco.com>
In-Reply-To: <53282F13.207@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/3qT3rTK7Jx6gWXIRsLfB107Osyc
Cc: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, Joel jaeggli <joelja@bogus.com>
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 13:16:37 -0000

Benoit Claise wrote:
> No one, really?

  I think most aaa-doctors have been following abfab closely for quite a
while.

> Did this directory lose all its energy? Time to close an move on?

  I'd prefer not... but AAA is a sadly neglected part of the internet.


From nobody Tue Mar 18 06:50:37 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86B11A0403 for <aaa-doctors@ietfa.amsl.com>; Tue, 18 Mar 2014 06:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et-x2Fiou3Wl for <aaa-doctors@ietfa.amsl.com>; Tue, 18 Mar 2014 06:50:34 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2139D1A02E8 for <aaa-doctors@ietf.org>; Tue, 18 Mar 2014 06:50:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=668; q=dns/txt; s=iport; t=1395150626; x=1396360226; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EbjzYkx7D4YHid8TDcugPzZa4hZyQ0iba764do/sNzs=; b=Mq2qXpT+tvKsazS5Tro5Na5fTYZqcMLjVXQe9wc/iRWXQcnhEYB5Duz3 6ElaQCMRJQK9j8u/2PRdVu/xRS92BsWlGigTuL/Wo8NtWsO1LzK7YpNRN xe8INCcWTkw4irKvfXGcrNzNoXHzWy3kWqxPs/EzJYj008Pp0VghljUyP c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlcIAGFOKFOQ/khM/2dsb2JhbABagwa7foc1gSsWdIIlAQEBBDgzDQEQCxgJFg8JAwIBAgFFBg0BBwEBh3XRVBeOYgeEOAEDmEaGTItkgy48
X-IronPort-AV: E=Sophos;i="4.97,678,1389744000";  d="scan'208";a="9048500"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 18 Mar 2014 13:50:25 +0000
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2IDoOMi016765; Tue, 18 Mar 2014 13:50:25 GMT
Message-ID: <53284F20.5030009@cisco.com>
Date: Tue, 18 Mar 2014 14:50:24 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Alan DeKok <aland@deployingradius.com>
References: <530BD115.7020902@cisco.com> <531D8EDC.9010106@cisco.com> <53282F13.207@cisco.com> <53284729.3040503@deployingradius.com>
In-Reply-To: <53284729.3040503@deployingradius.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/6AF4QaewErjLwjXmEJtXG5swqwQ
Cc: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, Joel jaeggli <joelja@bogus.com>
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 13:50:36 -0000

Alan,

Thanks for replying
> Benoit Claise wrote:
>> No one, really?
>    I think most aaa-doctors have been following abfab closely for quite a
> while.
So what is the feedback of the aaa-doctors who have been following abfab 
closely.
Personally, I have not been following abfab. So, between the extreme 
"this is non-sense" and "this is good to go", I have no opinion at this 
point in time: I still have to start reading the doc.
So any feedback from the experts is good feedback.

Regards, Benoit
>
>> Did this directory lose all its energy? Time to close an move on?
>    I'd prefer not... but AAA is a sadly neglected part of the internet.
>


From nobody Sat Mar 22 17:32:13 2014
Return-Path: <aland@freeradius.org>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A841A6EF7 for <aaa-doctors@ietfa.amsl.com>; Sat, 22 Mar 2014 17:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level: 
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zgxhqe1AOUK for <aaa-doctors@ietfa.amsl.com>; Sat, 22 Mar 2014 17:32:09 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93C741A6EF5 for <aaa-doctors@ietf.org>; Sat, 22 Mar 2014 17:32:09 -0700 (PDT)
Received: by power.freeradius.org (Postfix, from userid 1000) id EAD2A22400DD; Sun, 23 Mar 2014 01:32:07 +0100 (CET)
From: aland@freeradius.org
To: <aaa-doctors@ietf.org>
X-Mailer: mail (GNU Mailutils 2.2)
Message-Id: <20140323003207.EAD2A22400DD@power.freeradius.org>
Date: Sun, 23 Mar 2014 01:32:07 +0100 (CET)
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/Kwf46ZiPp1KlOx7HGtsnb0C2xxg
Subject: [AAA-DOCTORS] Automatic tech report for Sun Mar 23 01:32:07 CET 2014
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Mar 2014 00:32:11 -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-aaa-saml-09                      Active	
draft-ietf-abfab-arch-12                          In IESG processing - ID Tracker state <IESG Evaluation - Defer>	
draft-ietf-netmod-system-mgmt-13                  In IESG processing - ID Tracker state <IESG Evaluation>	
draft-ietf-softwire-map-radius-01                 Active	


From nobody Sun Mar 23 02:35:29 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992C91A6F4D; Sun, 23 Mar 2014 02:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.811
X-Spam-Level: 
X-Spam-Status: No, score=-6.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp1UI8XSnxmE; Sun, 23 Mar 2014 02:35:25 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1E31A093B; Sun, 23 Mar 2014 02:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9487; q=dns/txt; s=iport; t=1395567326; x=1396776926; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=/CGH2bxewU8GHaYv8s94iBd1OhJlMaD15CFV8C0TN0s=; b=iaGanrScMdmqBt+nTNslxq+npvyp1QKIFLlq41Fz31Pk1rxGWho1jq5c wy3nPBuk0eBmJaH86IfQ9JM4BE3ZtFrmGXOsblBzr/A4KIOoRCCo8p7FA o3EmwmQ1lW5RVa5KM3R3JFDjlGyksAmiIjIht4RwFmgu3Ydzwrq3UH6Oe w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFACSqLlOQ/khN/2dsb2JhbABYgwY7w0WBDhZ0giUBAQEEOEANBB0PFg8JAwIBAgE3DgYBDAYCAQGHdQ3NRhePAYQ4BJhKgTKFGotlgy48
X-IronPort-AV: E=Sophos;i="4.97,713,1389744000";  d="scan'208";a="6039961"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-3.cisco.com with ESMTP; 23 Mar 2014 09:35:24 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2N9ZL0B012555; Sun, 23 Mar 2014 09:35:22 GMT
Message-ID: <532EAAD9.7080306@cisco.com>
Date: Sun, 23 Mar 2014 10:35:21 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, YANG Doctors <yang-doctors@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "pm-dir@ietf.org" <pm-dir@ietf.org>, IETF DNS Directorate <dns-dir@ietf.org>
References: <20140320224110.21951.63897.idtracker@ietfa.amsl.com>
In-Reply-To: <20140320224110.21951.63897.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140320224110.21951.63897.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/KpHP2iCzreyNc4DLhNGUi4r6oz8
Subject: [AAA-DOCTORS] Summarized Agenda for the 2014-03-27 IESG Teleconference
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Mar 2014 09:35:27 -0000

Dear all,

Please find below the agenda of the Mar 27th IESG telechat.
Please send your questions, comments, and concerns before Mar 26th COB.

Thanks and Regards, Benoit.

-------- Original Message --------

INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the 2014-03-27 IESG Teleconference

This agenda was generated at 2014-03-20 15:39:19 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-cuss-sip-uui-14  - IETF stream
     A Mechanism for Transporting User to User Call Control Information
     in SIP (Proposed Standard)
     Token: Alissa Cooper
     IANA Review: IANA - Not OK
     Consensus: Unknown

   o draft-ietf-storm-rdmap-ext-09  - IETF stream
     RDMA Protocol Extensions (Proposed Standard)
     Token: Martin Stiemerling
     IANA Review: IANA OK - Actions Needed
     Consensus: Unknown

   o draft-ietf-manet-smf-mib-10  - IETF stream
     Definition of Managed Objects for the Manet Simplified Multicast
     Framework Relay Set Process (Proposed Standard)
     Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd
     Token: Adrian Farrel
     IANA Review: IANA - Not OK
     Consensus: Yes

   o draft-ietf-netmod-ip-cfg-13  - IETF stream
     A YANG Data Model for IP Management (Proposed Standard)
     Note: Thomas Nadeau <tnadeau@lucidvision.com> is the document
     shepherd.
     Token: Benoit Claise
     IANA Review: Version Changed - Review Needed
     Consensus: Yes

   o draft-ietf-mpls-ldp-multi-topology-11  - IETF stream
     LDP Extensions for Multi Topology (Proposed Standard)
     Note: Loa Andersson <loa@pi.nu> is the document shepherd
     Token: Adrian Farrel
     IANA Review: IANA - Not OK
     Consensus: Yes

   o draft-ietf-tcpm-1323bis-20  - IETF stream
     TCP Extensions for High Performance (Proposed Standard)
     Token: Martin Stiemerling
     IANA Review: IANA OK - Actions Needed
     Consensus: Unknown

   o draft-ietf-netmod-system-mgmt-13  - IETF stream
     A YANG Data Model for System Management (Proposed Standard)
     Token: Benoit Claise
     IANA Review: Version Changed - Review Needed
     Consensus: Yes

   o draft-ietf-jcardcal-jcal-09  - IETF stream
     jCal: The JSON format for iCalendar (Proposed Standard)
     Token: Pete Resnick
     IANA Review: IANA OK - Actions Needed
     Consensus: Yes

   o draft-ietf-dhc-dhcpv6-unknown-msg-06  - IETF stream
     Handling Unknown DHCPv6 Messages (Proposed Standard)
     Token: Brian Haberman
     IANA Review: Version Changed - Review Needed
     Consensus: Yes

   o draft-ietf-radext-ieee802ext-11  - IETF stream
     RADIUS Attributes for IEEE 802 Networks (Proposed Standard)
     Token: Benoit Claise
     IANA Review: IANA OK - Actions Needed
     Consensus: Yes

   o draft-ietf-appsawg-rrvs-header-field-08  - IETF stream
     The Require-Recipient-Valid-Since Header Field and SMTP Service
     Extension (Proposed Standard)
     Token: Barry Leiba
     IANA Review: Version Changed - Review Needed
     Consensus: Yes

   o draft-ietf-mpls-special-purpose-labels-06  - IETF stream
     Allocating and Retiring Special Purpose MPLS Labels (Proposed
     Standard)
     Token: Alia Atlas
     IANA Review: IANA OK - Actions Needed
     Consensus: Unknown

   o draft-ietf-mpls-tp-psc-itu-03  - IETF stream
     MPLS Transport Profile (MPLS-TP) Linear Protection to Match the
     Operational Expectations of SDH, OTN and Ethernet Transport Network
     Operators (Proposed Standard)
     Token: Adrian Farrel
     IANA Review: IANA OK - Actions Needed
     Consensus: Yes

   o draft-ietf-netext-pmip6-qos-11  - IETF stream
     Quality of Service Option for Proxy Mobile IPv6 (Proposed Standard)
     Token: Brian Haberman
     IANA Review: IANA - Review Needed
     Consensus: Unknown
     Last call expires: 2014-03-24

   o draft-ietf-appsawg-xml-mediatypes-09  - IETF stream
     XML Media Types (Proposed Standard)
     Token: Barry Leiba
     IANA Review: IANA - Not OK
     Consensus: Yes

2.1.2 Returning Items
     
   o draft-ietf-pwe3-iccp-15  - IETF stream
     Inter-Chassis Communication Protocol for L2VPN PE Redundancy
     (Proposed Standard)
     Token: Alia Atlas
     IANA Review: Version Changed - Review Needed
     Consensus: Yes

2.2 Individual Submissions
2.2.1 New Items
     
   o draft-fairhurst-ipdvb-ule-iana-06  - IETF stream
     IANA Guidance for Managing the ULE Next-Header Registry (Proposed
     Standard)
     Token: Brian Haberman
     IANA Review: Version Changed - Review Needed
     Consensus: Yes

2.2.2 Returning Items

   NONE

2.3 Status Changes
2.3.1 New Items

   NONE

2.3.2 Returning Items

   NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items
     
   o draft-ietf-dmm-requirements-15  - IETF stream
     Requirements for Distributed Mobility Management (Informational)
     Token: Brian Haberman
     IANA Review: IANA OK - No Actions Needed
     Consensus: Yes

   o draft-ietf-ippm-testplan-rfc2680-04  - IETF stream
     Test Plan and Results for Advancing RFC 2680 on the Standards Track
     (Informational)
     Token: Spencer Dawkins
     IANA Review: IANA OK - No Actions Needed
     Consensus: Unknown

   o draft-ietf-multimob-pmipv6-source-08  - IETF stream
     Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6)
     Domains (Experimental)
     Token: Brian Haberman
     IANA Review: IANA OK - No Actions Needed
     Consensus: Yes

   o draft-ietf-ecrit-trustworthy-location-09  - IETF stream
     Trustworthy Location (Informational)
     Token: Alissa Cooper
     IANA Review: Version Changed - Review Needed
     Consensus: Unknown

3.1.2 Returning Items
     
   o draft-ietf-opsawg-oam-overview-14  - IETF stream
     An Overview of Operations, Administration, and Maintenance (OAM)
     Tools (Informational)
     Note: Scott Bradner (sob@harvard.edu) is the Document Shepherd.
     Token: Benoit Claise
     IANA Review: IANA OK - No Actions Needed
     Consensus: Unknown

   o draft-ietf-abfab-arch-12  - IETF stream
     Application Bridging for Federated Access Beyond Web (ABFAB)
     Architecture (Informational)
     Token: Stephen Farrell
     IANA Review: IANA OK - No Actions Needed
     Consensus: Yes

   o draft-ietf-v6ops-64share-09  - IETF stream
     Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN
     link (Informational)
     Token: Joel Jaeggli
     IANA Review: IANA OK - No Actions Needed
     Consensus: Unknown

   o draft-ietf-eman-framework-16  - IETF stream
     Energy Management Framework (Informational)
     Token: Joel Jaeggli
     IANA Review: IANA OK - Actions Needed
     Consensus: No

3.2 Individual Submissions Via AD
3.2.1 New Items
     
   o draft-kaplan-insipid-session-id-04  - IETF stream
     A Session Identifier for the Session Initiation Protocol (SIP)
     (Informational)
     Token: Richard Barnes
     IANA Review: IANA OK - Actions Needed
     Consensus: No

3.2.2 Returning Items
     
   o draft-yourtchenko-cisco-ies-10  - IETF stream
     Cisco Specific Information Elements reused in IPFIX (Informational)
     Token: Joel Jaeggli
     IANA Review: IANA OK - Actions Needed
     Consensus: Unknown

3.3 Status Changes
3.3.1 New Items

   NONE

3.3.2 Returning Items

   NONE

3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items

   o conflict-review-zulr-mpls-tp-linear-protection-switching-01
     IETF conflict review for
     draft-zulr-mpls-tp-linear-protection-switching
       draft-zulr-mpls-tp-linear-protection-switching-12
       Pre-standard Linear Protection Switching in MPLS-TP (ISE:
     Informational)
     Token: Adrian Farrel

   o conflict-review-melnikov-authentication-results-smime-00
     IETF conflict review for draft-melnikov-authentication-results-smime
       draft-melnikov-authentication-results-smime-08
       Authentication-Results Registration for S/MIME signature
     verification (ISE: Informational)
     Token: Barry Leiba

3.4.2 Returning Items

   NONE

3.4.3 For Action

   o conflict-review-boucadair-connectivity-provisioning-profile-00
     IETF conflict review for
     draft-boucadair-connectivity-provisioning-profile
       draft-boucadair-connectivity-provisioning-profile-03
       Connectivity Provisioning Profile (CPP) (ISE: Informational)
     Token: Jari Arkko

   o conflict-review-avula-shwmp-00
     IETF conflict review for draft-avula-shwmp
       draft-avula-shwmp-01
       Secure Hybrid Wireless Mesh Protocol (SHWMP) (ISE: Experimental)
     Token: Jari Arkko

   o conflict-review-dunbar-armd-arp-nd-scaling-practices-00
     IETF conflict review for draft-dunbar-armd-arp-nd-scaling-practices
       draft-dunbar-armd-arp-nd-scaling-practices-07
       Practices for scaling ARP and ND for large data centers (ISE:
     Informational)
     Token: Jari Arkko

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

   o DiffServ Applied to RTP Transports (dart)

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

   NONE




From nobody Mon Mar 24 07:01:23 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14F71A021D for <aaa-doctors@ietfa.amsl.com>; Mon, 24 Mar 2014 07:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.511
X-Spam-Level: 
X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIfGoFXaeeqq for <aaa-doctors@ietfa.amsl.com>; Mon, 24 Mar 2014 07:01:15 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 452691A0228 for <aaa-doctors@ietf.org>; Mon, 24 Mar 2014 07:01:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=918; q=dns/txt; s=iport; t=1395669669; x=1396879269; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SJCPGNRyRGgNLTbiPWbH+MN7qwDUWbmLYh3zVGV4SNc=; b=P0Qrryaya4XVYy49AmqjgQvucxTeR/ahv1ENWGEsHIwgOWGo/yz0vko9 vcaswGt1vcRxFO55jMtuSLPKKspJco9IRsuOnunTOx9YXFI44OgP/DOxh NsgxqGkAd2upGfgnxSvA1gQVdB5eEO4k5qyrLSr27xJtF26rgQ3YdqsuT I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AucNAHE5MFOQ/khM/2dsb2JhbABZgwY7vA8Hhy6BFhZ0giUBAQEEAQEBNTMDCgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGHdQ3OGxMEjnoHhDgBA5hKhkyLZYMuPA
X-IronPort-AV: E=Sophos;i="4.97,721,1389744000"; d="scan'208";a="10383077"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 24 Mar 2014 14:01:07 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2OE17xj031597; Mon, 24 Mar 2014 14:01:07 GMT
Message-ID: <53303AA3.2050700@cisco.com>
Date: Mon, 24 Mar 2014 15:01:07 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Alan DeKok <aland@deployingradius.com>
References: <530BD115.7020902@cisco.com> <531D8EDC.9010106@cisco.com> <53282F13.207@cisco.com> <53284729.3040503@deployingradius.com> <53284F20.5030009@cisco.com>
In-Reply-To: <53284F20.5030009@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/APoi34npr9FPjSqNMECRmKHh_wE
Cc: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, Joel jaeggli <joelja@bogus.com>
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Mar 2014 14:01:17 -0000

Alan, All,
> Alan,
>
> Thanks for replying
>> Benoit Claise wrote:
>>> No one, really?
>>    I think most aaa-doctors have been following abfab closely for 
>> quite a
>> while.
> So what is the feedback of the aaa-doctors who have been following 
> abfab closely?
No answer to this one?

Regards, Benoit
> Personally, I have not been following abfab. So, between the extreme 
> "this is non-sense" and "this is good to go", I have no opinion at 
> this point in time: I still have to start reading the doc.
> So any feedback from the experts is good feedback.
>
> Regards, Benoit
>>
>>> Did this directory lose all its energy? Time to close an move on?
>>    I'd prefer not... but AAA is a sadly neglected part of the internet.
>>
>
> _______________________________________________
> AAA-DOCTORS mailing list
> AAA-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/aaa-doctors
>


From nobody Mon Mar 24 10:17:39 2014
Return-Path: <aland@deployingradius.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AED1A023F for <aaa-doctors@ietfa.amsl.com>; Mon, 24 Mar 2014 10:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osJ8YqzOkuoc for <aaa-doctors@ietfa.amsl.com>; Mon, 24 Mar 2014 10:17:35 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C17AD1A01DF for <aaa-doctors@ietf.org>; Mon, 24 Mar 2014 10:17:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 91051224017C; Mon, 24 Mar 2014 18:17:33 +0100 (CET)
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 EEIKC1t6mJjT; Mon, 24 Mar 2014 18:17:32 +0100 (CET)
Received: from Thor.local (bas1-ottawa11-1176224686.dsl.bell.ca [70.27.195.174]) by power.freeradius.org (Postfix) with ESMTPSA id 24363224006A; Mon, 24 Mar 2014 18:17:32 +0100 (CET)
Message-ID: <533068AB.1020903@deployingradius.com>
Date: Mon, 24 Mar 2014 13:17:31 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <530BD115.7020902@cisco.com> <531D8EDC.9010106@cisco.com> <53282F13.207@cisco.com> <53284729.3040503@deployingradius.com> <53284F20.5030009@cisco.com> <53303AA3.2050700@cisco.com>
In-Reply-To: <53303AA3.2050700@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/eaRoi0ta2s-ZYeCuC3qhioWgrcU
Cc: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, Joel jaeggli <joelja@bogus.com>, raft-ietf-abfab-arch@tools.ietf.org
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Mar 2014 17:17:37 -0000

Benoit Claise wrote:
> No answer to this one?

  Here we go.  In short, the document is good, but seems to assume a
familiarity with the concepts being discussed.  It talks about concepts
without introducing them, leading to confusion on the part of the naive
reader.

Section 1

   Numerous security mechanisms have been deployed on the Internet to
   manage access to various resources.

- This is a bit vague.  "Security does stuff". Some examples would help.

   A Relying Party (RP) is the entity that manages access to some
   resource

- This sentence jumps discontinuously from the previous paragraph.  Why
are we talking about Relying parties?  It's generally easier to talk
about problems, and then to introduce solutions to those problems.

     ... The entity that is requesting access to that resource is
   often described as the Client.

  Why not use "Client" and "Server"?  Jumping straight to new
terminology is awkward.

   Some security mechanisms allow the RP to delegate aspects of the
   access management decision to an entity called the Identity Provider
   (IdP).  This delegation requires technical signaling, trust and a
   common understanding of semantics between the RP and IdP.  These
   aspects are generally managed within a relationship known as a
   'federation'.

- The "federation" doesn't follow from delegation.  System A can
delegate functionality to system B, but that's just delegation.  I would
expect to see motivation for federation.

- e.g. when there are many people trying to authenticate, the Server may
not have credentials for all of them.  It may delegate the
authentication to one or more secondary Servers.  Any grouping of
Servers to achieve a common purpose is called a "federation"

- once we define the problem space in terms of *existing* terminology,
it's then possible to introduce *new* terminology.

   Single or Simplified sign-on:

      An Internet service can delegate access management

- what's an "Internet Service" ?  That's the first use of the term in
this document.  Is it a Relying Party?  A generic Server?

      Often a Relying Party does not need to know the identity of a
      Client to reach an access management decision.  It is frequently
      only necessary for the Relying Party to know specific attributes
      about the client,

- nitpick I'd use "properties" rather than "attributes".  Attributes
have a well-defined meaning in AAA space.  The properties talked about
above may not be transported in attributes, so they shouldn't be called
attributes.

      Prior to the release of attributes to the RP from the IdP, the IdP
      will check configuration and policy to determine if the attributes
      are to be released.

- Why is an IdP releasing attributes to the RP?  This is the first
mention of it.

      Sometimes a Relying Party needs, or would like, to know more about
      a client than an affiliation or a pseudonym.

- Why?  Because "it's Tuesday, and I want to know his shoe size"?  Or
are there problems whih are solved by asking for additional information?

   This memo describes the Application Bridging for Federated Access
   Beyond the Web (ABFAB) architecture.  This architecture makes use of
   extensions to the commonly used security mechanisms for both
   federated and non-federated access management, including RADIUS, the
   Generic Security Service (GSS), the Extensible Authentication
   Protocol (EAP) and SAML.  The architecture should be extended to use
   Diameter in the future.  The architecture addresses the problem of
   federated access management primarily for non-web-based services.

- the last sentence there should be moved to be the second one.
  i.e. What is ABFAB.  Problem to be solved.  Technology used to solve
  the problem.

Section 1.1

   This document uses identity management and privacy terminology from
   [RFC6973].  In particular, this document uses the terms identity
   provider, relying party, identifier, pseudonymity, unlinkability, and
   anonymity.

- that sentence could be moved to earlier in the document.  It gives a
basis for the terminology used in Section 1.  Or, re-word Section 1 to
use less of the terminology introduced in Section 1.1.

   This document uses the term Network Access Identifier (NAI), as
   defined in [I-D.ietf-radext-nai].  An NAI consists of a realm
   identifier, which is associated with an IdP

- Why is a realm associated with an IdP?  Again, motivation.  Does the
*document* use the NAI, or does it assume that the *authentication it
talks about* uses the NAI?

- e.g. We assume that each authentication request in the ABFAB
architecture includes an NAI.  The realm portion of the NAI is used to
distinguish and/or select an IdP.  Each IdP may have one or more realms.

   One of the problems some people have found with reading this document
   is that the terminology sometimes appears to be inconsistent.  This
   is due the fact that the terms used by the different standards we are
   referencing are not consistent with each other.  In general the
   document uses either the ABFAB term or the term associated with the
   standard under discussion as appropriate.

- nitpick: I would say that for general cases, this document uses the
terminology from RFC 6973, as it is cross-standard.  Where this document
refers to actions of a particular protocol, the protocol-specific terms
are used.  e.g. "ABFAB relies on an IdP", versus "the RADIUS client ..."

- doing so should make the document clearer

   Note that in some cases a cell has been left empty; in these cases
   there is no name that represents the entity.

- nitpick: there is no name *within that standard* which defines the
given term.

   This document uses the term channel binding with two different
   meanings.

- I would say "in two different contexts".  The later specification of
"EAP channel bindings" and "GSS-API channel bindings" makes the
distinction clear.  The term "channel bindings" therefore does not have
two different meanings, as it should be used only within the context of
"EAP" or "GSS-API".

   Federation

      The Identity Provider and the Relying Parties are part of a
      Federation.  The relationship may be direct (they have an explicit
      trust relationship) or transitive (the trust relationship is
      mediated by one or more entities).  The federation relationship is
      governed by a federation agreement.  Within a single federation,
      there may be multiple Identity Providers as well as multiple
      Relying Parties.

- I find this confusing, and not in line with the other definitions.  A
definition should be of the form:

  FOO
    FOO is thing which does BAR, and used BAZ and BARK to do so.

- e.g.  A Federation is composed of a set of Identity Providers and
Relying Parties.  The IdPs and RPs may have explicit trust relationships
with each other, or the trust may be mediated by one more more entities
within that federation.  The relationships between IdPs and RPs is
governed by a federation agreement, which is outside of the scope of
this specification.

   Authentication

      There is a direct relationship between the Client and the Identity
      Provider.  This relationship provides the means by which they
      trust each other and can securely authenticate each other.

- the same comment applies here.  Authentication is *something*.  The
first sentence of the definition above seems to have no bearing on
authentication

  Operational Specifications:

- put the last sentence first, which motivates the rest of the paragraph.

   The Operational Specifications can demand the usage of a
   sophisticated technical infrastructure,

- as opposed to a crappy technical infrastructure?  I suggest just
deleting the word "sophisticated"

   While a federation agreement is often discussed within the context of
   formal relationships, such as between an enterprise and an employee
   or a government and a citizen,

- who is doing that discussion?  I don't see it in this document.  Some
clarity would help here.

   For an IdP and a
   Client, it is sufficient for a relationship to be established by
   something as simple as using a web form and confirmation email.

- are we suggesting implementation details?  If so, why does it matter?

   The nature of federation dictates that there is some form of
   relationship between the identity provider and the relying party.
   This is particularly important when the relying party wants to use
   information obtained from the identity provider for access management
   decisions and when the identity provider does not want to release
   information to every relying party (or only under certain
   conditions).

- Suggest capitalization of terms, to match the rest of the draft

   While it is possible to have a bilateral agreement between every IdP
   and every RP; on an Internet scale this setup requires the
   introduction of the multi-lateral federation concept, as the
   management of such pair-wise relationships would otherwise prove
   burdensome.

- what is a "multi-lateral federation concept"?  A concept?  A real thing?

   The nature and quality of the relationship between the Client and the
   IdP is an important contributor to the level of trust that an RP may
   attribute to an assertion

- "attribute" is used in other contexts here.  I'd suggest using a
synonym for "attribute"

   Federation does not require an a priori relationship or a long-term
   relationship between the RP and the Client; it is this property of
   federation that yields many of its benefits.

- what does "its" refer to?  The federation?  The relationship?

   However, federation
   does not preclude the possibility of a pre-existing relationship
   between the RP and the Client, nor that they may use the introduction
   to create a new long-term relationship independent of the federation.

- nitpick: I would say that the entities may have relationships outside
of the federation, including ones prior and post to the federation

   As the number of federated IdPs and RPs (services) proliferats,

- typo "proliferates".  And why is (services) there?  Are RPs just RPs,
or are they now (services)?  I suggest deleting it.

   As the number of federated IdPs and RPs (services) proliferats, the
   role of the individual

- ... was not previously discussed.  I suggest replacing that with
something like "an individual may have multiple identities (NAIs), and
choose the correct identity for network access"

  For instance, in the case of an email
   provider, the SMTP and IMAP protocols do not have the ability for the
   server to request information from the client, beyond the clients
   NAI, that the server would then use to decide between the multiple
   federations it is associated with.

Section 1.4

- nitpick: that's a long sentence.  Suggest breaking it up into smaller
fragments.

   In this example, a client is attempting to connect to a server

- nitpick: suggest passive voice. "a client attempts to connect ..."

- many of the following paragraphs have "X is configured".  OK, how?
Maybe "we assume that configuration discussed below is out of band, e.g.
via manual administrator action"



  OK... it's lunchtime here.  I'm done for now.  More later.

  Alan DeKok.


From nobody Wed Mar 26 12:20:00 2014
Return-Path: <aland@deployingradius.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169FA1A0388 for <aaa-doctors@ietfa.amsl.com>; Wed, 26 Mar 2014 12:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqt0I_GqhjWu for <aaa-doctors@ietfa.amsl.com>; Wed, 26 Mar 2014 12:19:54 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D64631A018D for <aaa-doctors@ietf.org>; Wed, 26 Mar 2014 12:19:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D192A224014F; Wed, 26 Mar 2014 20:19:51 +0100 (CET)
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 OY+kNKAQDd8t; Wed, 26 Mar 2014 20:19:51 +0100 (CET)
Received: from Thor.local (bas1-ottawa11-1176224686.dsl.bell.ca [70.27.195.174]) by power.freeradius.org (Postfix) with ESMTPSA id B79E822400B4; Wed, 26 Mar 2014 20:19:50 +0100 (CET)
Message-ID: <53332855.9030909@deployingradius.com>
Date: Wed, 26 Mar 2014 15:19:49 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <530BD115.7020902@cisco.com> <531D8EDC.9010106@cisco.com> <53282F13.207@cisco.com> <53284729.3040503@deployingradius.com> <53284F20.5030009@cisco.com> <53303AA3.2050700@cisco.com>
In-Reply-To: <53303AA3.2050700@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/O_xx5UkfN-Yt88guzZEyM094wGc
Cc: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, Joel jaeggli <joelja@bogus.com>, draft-ietf-abfab-arch@tools.ietf.org
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 19:19:57 -0000

  Continuing my review...

Section 1.5

   o  Each party in a transaction will be authenticated, although
      perhaps not identified,

- I'm not sure how that works.  Can you authenticate an entity without
identifying them?  The rest of the document seems silent on this topic

- Generally, there's a lot of lower-case use of "identity providers",
"relying parties", etc.  Please use consistent terms.  IdPs and RPs is
probably good enough, given the number of uses of those terms in the
document

   o  The system will be designed primarily for non-Web-based
      authentication.

- Why exclude the Web?  And if we're excluding the web, what kind of
authentication *is* it designed for?

   o  The system will build upon existing standards, components, and
      operational practices.

- that's good, but I'm not sure it needs to be explicitly called out.

   A lot of attention on
   federated access has been devoted to the Web.  This document instead
   focuses on a non-Web-based environment and focuses on those protocols
   where HTTP is not used.

- it would be useful to say why web-based systems aren't useful here.
i.e. OAUTH, etc. presumes that the user already has network access.
OAUTH mediates access to *services* on an existing network.  ABFAB
mediates access to *networks*, especially visited networks.

Section 2

   The main theme of the work described in this
   document is focused on re-using existing building blocks that have
   been deployed already and to re-arrange them in a novel way.

- the re-arrangement is not the goal, surely.  Instead, it's "re-arrange
them in a novel way to achieve global federated network access with
minimal changes to existing systems"

- that motivation also affects the first sentence of the next paragraph

Section 2.1

   Protocols that support the same framework, but do different routing
   are expected to be defined and used the future.  One such effort call
   the Trust Router

- nitpick: callED the Trust Router...

Section 2.1.1

   The usage of the AAA framework with RADIUS [RFC2865] and Diameter
   [RFC6733] for network access authentication has been successful from
   a deployment point of view.  To map to the terminology used in
   Figure 1 to the AAA framework

- it may be worth referring again to the table earlier in Section 1.
But reminding the reader of it here is a good idea.

Section 2.1.5

   For the traditional use of AAA frameworks, network access, the only
   requirement that was necessary to grant access was an affirmative
   response from the IdP.

- not completely true.  An affirmative response is the minimal
requirement.  Very often, additional authorization attributes are needed
 (e.g. Service-Type).  RFC 2865 Section 5.6 says this about Service-Type:

      A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead.

   ... This means that the RP needs to map from the SAML
   issuer or federation name, type and semantic into the name, type and
   semantics that the policies of the RP are written in.

- some guidance here would be useful.  How is that mapping done?  Or is
it just "implementation defined" ?

   Some RPs need to ensure that specific criteria are met during the
   authentication process.  This need is met by using Levels of
   Assurance.

- This is the first mention of "Levels of Assurance".  It's important
enough to capitalize, so it's a apparently a key concept.  But there's
no corresponding definition anywhere.

Section 2.3.1

   So, we use GSS-API and SASL because a number of the application
   protocols we wish to federate support these strategies for security
   integration.  What does this mean from a protocol standpoint and how
   does this relate to other layers?  This means we need to design a
   concrete GSS-API mechanism.

- while explanatory, asking && answering questions is a little odd in a
standards document.  I suggest trying to re-word this to be explanatory
instead

Section 4.2.2

   ... (such as
   the use of TLS for RADIUS [I-D.ietf-radext-dtls]).

- Maybe refer to RFC 6614 instead of the DTLS draft

  Also "mitigted"

- mis-spelled

   Note that ABFAB has not specified any AAA accounting requirements.
   Implementations that use the accounting portion of AAA should
   consider privacy appropriately when designing this aspect.

- specific suggestions would be useful here.  e.g. use CUI for user
identifiers, to give user anonymity.  Ensure that the accounting packets
contain no more information than what's in the Access-Request, etc.

Section 4.4

- it may be worth moving the last paragraph of Section 4.2.2
(accounting) to this section.

Section 5

   ...  In situations where the client is not yet on the
   net, ...

- that situation wasn't clearly described earlier in the document.  (or
at least so far as I recall).  Earlier text also talked about clients
having IP addresses.  It would be good to clarify just which situations
will apply to ABFAB.  Concrete examples would help.

- it may be useful to add a section with concrete examples.  Describe
the scenarios (user visiting remote site), and then a short discussion
of what happens, and what protocols are used.  Show which portions are
new to ABFAB, and which ones already exist.



  Despite my nits, the document is pretty good overall.  My comments are
largely related to clarifications, style, etc.  The ABFAB architecture
is a complex system which has a lot of moving pieces.  The document does
a good job of describing them.

  Alan DeKok.


From nobody Wed Mar 26 15:12:06 2014
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381A31A03DB for <aaa-doctors@ietfa.amsl.com>; Wed, 26 Mar 2014 15:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw9MGM9cZi4h for <aaa-doctors@ietfa.amsl.com>; Wed, 26 Mar 2014 15:12:03 -0700 (PDT)
Received: from blu0-omc3-s26.blu0.hotmail.com (blu0-omc3-s26.blu0.hotmail.com [65.55.116.101]) by ietfa.amsl.com (Postfix) with ESMTP id 98D681A03CB for <aaa-doctors@ietf.org>; Wed, 26 Mar 2014 15:12:03 -0700 (PDT)
Received: from BLU406-EAS323 ([65.55.116.72]) by blu0-omc3-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 26 Mar 2014 15:12:01 -0700
X-TMN: [X5IrbzPTPF7dKrMZacWcBZVpELjWopix2GHpzIhHuFw=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS323D99D6F02597E377F281293640@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <530BD115.7020902@cisco.com> <531D8EDC.9010106@cisco.com> <53282F13.207@cisco.com> <53284729.3040503@deployingradius.com> <53284F20.5030009@cisco.com> <53303AA3.2050700@cisco.com> <53332855.9030909@deployingradius.com>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <53332855.9030909@deployingradius.com>
Date: Wed, 26 Mar 2014 18:11:59 -0400
To: Alan DeKok <aland@deployingradius.com>
X-OriginalArrivalTime: 26 Mar 2014 22:12:01.0993 (UTC) FILETIME=[69DE1390:01CF4940]
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/ToqkW9IBAAmPHrdN4HXQrUrJgA4
Cc: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, Joel jaeggli <joelja@bogus.com>
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 22:12:05 -0000

> - I'm not sure how that works.  Can you authenticate an entity without
> identifying them?  The rest of the document seems silent on this topic
>=20

[BA] since AAA protocols require identification in some form, how is this po=
ssible?

> - Why exclude the Web?  And if we're excluding the web, what kind of authe=
ntication *is* it designed for?

[BA] The problem is that so many app layer protocols now are being subsumed b=
y the Web that in reality this doesn't leave much left - and just because a p=
rotocol supports SASL doesn't mean it is a valid ABFAB use case.

>=20
>   o  The system will build upon existing standards, components, and
>      operational practices.
>=20
> - that's good, but I'm not sure it needs to be explicitly called out.

[BA ] is this really true? Doesn't ABFAB require non-backwards compatible ex=
tensions?=20
>  The ABFAB architecture
> is a complex system which has a lot of moving pieces.  The document does
> a good job of describing them.

[BA ] Since ABFAB shares many of the same goals and use cases (and a compara=
ble degree of complexity) to IMS, it might be useful to provide an argument f=
or why ABFAB is more likely to be deployed.=20=


From nobody Wed Mar 26 15:36:59 2014
Return-Path: <aland@deployingradius.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5981A03E6 for <aaa-doctors@ietfa.amsl.com>; Wed, 26 Mar 2014 15:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUt4PsGEzf1e for <aaa-doctors@ietfa.amsl.com>; Wed, 26 Mar 2014 15:36:53 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68B1A03DC for <aaa-doctors@ietf.org>; Wed, 26 Mar 2014 15:36:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7A911224016C; Wed, 26 Mar 2014 23:36:20 +0100 (CET)
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 gsr7g9EfeMXR; Wed, 26 Mar 2014 23:36:18 +0100 (CET)
Received: from Thor.local (bas1-ottawa11-1176224686.dsl.bell.ca [70.27.195.174]) by power.freeradius.org (Postfix) with ESMTPSA id 111912240023; Wed, 26 Mar 2014 23:36:17 +0100 (CET)
Message-ID: <53335660.2040304@deployingradius.com>
Date: Wed, 26 Mar 2014 18:36:16 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <530BD115.7020902@cisco.com> <531D8EDC.9010106@cisco.com> <53282F13.207@cisco.com> <53284729.3040503@deployingradius.com> <53284F20.5030009@cisco.com> <53303AA3.2050700@cisco.com> <53332855.9030909@deployingradius.com> <BLU406-EAS323D99D6F02597E377F281293640@phx.gbl>
In-Reply-To: <BLU406-EAS323D99D6F02597E377F281293640@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/sF8t246o41j4AupbMP4i6-Wm6nI
Cc: "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>, Joel jaeggli <joelja@bogus.com>
Subject: Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 22:36:56 -0000

Bernard Aboba wrote:
>> - I'm not sure how that works.  Can you authenticate an entity without
>> identifying them?  The rest of the document seems silent on this topic
>>
> 
> [BA] since AAA protocols require identification in some form, how is this possible?

  I don't think it is.

>> - Why exclude the Web?  And if we're excluding the web, what kind of authentication *is* it designed for?
> 
> [BA] The problem is that so many app layer protocols now are being subsumed by the Web that in reality this doesn't leave much left - and just because a protocol supports SASL doesn't mean it is a valid ABFAB use case.

  I agree.

>>   o  The system will build upon existing standards, components, and
>>      operational practices.
>>
>> - that's good, but I'm not sure it needs to be explicitly called out.
> 
> [BA ] is this really true? Doesn't ABFAB require non-backwards compatible extensions?

  Yes.  But I suspect most IETF standards build on existing standards,
components, etc.

>>  The ABFAB architecture
>> is a complex system which has a lot of moving pieces.  The document does
>> a good job of describing them.
> 
> [BA ] Since ABFAB shares many of the same goals and use cases (and a comparable degree of complexity) to IMS, it might be useful to provide an argument for why ABFAB is more likely to be deployed. 

  Or situations where it's likely to be deployed instead of IMS.

  Alan DeKok.


From nobody Thu Mar 27 07:17:59 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD2C1A06F5; Thu, 27 Mar 2014 07:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-_zhDJ7gvzt; Thu, 27 Mar 2014 07:17:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C981A027F; Thu, 27 Mar 2014 07:17:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Benoit Claise" <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140327141752.15490.22059.idtracker@ietfa.amsl.com>
Date: Thu, 27 Mar 2014 07:17:52 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/lO8jTOeabefCtYC8c8EN8hFTyCs
Cc: aaa-doctors@ietf.org, abfab-chairs@tools.ietf.org, draft-ietf-abfab-arch@tools.ietf.org
Subject: [AAA-DOCTORS] Benoit Claise's No Objection on draft-ietf-abfab-arch-12: (with COMMENT)
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Mar 2014 14:17:56 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-abfab-arch-12: No Objection

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


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


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-abfab-arch/



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

Here is the AAA-doctor thorough review by Alan DeKok:

  Here we go.  In short, the document is good, but seems to assume a
familiarity with the concepts being discussed.  It talks about concepts
without introducing them, leading to confusion on the part of the naive
reader.

Section 1

   Numerous security mechanisms have been deployed on the Internet to
   manage access to various resources.

- This is a bit vague.  "Security does stuff". Some examples would help.

   A Relying Party (RP) is the entity that manages access to some
   resource

- This sentence jumps discontinuously from the previous paragraph.  Why
are we talking about Relying parties?  It's generally easier to talk
about problems, and then to introduce solutions to those problems.

     ... The entity that is requesting access to that resource is
   often described as the Client.

  Why not use "Client" and "Server"?  Jumping straight to new
terminology is awkward.

   Some security mechanisms allow the RP to delegate aspects of the
   access management decision to an entity called the Identity Provider
   (IdP).  This delegation requires technical signaling, trust and a
   common understanding of semantics between the RP and IdP.  These
   aspects are generally managed within a relationship known as a
   'federation'.

- The "federation" doesn't follow from delegation.  System A can
delegate functionality to system B, but that's just delegation.  I would
expect to see motivation for federation.

- e.g. when there are many people trying to authenticate, the Server may
not have credentials for all of them.  It may delegate the
authentication to one or more secondary Servers.  Any grouping of
Servers to achieve a common purpose is called a "federation"

- once we define the problem space in terms of *existing* terminology,
it's then possible to introduce *new* terminology.

   Single or Simplified sign-on:

      An Internet service can delegate access management

- what's an "Internet Service" ?  That's the first use of the term in
this document.  Is it a Relying Party?  A generic Server?

      Often a Relying Party does not need to know the identity of a
      Client to reach an access management decision.  It is frequently
      only necessary for the Relying Party to know specific attributes
      about the client,

- nitpick I'd use "properties" rather than "attributes".  Attributes
have a well-defined meaning in AAA space.  The properties talked about
above may not be transported in attributes, so they shouldn't be called
attributes.

      Prior to the release of attributes to the RP from the IdP, the IdP
      will check configuration and policy to determine if the attributes
      are to be released.

- Why is an IdP releasing attributes to the RP?  This is the first
mention of it.

      Sometimes a Relying Party needs, or would like, to know more about
      a client than an affiliation or a pseudonym.

- Why?  Because "it's Tuesday, and I want to know his shoe size"?  Or
are there problems whih are solved by asking for additional information?

   This memo describes the Application Bridging for Federated Access
   Beyond the Web (ABFAB) architecture.  This architecture makes use of
   extensions to the commonly used security mechanisms for both
   federated and non-federated access management, including RADIUS, the
   Generic Security Service (GSS), the Extensible Authentication
   Protocol (EAP) and SAML.  The architecture should be extended to use
   Diameter in the future.  The architecture addresses the problem of
   federated access management primarily for non-web-based services.

- the last sentence there should be moved to be the second one.
  i.e. What is ABFAB.  Problem to be solved.  Technology used to solve
  the problem.

Section 1.1

   This document uses identity management and privacy terminology from
   [RFC6973].  In particular, this document uses the terms identity
   provider, relying party, identifier, pseudonymity, unlinkability, and
   anonymity.

- that sentence could be moved to earlier in the document.  It gives a
basis for the terminology used in Section 1.  Or, re-word Section 1 to
use less of the terminology introduced in Section 1.1.

   This document uses the term Network Access Identifier (NAI), as
   defined in [I-D.ietf-radext-nai].  An NAI consists of a realm
   identifier, which is associated with an IdP

- Why is a realm associated with an IdP?  Again, motivation.  Does the
*document* use the NAI, or does it assume that the *authentication it
talks about* uses the NAI?

- e.g. We assume that each authentication request in the ABFAB
architecture includes an NAI.  The realm portion of the NAI is used to
distinguish and/or select an IdP.  Each IdP may have one or more realms.

   One of the problems some people have found with reading this document
   is that the terminology sometimes appears to be inconsistent.  This
   is due the fact that the terms used by the different standards we are
   referencing are not consistent with each other.  In general the
   document uses either the ABFAB term or the term associated with the
   standard under discussion as appropriate.

- nitpick: I would say that for general cases, this document uses the
terminology from RFC 6973, as it is cross-standard.  Where this document
refers to actions of a particular protocol, the protocol-specific terms
are used.  e.g. "ABFAB relies on an IdP", versus "the RADIUS client ..."

- doing so should make the document clearer

   Note that in some cases a cell has been left empty; in these cases
   there is no name that represents the entity.

- nitpick: there is no name *within that standard* which defines the
given term.

   This document uses the term channel binding with two different
   meanings.

- I would say "in two different contexts".  The later specification of
"EAP channel bindings" and "GSS-API channel bindings" makes the
distinction clear.  The term "channel bindings" therefore does not have
two different meanings, as it should be used only within the context of
"EAP" or "GSS-API".

   Federation

      The Identity Provider and the Relying Parties are part of a
      Federation.  The relationship may be direct (they have an explicit
      trust relationship) or transitive (the trust relationship is
      mediated by one or more entities).  The federation relationship is
      governed by a federation agreement.  Within a single federation,
      there may be multiple Identity Providers as well as multiple
      Relying Parties.

- I find this confusing, and not in line with the other definitions.  A
definition should be of the form:

  FOO
    FOO is thing which does BAR, and used BAZ and BARK to do so.

- e.g.  A Federation is composed of a set of Identity Providers and
Relying Parties.  The IdPs and RPs may have explicit trust relationships
with each other, or the trust may be mediated by one more more entities
within that federation.  The relationships between IdPs and RPs is
governed by a federation agreement, which is outside of the scope of
this specification.

   Authentication

      There is a direct relationship between the Client and the Identity
      Provider.  This relationship provides the means by which they
      trust each other and can securely authenticate each other.

- the same comment applies here.  Authentication is *something*.  The
first sentence of the definition above seems to have no bearing on
authentication

  Operational Specifications:

- put the last sentence first, which motivates the rest of the
paragraph.

   The Operational Specifications can demand the usage of a
   sophisticated technical infrastructure,

- as opposed to a crappy technical infrastructure?  I suggest just
deleting the word "sophisticated"

   While a federation agreement is often discussed within the context of
   formal relationships, such as between an enterprise and an employee
   or a government and a citizen,

- who is doing that discussion?  I don't see it in this document.  Some
clarity would help here.

   For an IdP and a
   Client, it is sufficient for a relationship to be established by
   something as simple as using a web form and confirmation email.

- are we suggesting implementation details?  If so, why does it matter?

   The nature of federation dictates that there is some form of
   relationship between the identity provider and the relying party.
   This is particularly important when the relying party wants to use
   information obtained from the identity provider for access management
   decisions and when the identity provider does not want to release
   information to every relying party (or only under certain
   conditions).

- Suggest capitalization of terms, to match the rest of the draft

   While it is possible to have a bilateral agreement between every IdP
   and every RP; on an Internet scale this setup requires the
   introduction of the multi-lateral federation concept, as the
   management of such pair-wise relationships would otherwise prove
   burdensome.

- what is a "multi-lateral federation concept"?  A concept?  A real
thing?

   The nature and quality of the relationship between the Client and the
   IdP is an important contributor to the level of trust that an RP may
   attribute to an assertion

- "attribute" is used in other contexts here.  I'd suggest using a
synonym for "attribute"

   Federation does not require an a priori relationship or a long-term
   relationship between the RP and the Client; it is this property of
   federation that yields many of its benefits.

- what does "its" refer to?  The federation?  The relationship?

   However, federation
   does not preclude the possibility of a pre-existing relationship
   between the RP and the Client, nor that they may use the introduction
   to create a new long-term relationship independent of the federation.

- nitpick: I would say that the entities may have relationships outside
of the federation, including ones prior and post to the federation

   As the number of federated IdPs and RPs (services) proliferats,

- typo "proliferates".  And why is (services) there?  Are RPs just RPs,
or are they now (services)?  I suggest deleting it.

   As the number of federated IdPs and RPs (services) proliferats, the
   role of the individual

- ... was not previously discussed.  I suggest replacing that with
something like "an individual may have multiple identities (NAIs), and
choose the correct identity for network access"

  For instance, in the case of an email
   provider, the SMTP and IMAP protocols do not have the ability for the
   server to request information from the client, beyond the clients
   NAI, that the server would then use to decide between the multiple
   federations it is associated with.

Section 1.4

- nitpick: that's a long sentence.  Suggest breaking it up into smaller
fragments.

   In this example, a client is attempting to connect to a server

- nitpick: suggest passive voice. "a client attempts to connect ..."

- many of the following paragraphs have "X is configured".  OK, how?
Maybe "we assume that configuration discussed below is out of band, e.g.
via manual administrator action"


Section 1.5

   o  Each party in a transaction will be authenticated, although
      perhaps not identified,

- I'm not sure how that works.  Can you authenticate an entity without
identifying them?  The rest of the document seems silent on this topic

- Generally, there's a lot of lower-case use of "identity providers",
"relying parties", etc.  Please use consistent terms.  IdPs and RPs is
probably good enough, given the number of uses of those terms in the
document

   o  The system will be designed primarily for non-Web-based
      authentication.

- Why exclude the Web?  And if we're excluding the web, what kind of
authentication *is* it designed for?

   o  The system will build upon existing standards, components, and
      operational practices.

- that's good, but I'm not sure it needs to be explicitly called out.

   A lot of attention on
   federated access has been devoted to the Web.  This document instead
   focuses on a non-Web-based environment and focuses on those protocols
   where HTTP is not used.

- it would be useful to say why web-based systems aren't useful here.
i.e. OAUTH, etc. presumes that the user already has network access.
OAUTH mediates access to *services* on an existing network.  ABFAB
mediates access to *networks*, especially visited networks.

Section 2

   The main theme of the work described in this
   document is focused on re-using existing building blocks that have
   been deployed already and to re-arrange them in a novel way.

- the re-arrangement is not the goal, surely.  Instead, it's "re-arrange
them in a novel way to achieve global federated network access with
minimal changes to existing systems"

- that motivation also affects the first sentence of the next paragraph

Section 2.1

   Protocols that support the same framework, but do different routing
   are expected to be defined and used the future.  One such effort call
   the Trust Router

- nitpick: callED the Trust Router...

Section 2.1.1

   The usage of the AAA framework with RADIUS [RFC2865] and Diameter
   [RFC6733] for network access authentication has been successful from
   a deployment point of view.  To map to the terminology used in
   Figure 1 to the AAA framework

- it may be worth referring again to the table earlier in Section 1.
But reminding the reader of it here is a good idea.

Section 2.1.5

   For the traditional use of AAA frameworks, network access, the only
   requirement that was necessary to grant access was an affirmative
   response from the IdP.

- not completely true.  An affirmative response is the minimal
requirement.  Very often, additional authorization attributes are needed
 (e.g. Service-Type).  RFC 2865 Section 5.6 says this about
Service-Type:

      A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead.

   ... This means that the RP needs to map from the SAML
   issuer or federation name, type and semantic into the name, type and
   semantics that the policies of the RP are written in.

- some guidance here would be useful.  How is that mapping done?  Or is
it just "implementation defined" ?

   Some RPs need to ensure that specific criteria are met during the
   authentication process.  This need is met by using Levels of
   Assurance.

- This is the first mention of "Levels of Assurance".  It's important
enough to capitalize, so it's a apparently a key concept.  But there's
no corresponding definition anywhere.

Section 2.3.1

   So, we use GSS-API and SASL because a number of the application
   protocols we wish to federate support these strategies for security
   integration.  What does this mean from a protocol standpoint and how
   does this relate to other layers?  This means we need to design a
   concrete GSS-API mechanism.

- while explanatory, asking && answering questions is a little odd in a
standards document.  I suggest trying to re-word this to be explanatory
instead

Section 4.2.2

   ... (such as
   the use of TLS for RADIUS [I-D.ietf-radext-dtls]).

- Maybe refer to RFC 6614 instead of the DTLS draft

  Also "mitigted"

- mis-spelled

   Note that ABFAB has not specified any AAA accounting requirements.
   Implementations that use the accounting portion of AAA should
   consider privacy appropriately when designing this aspect.

- specific suggestions would be useful here.  e.g. use CUI for user
identifiers, to give user anonymity.  Ensure that the accounting packets
contain no more information than what's in the Access-Request, etc.

Section 4.4

- it may be worth moving the last paragraph of Section 4.2.2
(accounting) to this section.

Section 5

   ...  In situations where the client is not yet on the
   net, ...

- that situation wasn't clearly described earlier in the document.  (or
at least so far as I recall).  Earlier text also talked about clients
having IP addresses.  It would be good to clarify just which situations
will apply to ABFAB.  Concrete examples would help.

- it may be useful to add a section with concrete examples.  Describe
the scenarios (user visiting remote site), and then a short discussion
of what happens, and what protocols are used.  Show which portions are
new to ABFAB, and which ones already exist.



  Despite my nits, the document is pretty good overall.  My comments are
largely related to clarifications, style, etc.  The ABFAB architecture
is a complex system which has a lot of moving pieces.  The document does
a good job of describing them.



From nobody Sat Mar 29 17:32:53 2014
Return-Path: <aland@freeradius.org>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34F11A068D for <aaa-doctors@ietfa.amsl.com>; Sat, 29 Mar 2014 17:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0JqoKNRcraB for <aaa-doctors@ietfa.amsl.com>; Sat, 29 Mar 2014 17:32:47 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 532E61A0365 for <aaa-doctors@ietf.org>; Sat, 29 Mar 2014 17:32:46 -0700 (PDT)
Received: by power.freeradius.org (Postfix, from userid 1000) id D51B12240541; Sun, 30 Mar 2014 01:32:12 +0100 (CET)
From: aland@freeradius.org
To: <aaa-doctors@ietf.org>
X-Mailer: mail (GNU Mailutils 2.2)
Message-Id: <20140330003212.D51B12240541@power.freeradius.org>
Date: Sun, 30 Mar 2014 01:32:12 +0100 (CET)
Archived-At: http://mailarchive.ietf.org/arch/msg/aaa-doctors/OrEPExVvf3MhYx004IbVFIVVzF8
Subject: [AAA-DOCTORS] Automatic tech report for Sun Mar 30 01:32:11 CET 2014
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Mar 2014 00:32:49 -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-aaa-saml-09                      Active	
draft-ietf-abfab-arch-12                          In IESG processing - ID Tracker state <Approved-announcement to be sent::Point Raised - writeup needed>	
draft-ietf-netmod-system-mgmt-13                  In IESG processing - ID Tracker state <IESG Evaluation::Revised I-D Needed>	
draft-ietf-softwire-map-radius-01                 Active