Subject: Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 1 Jun 2020 12:27:09 +0000

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: 31 May 2020 05:09
> To: Pete Resnick <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; RFC Errata System <rfc-
> [email-masked]>
> Subject: Re: [Errata Verified] RFC7800 (6187)
> 
> The new text is clearly the right thing, and there is no need
> to debate it if/when the document gets updated.  "Don't hold
> it; do it now", so to speak -- and noting that (my
> understanding/recollection of) the plan for
> https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
> verified errata, not those in other states, will be displayed.
[RW] 

If this ends up being the plan, then I think that we may wish to modify the RFC guidance, or possibly have two different verified states:
 (i) Verified, could impact implementations
 (ii) Verified, editorial only.

Certainly, it seems to be makes sense for these sorts of errata to be displayed.

Regards,
Rob

> 
> (Yes, that link 404s at the moment, I assume a caching issue.)
> 
> -Ben
> 
> On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:
> > "Verified", not "Hold For Document Update"?
> >
> > pr
> >
> > On 30 May 2020, at 20:34, RFC Errata System wrote:
> >
> > > The following errata report has been verified for RFC7800,
> > > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
> > >
> > > --------------------------------------
> > > You may review the report below and at:
> > > https://www.rfc-editor.org/errata/eid6187
> > >
> > > --------------------------------------
> > > Status: Verified
> > > Type: Editorial
> > >
> > > Reported by: Pete Resnick <[email-masked]>
> > > Date Reported: 2020-05-26
> > > Verified by: Benjamin Kaduk (IESG)
> > >
> > > Section: 7.1
> > >
> > > Original Text
> > > -------------
> > >    [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
> > >               DOI 10.17487/RFC7157, May 2015,
> > >               <http://www.rfc-editor.org/info/rfc7517>.
> > >
> > >
> > > Corrected Text
> > > --------------
> > >    [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
> > >               DOI 10.17487/RFC7517, May 2015,
> > >               <http://www.rfc-editor.org/info/rfc7517>.
> > >
> > >
> > > Notes
> > > -----
> > > DOI has a typo: 7157 instead of 7517.
> > >
> > > --------------------------------------
> > > RFC7800 (draft-ietf-oauth-proof-of-possession-11)
> > > --------------------------------------
> > > Title               : Proof-of-Possession Key Semantics for JSON Web
> > > Tokens (JWTs)
> > > Publication Date    : April 2016
> > > Author(s)           : M. Jones, J. Bradley, H. Tschofenig
> > > Category            : PROPOSED STANDARD
> > > Source              : Web Authorization Protocol
> > > Area                : Security
> > > Stream              : IETF
> > > Verifying Party     : IESG
> >
> >
> > --
> > Pete Resnick https://www.episteme.net/
> > All connections to the world are tenuous at best

---

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Jun 2020 09:16:14 -0400

That's what the "technical" vs "editorial" distinction is supposed to be for.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Jun 2020 09:23:35 -0400

Further on this:

In the "editorial" realm, there are two classes of "correct" errata reports:

1. Trivial and obvious typos, such as spelling "and" as "adn".

2. Others, such as a number with transposed digits, which could,
indeed, be confusing.

The guideline that we're discussing is meant to separate those out,
saying that class 1 should go to HFDU, while class 2 might qualify as
Verified.  Whether a particular report falls into class 1 or 2 is
usually clear, but sometimes a matter of judgment.  And then whether a
class 2 report rates Verified or HFDU is also sometimes a matter of
judgment.  I'm personally happy with leaving that to judgment, rather
than trying to be overly rigorous about making rules for it.  I'm also
happy with the idea of clarifying or altering the guidelines, if
someone wants to make a specific proposal.

One thing we have talked about is having the RPC handle editorial
class 1 reports, and we can discuss that again if we like.  Should we
do that, it might make sense to have a separate handling code for
those that the RPC resolves.

Barry

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 1 Jun 2020 13:23:58 +0000

Okay, so the distinction is already there.

As the errata rules are written then I would have done the same as Pete suggested and marked this as HFDU under point (2) of https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/.

However, I also take Ben's point that it would be useful if this errata showed up inline (as per https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html), which is why I think that we might want to change the guidance for point (2) so that they become verified (editorial) rather than HFDU.

Regards,
Rob

> From: Barry Leiba <[email-masked]>
> Sent: 01 June 2020 14:16
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: Benjamin Kaduk <[email-masked]>; Pete Resnick <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> > If this ends up being the plan, then I think that we may wish to modify
> the RFC guidance, or possibly have two different verified states:

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 1 Jun 2020 13:55:18 +0000

> From: iesg <[email-masked]> On Behalf Of Barry Leiba
> Sent: 01 June 2020 14:24
> To: Rob Wilton (rwilton) <rwilton=[email-masked]>
> Cc: RFC Errata System <[email-masked]>; [email-masked];
> Benjamin Kaduk <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; Pete Resnick
> <[email-masked]>; [email-masked]
[RW] 

This seems entirely reasonable.

[RW] 

Personally, at least for new ADs, I think that it would probably be useful to clarify the guidelines.

I could propose some text, but I think that the first question to answer really relates to the inline-errata output.  It would be nice if spelling and grammatical mistakes were included in the inline-errata, since there seems to be no good reason why they should not be and they may be helpful to a non-native speaker.  If only "verified" errata can be included inline then it might be an idea to classify these as something like "verified, inconsequential".

Thanks,
Rob

> > > If this ends up being the plan, then I think that we may wish to
> modify the RFC guidance, or possibly have two different verified states: