Hi SM, Thanks for the thorough review of the draft. Please see comments below: On 1/8/13 11:25 PM, "SM" <sm@xxxxxxxxxxxx> wrote: >At 06:43 02-01-2013, The IESG wrote: >>The IESG has received a request from the Network Endpoint Assessment WG >>(nea) to consider the following document: >>- 'PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods' >> <draft-ietf-nea-pt-eap-06.txt> 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@xxxxxxxx mailing lists by 2013-01-16. Exceptionally, comments may be > >This is a quick comment. > >In Section 1: > > "The PT-EAP protocol MUST be protected by an outer > TLS-based EAP tunnel method to ensure the exchanged messages are > protected from a variety of threats from hostile intermediaries." > >The RFC 2119 boilerplate is after that "MUST". [NCW] I can change it to a lower case "must", ok? > >In Section 1.1: > > "This document does not define an architecture or reference model. > Instead, it defines a protocol that works within the reference model > described in the NEA Requirements specification [RFC5209]." > >The reference is informative. [NCW] We can move the reference to be normative. > >In Section 6: > > "PT-EAP does not directly utilize or require direct knowledge of > any personally identifiable information (PII). PT-EAP will > typically be used in conjunction with other EAP methods > that provide for the user authentication (if bi-directional > authentication is used), so the user's credentials are not > directly seen by the PT-EAP inner method." > >Section 9 RFC 5209 mentions that: > > "However, in situations where the endpoint is owned by the user > or where local laws protect the rights of the user even when > using endpoints owned by another party, it is critical that the NEA > implementation enable the user to control what endpoint information > is shared with the network." > >I didn't find any information in the draft to assess the privacy >implications. Are there any such implications? [NCW] I don't think there are specifically for PT-EAP. The sections you reference Were to (in section 6) addressing the general EAP identity as PT-EAP is really not An "authentication" method. > >Regards, >-sm >