Subject: [Nea] Declaring Consensus to Approve Errata 2848 Against RFC 5793

From: Stephen Hanna <[email-masked]>
Date: Thu, 21 Jul 2011 10:58:39 -0400

I saw three comments on the thread started below. All agreed with the
errata. Two favored Approving it. One was not sure.

Based on this feedback, I declare that there is NEA WG consensus to
Approve the errata. I will ask our AD to do so.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Hanna
> Sent: Thursday, June 30, 2011 10:49 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793
> 
> I talked with our ADs about how to handle the errata described
> below. We agree that the best thing is to have the NEA WG discuss
> it and come to a consensus recommendation on the proper resolution.
> If the ADs agree, they'll go ahead and implement our recommendation.
> 
> As one of the editors of RFC 5793, I'd say this errata is pretty
> obviously correct. The paragraph in question is talking about the
> Remediation String. The one occurrence of Reason String in the text
> must have been a copy-paste error in the development of the document.
> 
> The other thing to consider is whether the errata should be Approved
> (and therefore published in the RFC Editor's errata database) or
> marked Hold For Document Update (in which case it's simply set aside
> for a future revision of this RFC). The criterion to be used here is
> whether the issue "could cause implementation or deployment problems
> or significant confusion". This is a tougher call but I'd say that
> it could cause implementation or deployment problems. If an implementer
> reads the erroneous text at face value, he/she would skip the mandatory
> NUL terminator check for Remediation String. That could result in
> interoperability problems since a NEA Server that sends a NUL
> terminator on the Remediation String would work fine with one
> NEA Client but not with another. So I think the errata should be
> Approved.
> 
> Do you agree? Let's see some discussion or simply Agree/Disagree
> emails so that we can reach consensus. Susan and I plan to close this
> discussion in two weeks (end of July 14) so please respond by then.
> 
> BTW, kudos to Andreas for finding and reporting this problem!
> 
> Thanks,
> 
> Steve
> 
> > -----Original Message-----
> > From: RFC Errata System [mailto:[email-masked]]
> > Sent: Tuesday, June 28, 2011 2:43 PM
> > To: [email-masked]; Stephen Hanna; [email-masked];
> > [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; Stephen Hanna
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: [Technical Errata Reported] RFC5793 (2848)
> >
> >
> > The following errata report has been submitted for RFC5793,
> > "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted
> Network
> > Connect (TNC)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=5793&eid=2848
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Andreas Steffen <[email-masked]>
> >
> > Section: 4.8.1
> >
> > Original Text
> > -------------
> > Remediation String (variable length)
> >
> >
> >
> >       The Remediation String field MUST contain a UTF-8 [6] encoded
> >
> >       string.  This string contains human-readable instructions for
> >
> >       remediation that MAY be displayed to the user by the Posture
> >
> >       Broker Client.  NUL termination MUST NOT be included.  If a
> >
> >       Posture Broker Client receives a Reason String that does
> contain
> > a
> >
> >       NUL termination, it MUST respond with a fatal Invalid Parameter
> >
> >       error in a CLOSE batch.
> >
> >
> >
> > Corrected Text
> > --------------
> > Remediation String (variable length)
> >
> >
> >
> >       The Remediation String field MUST contain a UTF-8 [6] encoded
> >
> >       string.  This string contains human-readable instructions for
> >
> >       remediation that MAY be displayed to the user by the Posture
> >
> >       Broker Client.  NUL termination MUST NOT be included.  If a
> >
> >       Posture Broker Client receives a Remediation String that does
> > contain a
> >
> >       NUL termination, it MUST respond with a fatal Invalid Parameter
> >
> >       error in a CLOSE batch.
> >
> > Notes
> > -----
> > Copy-and-paste error: Reason String must be changed to Remediation
> > String.
> >
> > Instructions:
> > -------------
> > This errata is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party (IESG)
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC5793 (draft-ietf-nea-pb-tnc-06)
> > --------------------------------------
> > Title               : PB-TNC: A Posture Broker (PB) Protocol
> Compatible
> > with Trusted Network Connect (TNC)
> > Publication Date    : March 2010
> > Author(s)           : R. Sahita, S. Hanna, R. Hurst, K. Narayan
> > Category            : PROPOSED STANDARD
> > Source              : Network Endpoint Assessment
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Jul 2011 16:09:47 +0100

Done. You might want to check I did it right:-)
Cheers,
S.

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 21 Jul 2011 11:11:35 -0400

Everything looks good to me. Let's consider this done.

Thanks,

Steve

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, July 21, 2011 11:10 AM
> To: Stephen Hanna
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Nea] Declaring Consensus to Approve Errata 2848 Against
> RFC 5793
> 
>