ietf
[Top] [All Lists]

RE: Last Call: <draft-ietf-nea-pt-eap-06.txt> (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard

2013-01-14 16:19:24
Changing our reference to RFC 5209 to be normative may cause
more problems than it solves. As RFC 3967 (BCP 97) says,

IETF procedures generally require that a standards track RFC
may not have a normative reference to another standards track
document at a lower maturity level or to a non standards track
specification (other than specifications from other standards
bodies). For example, a standards track document may not have
a normative reference to an informational RFC.

Generally, documents that contain use cases or architectures are
Informational. References to such documents in a standards track
document are informative because referring to the use cases is
not required in order to implement the standard.

RFC 5209 lists use cases for NEA, describes a reference model
for NEA, and includes requirements that the NEA protocols must
meet. None of the requirements in RFC 5209 are requirements on
implementations of the NEA protocols. Therefore, the PT-EAP spec
should not include a normative reference to RFC 5209. And that's
good, because RFC 5209 is an Informational RFC.

If I've missed something (e.g. a reason why the reference should
be normative), please explain it more clearly.

Thanks,

Steve

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
SM
Sent: Monday, January 14, 2013 4:34 PM
To: Nancy Cam-Winget (ncamwing)
Cc: ietf-privacy(_at_)ietf(_dot_)org; nea(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-ietf-nea-pt-eap-06.txt> (PT-EAP: Posture
Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard

Hi Nancy,
At 12:29 14-01-2013, Nancy Cam-Winget (ncamwing) wrote:
[NCW] I can change it to a lower case "must", ok?

That's ok.

[NCW] We can move the reference to be normative.

Ok.

[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.

If I understood the above correctly PT-EAP does not transport any
information which could be used to identify an individual.  That's
different from PT-EAP not being an "authenticated" method. Therefore,
there isn't much to say in terms of privacy considerations.

I suggest not including the following then:

   "As a transport protocol, PT-EAP does not directly utilize or
    require direct knowledge of any personally identifiable
    information (PII)."

The draft can leverage the second paragraph of Section 6 as "privacy
considerations" instead of making a statement about PII.  I'll copy
this message to ietf-privacy@ to get a better opinion.

In Section 6:

   "Therefore, it is important for deployers to leverage these
    protections in order to prevent disclosure of PII potentially
    contained within PA-TNC or PB-TNC within the PT-EAP payload."

I suggest "information about an individual" instead of PII [1].

Regards,
-sm

1. I used the wording from draft-iab-privacy-considerations-06