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 Hanna <[e-mail]>]

Stephen,

Thanks for the guidance. As you recommend, we'll proceed
without this change for now. If it becomes a problem,
we'll cycle back and do the downref thing.

Take care,

Steve

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Monday, January 14, 2013 7:07 PM
> To: Stephen Hanna
> Cc: SM; [e-mail]
> Subject: Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.txt> (PT-EAP:
> Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed
> Standard
> 
> 
> 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
> >
> >