[abfab] Protocol Action: 'Update to the EAP Applicability Statement for ABFAB' to Proposed Standard (draft-ietf-abfab-eapapplicability-06.txt)
The IESG <iesg-secretary@ietf.org> Fri, 27 September 2013 14:25 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4A221F9385; Fri, 27 Sep 2013 07:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.5
X-Spam-Level:
X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haZ+Nq0+E0dh; Fri, 27 Sep 2013 07:25:18 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 952A721F9808; Fri, 27 Sep 2013 07:25:17 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.72
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20130927142517.11230.35151.idtracker@ietfa.amsl.com>
Date: Fri, 27 Sep 2013 07:25:17 -0700
Cc: abfab mailing list <abfab@ietf.org>, abfab chair <abfab-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [abfab] Protocol Action: 'Update to the EAP Applicability Statement for ABFAB' to Proposed Standard (draft-ietf-abfab-eapapplicability-06.txt)
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2013 14:25:19 -0000
The IESG has approved the following document: - 'Update to the EAP Applicability Statement for ABFAB' (draft-ietf-abfab-eapapplicability-06.txt) as Proposed Standard This document is the product of the Application Bridging for Federated Access Beyond web Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ Technical Summary The EAP applicability statement in [RFC3748] defines the scope of the Extensible Authentication Protocol to be "for use in network access authentication, where IP layer connectivity may not be available.", and states that "Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.". While some of the recommendation against usage of EAP for bulk data transport is still valid, some of the other provisions in the applicability statement have turned out to be too narrow. This document describes the applicability of EAP for (certain) application layer access decisions. Working Group Summary The WG (as well as emu) has debated extensively as to whether to revise the EAP-applicability statement completely or to focus on the particular requirements for abfab. It was decided to keep it limited to abfab in the interest of progressing the work items. Document Quality This being an applicability statement, there is no question of implementations. What can be said is that the existing implementations of abfab use the relaxed applicability statement. Personnel Shepherd: Klaas Wierenga AD: Stephen Farell RFC Editor Note Please add a new sentence to the end of section 3 (and the associated informative reference), so: OLD, at the end of section 3: Circumstances might require that applications need to perform conversion of identities from an application specific character set to UTF-8 or another character set required by a particular EAP method. NEW Circumstances might require that applications need to perform conversion of identities from an application specific character set to UTF-8 or another character set required by a particular EAP method. See also [draft-ietf-radext-nai], Section 2.6, for information about normalization of identifiers. NEW, section 7.2: Add [draft-ietf-radext-nai]