Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
RFC 5422
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Lars Eggert No Objection
The document writeup says "This is not the product of any working group. This is part of the ongoing effort to document existing deployed EAP methods. The purpose of this document is to publish existing behavior." That doesn't come out in the document at all. I wonder if this should be explicitly called out in the abstract and/or introduction?
(Tim Polk; former steering group member) Yes
(Chris Newman; former steering group member) (was Discuss) No Objection
When defining a registry, it's helpful to give a title for the registry as this is the only way readers of the document can find the IANA registry. For example, "EAP-FAST PAC Attribute Types" registry, or "PAC Attribute Type" sub-registry of the "EAP-FAST" registry.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
General area seems odd for this document. Tracker mistake?
(Pasi Eronen; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Vijay Gurbani did a Gen-ART Review of -08 and -09 of this document.
Please consider the two comments that he raised:
1/ In S4.1.{2,3}, there is a term "PAC opaque". I think you
mean "PAC-Opaque", the opaque data that was defined in S4.1.1.
2/ In S6.3, first paragraph: should the "should" on line 3 be
normative? More so especially since the "MAY" seven lines
down is normative.