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 <stephen.farrell@cs.tcd.ie> Tue, 15 January 2013 00:27 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: nea@ietfa.amsl.com
Delivered-To: nea@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB4B21F8B62 for <nea@ietfa.amsl.com>; Mon, 14 Jan 2013 16:27:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6EGhtybvuvn for <nea@ietfa.amsl.com>; Mon, 14 Jan 2013 16:27:27 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7F21F8824 for <nea@ietf.org>; Mon, 14 Jan 2013 16:27:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 10000BE47; Tue, 15 Jan 2013 00:27:05 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5+hCkJsP2-r; Tue, 15 Jan 2013 00:27:02 +0000 (GMT)
Received: from [10.87.48.8] (unknown [86.41.50.151]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A8FD0BE3F; Tue, 15 Jan 2013 00:27:02 +0000 (GMT)
References: <6.2.5.6.2.20130108225436.0b31f008@resistor.net> <B80278DF1B7C814184086F4A6ECB3115225B9B21@xmb-aln-x02.cisco.com> <6.2.5.6.2.20130114123552.0a8fb9e8@resistor.net> <F1DFC16DCAA7D3468651A5A776D5796E069A3D59@SN2PRD0510MB372.namprd05.prod.outlook.com> <6.2.5.6.2.20130114143302.0a375f30@resistor.net> <F1DFC16DCAA7D3468651A5A776D5796E069A3E7B@SN2PRD0510MB372.namprd05.prod.outlook.com> <50F49DAB.9080909@cs.tcd.ie> <F1DFC16DCAA7D3468651A5A776D5796E069A3F64@SN2PRD0510MB372.namprd05.prod.outlook.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <F1DFC16DCAA7D3468651A5A776D5796E069A3F64@SN2PRD0510MB372.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <EC17C004-675E-47DD-A8D0-129230C430FD@cs.tcd.ie>
X-Mailer: iPhone Mail (10A523)
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Tue, 15 Jan 2013 00:27:00 +0000
To: Stephen Hanna <shanna@juniper.net>
Cc: SM <sm@resistor.net>, "nea@ietf.org" <nea@ietf.org>
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
X-BeenThere: nea@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Endpoint Assessment discussion list <nea.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nea>
List-Post: <mailto:nea@ietf.org>
List-Help: <mailto:nea-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jan 2013 00:27:28 -0000
On 15 Jan 2013, at 00:21, Stephen Hanna <shanna@juniper.net> wrote: > 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. Grand. SM - I can put a note on the ballot so other ADs know about it. S > > Take care, > > Steve > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Monday, January 14, 2013 7:07 PM >> To: Stephen Hanna >> Cc: SM; nea@ietf.org >> 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:sm@resistor.net] >>>> Sent: Monday, January 14, 2013 5:47 PM >>>> To: Stephen Hanna >>>> Cc: nea@ietf.org; 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 >>> Nea@ietf.org >>> https://www.ietf.org/mailman/listinfo/nea > >
- [Nea] Last Call: <draft-ietf-nea-pt-eap-06.txt> (… The IESG
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… SM
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… Nancy Cam-Winget (ncamwing)
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… Stephen Hanna
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… Stephen Hanna
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… Stephen Farrell
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… Stephen Hanna
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… Stephen Farrell
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… SM
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… SM
- Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.tx… SM