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

[Stephen Farrell <[e-mail]>]

Hiya,

On 01/14/2013 11:41 PM, Stephen Hanna wrote:
> SM wrote:
>> It's a matter of mentioning the down-ref in the Last Call announcement.
> 
> I understand that we COULD request approval for a downward reference.
> We'd need to restart the IETF Last Call in order to do so but if that's
> the right thing to do, we can do it.
> 
> I just don't see why we need a downref. Yes, you should understand the
> NEA reference model while building an implementation of PT-EAP. You also
> should understand the EAP architecture and PB-TNC and lots of other things.
> That doesn't mean that all those things should be normative references.
> RFC 5209 doesn't include ANY normative text that would affect implementers
> of PT-EAP. An informative reference seems more appropriate to me. And
> that's what we did for all the other NEA specs (PA-TNC, PB-TNC, and
> PT-TLS). PB-TNC (RFC 5793) includes basically the same language as PT-EAP:
> 
> 1.1.  Prerequisites
> 
>    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 [8].  The reader is
>    assumed to be thoroughly familiar with that document.  No familiarity
>    with TCG specifications is assumed.
> 
> Still, I know that the IETF process can be unpredictable. If we
> now think that we need to have a normative reference in this spec,
> we can change it and run the IETF Last Call process again, requesting
> approval for a downref to RFC 5209.
> 
> What is the sense of the Working Group? Any guidance from the ADs?

I bet you know:-)

Ignore it and push on. If we get stuck then we go back to IETF LC
then and fix. The precedent in the WG should be enough to see it
through I'd say esp since PT-TLS is so recent (still in the RFC
editor queue) with precisely the same reference. Neither IETF
LC called out this out as a downref.

SM does have a point, but OTOH so do you, and yes the IESG is
fickle about stuff like this, and BCP97 doesn't really deal with
requirement or framework RFCs (I guess those are a subsequent
fad;-). And in this case, 5209 is requirements plus the
overview and I think you can credibly say that in reality a
coder who's gotten as far as coding up PT-EAP already does
know the overview, and the reqiurements are not relevant
for that coder, so this is a purely process problem if it
is a problem of any sort and does no harm to the Internet.

S.

> 
> Thanks,
> 
> Steve
> 
>> -----Original Message-----
>> From: SM [mailto:[e-mail]]
>> Sent: Monday, January 14, 2013 5:47 PM
>> To: Stephen Hanna
>> Cc: [e-mail]; Nancy Cam-Winget (ncamwing)
>> 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 Stephen,
>> At 14:17 14-01-2013, Stephen Hanna wrote:
>>> Changing our reference to RFC 5209 to be normative may cause
>>> more problems than it solves. As RFC 3967 (BCP 97) says,
>>
>> Yes.
>>
>>  From Section 1.1:
>>
>>    "The reader is assumed to be thoroughly familiar with that
>>     document." (RFC 5209)
>>
>>>> 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.
>>
>> It's a matter of mentioning the down-ref in the Last Call announcement.
>>
>>> If I've missed something (e.g. a reason why the reference should
>>> be normative), please explain it more clearly.
>>
>> See above.  I flagged it as the matter may be raised as an issue.  I
>> am ok with whatever the WG decides.
>>
>> Regards,
>> -sm
>>
> 
> 
> _______________________________________________
> Nea mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nea
> 
>