A GSS-API Mechanism for the Extensible Authentication Protocol
draft-ietf-abfab-gss-eap-09

Note: This ballot was opened for revision 08 and is now closed.

(Stephen Farrell; former steering group member) Yes

Yes ( for -08)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2012-07-18 for -08)
No email
send info
Just one small thing about the IANA Considerations: The reference to "section 4.1 of RFC 4121" makes it clear, but it would be useful if one detail of the registry in 7.2 were specified here... the "ID" field is two octets, specified in hex in big-endian order.  Having that bit here will make it easier for IANA to see that IDs have been specified correctly, without their having to go look in RFC 4121.

(Benoît Claise; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection (2012-07-18 for -08)
No email
send info
Only nits:

1) abstract: expand GS2.

2) s1: First sentence reads a little odd: The architecture describes an architecture.  Maybe the following is a little better:

OLD:

 The ABFAB architecture [I-D.ietf-abfab-arch] describes an
 architecture for providing federated access management to
 …

NEW:

 ABFAB [I-D.ietf-abfab-arch] describes an
 architecture for providing federated access management to

3) s1: Maybe r/backend authentication server/backend authentication, authorization, and accounting (AAA) server
that way AAA is expanded and introduced.

4) s3.1: r/mechanism.The/mechanism. The

5) s3.4: r/name.All/name. All

6) s5: r/and body must be present/and body MUST be present

7) s5.1: r/[RFC3961]is/[RFC3961] is

8) s5.5.1 & s5.5.2 : r/required/REQUIRED

9) s6: r/l bits of its input/L bits of its input  - ought to match the notation later which is uppercase L

10) s10.2: There are some outdated references:

== Outdated reference: A later version (-03) exists of
   draft-ietf-abfab-arch-02

== Outdated reference: draft-ietf-krb-wg-gss-cb-hash-agility has been
   published as RFC 6542

== Outdated reference: A later version (-06) exists of
   draft-ietf-radext-radius-extensions-05

== Outdated reference: draft-ietf-radext-radsec has been published as RFC
   6614

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -08)
No email
send info