PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods
draft-ietf-nea-pt-eap-09
Yes
(Stephen Farrell)
No Objection
(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 08 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(2013-01-30 for -08)
Unknown
-- Section 7 -- This document also defines one new IANA top-level registry: PT-EAP Versions. This section explains how this registry works. Because only eight (8) values are available in this registry, a high bar is set for new assignments. The only way to register new values in this registry is through Standards Action (via an approved Standards Track RFC). Thanks very much for including an explanation of your choice of registration policy. I really appreciate that. I have a very tiny, non-blocking point, of no significance other than tidiness of the IANA registries. From IANA's last-call comments: Second, a new registry is to be created. This registry will be called the "PT-EAP Versions" registry. The document requests that the be a top-level registry in the IANA Matrix. They're referring to the "new IANA top-level registry" bit above. Is there a good reason for this to have its own group on the main IANA page? I suggest this: There's a group called "TLS-based Posture Transport Protocol (PT-TLS)", which has the PT-TLS Error Codes and PT-TLS Message Types registries in it. Might it be reasonable to rename that group to "Posture Transport Protocols (PT-EAP and PT-TLS)", and to add this registry to that top-level group?
Stephen Farrell Former IESG member
Yes
Yes
(for -08)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -08)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -08)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -08)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -08)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -08)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2013-02-04 for -08)
Unknown
Section 5: The security requirements described in this specification MUST be implemented in any product claiming to be PT-EAP compliant. I couldn't tell *why* a product claiming to be PT-EAP compliant MUST implement the security requirements described in this specification. I think the abobe sentence could mean one of two things: 1. It means, "A product claiming to be PT-EAP compliant implements all of the security requirements described in this specification." That is to say, it's simply describing what it means to be compliant. If that's what is meant, say that; MUST isn't helping anything. 2. It means, "There are security requirements described in this specification that MUST be implemented because they are required for interoperability or to prevent harm." If that's what is meant, please list the particular sections these requirements appear, or list a summary of them here. Saying that I MUST do some things without telling me what specifically I MUST do is not helpful.
Ralph Droms Former IESG member
No Objection
No Objection
(for -08)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -08)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -08)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -08)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-03-29)
Unknown
Thanks for dealing with my discuss.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -08)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -08)
Unknown