Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism
draft-ietf-abfab-gss-eap-naming-07

[Ballot comment]

  The authors have agreed to implement the suggestions from the Gen-ART
  Review by Suresh Krishnan on 8-Oct-2012.  These have not been folded
  into the draft yet, but I am confident this will happen.

[Ballot comment]
I'm not making this first comment a DISCUSS, but I think it's important to address it.  Feel free to chat with me about it:

-- Section 8 --
  In this top-level registry, a sub-registry titled "GSS-API URN
  Parameters" is created.  Registration in this registry is by the IETF
  review or expert review procedures [RFC5226].  Registrations in this
  registry are generally only expected as part of protocols published
  as RFCs on the IETF stream; other URIs are expected to be better
  choices for non-IETf work.  Expert review is permitted mainly to
  permit early registration related to specifications under development
  when the community believes they have reach sufficient maturity.

IANA is taking this to mean that registrations are always done by IETF Review, and that Expert Review can only be used for early registrations that will later be ratified by IETF Review.  That's not how I read this text, though, so I want to check that IANA's interpretation is what you want.

As I read it, you intend Expert Review to apply *mainly* for early registration, but there's an implication that it could be used *instead* of IETF Review as well (otherwise, what does "mainly" mean?).  You also have no instructions or guidelines for the designated expert.  You talk about what "the community believes", but provide no guidance on judging that, nor any guidance for what else the designated expert should consider.

I strongly recommend that you re-write the registration policy to make it clear exactly when IETF Review applies and when Expert Review can be used, and to give some clear direction to the designated expert.

========

A nitty comment on idnits:

In the shepherd writeup:
  ID Nits says: "Unused Reference: 'I-D.ietf-kitten-gssapi-naming-exts'
  is defined on line 363, but no explicit reference was found in the text"
  This draft is referenced in paragraph 1 (Introduction)

idnits calls it out because there's no space between the citation and the word "to" that follows.  So it got confused.

IANA has reviewed draft-ietf-abfab-gss-eap-naming-05 and has
the following comments:

IANA understands that, upon approval of this document, there are three
IANA actions which must be completed.

First, IANA is to create a new top-level registry in the IANA Matrix
located at:

http://www.iana.org/protocols/

This registry will be named "Generic Security Service Application Program
Interface Parameters" and will have a reference of [ RFC-to-be ].

Second, in the new registry created in task one above a new sub-registry titled
"GSS-API URN Parameters" will be created. Maintenance of this registry is by
the IETF review or expert review procedures as defined in RFC 5226.
Registrations in this this new subregistry will be via IETF review. Early
registrations are allowed through Expert Review.

There are initial registrations in this new sub-registry as follows:

Parameter Reference
--------------------------------+-----------------
radius-attribute [ RFC-to-be ]
federated-saml-assertion [ RFC-to-be ]
federated-saml-attribute [ RFC-to-be ]
federated-saml-nameid [ RFC-to-be ]

Third, IETF URN Sub-namespace for Registered Protocol Parameter Identifiers
sub-registry of the IETF Protocol Parameter Identifiers located at:

http://www.iana.org/assignments/params/params.xml

a new URN will be registered as follows:

Registered Parameter Identifier: gss
Reference: [ RFC-to-be ]
IANA Registry Reference: [ URL from step one above ]

IANA understands that these are the only actions required to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard


The IESG has received a request from the Application Bridging for
Federated Access Beyond web WG (abfab) to consider the following
document:
- 'Name Attributes for the GSS-API EAP mechanism'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The naming extensions to the Generic Security Services Application
  Programming interface provide a mechanism for applications to
  discover authorization and personalization information associated
  with GSS-API names.  The Extensible Authentication Protocol GSS-API
  mechanism allows an Authentication/Authorization/Accounting peer to
  provide authorization attributes along side an authentication
  response.  It also provides mechanisms to process Security Assertion
  Markup Language (SAML) messages provided in the AAA response.  This
  document describes the necessary information to use the naming
  extensions API to access that information.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming/ballot/


No IPR declarations have been submitted directly on this I-D.