Thanks I guess I’m overdue for new glasses. Or bigger fonts. > On Aug 31, 2022, at 2:36 PM, Alice Russo <[email protected]> wrote: > > Brian, Dean, > > FYI, the content of this errata report was actually about RFC 7636, not RFC > 7363. (The submitted report used the wrong RFC number.) > > And the content of this report already exists as > https://www.rfc-editor.org/errata/eid6471 (so EID 7088 has been deleted). > > Separately, I'll forward the notification re: RFC 7636 (EID 6471) in case > you'd like to pass along your recommendation to the relevant ADs that the > report be marked "Held for Document Update". > > Thank you. > RFC Editor/ar > >> On Aug 19, 2022, at 6:58 AM, Brian Rosen <[email protected]> wrote: >> >> Yeah but do we want to do anything with it? >> “Hold for revision?” >> >> Brian >> >>> On Aug 17, 2022, at 2:52 PM, Dean Willis <[email protected]> wrote: >>> >>> >>> Seems legit. >>> >>> On 8/15/22 02:44, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC7363, >>>> "Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And >>>> Discovery (RELOAD)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://www.rfc-editor.org/errata/eid7088 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Keepn <[email protected]> >>>> >>>> Section: 7.1 >>>> >>>> Original Text >>>> ------------- >>>> The client SHOULD create a "code_verifier" with a minimum of 256 bits >>>> of entropy. This can be done by having a suitable random number >>>> generator create a 32-octet sequence. The octet sequence can then be >>>> base64url-encoded to produce a 43-octet URL safe string to use as a >>>> "code_challenge" that has the required entropy. >>>> >>>> Corrected Text >>>> -------------- >>>> The client SHOULD create a "code_verifier" with a minimum of 256 bits >>>> of entropy. This can be done by having a suitable random number >>>> generator create a 32-octet sequence. The octet sequence can then be >>>> base64url-encoded to produce a 43-octet URL safe string to use as a >>>> "code_verifier" that has the required entropy. >>>> >>>> Notes >>>> ----- >>>> The "32-octet sequence" referenced in the original text seems to be >>>> inconsistent with Section 4.1, which states that the minimum length of the >>>> code_verifier is 43 characters. It would be consistent by changing >>>> "code_challenge" to "code_verifier". >>>> >>>> Instructions: >>>> ------------- >>>> This erratum 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 >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC7363 (draft-ietf-p2psip-self-tuning-15) >>>> -------------------------------------- >>>> Title : Self-Tuning Distributed Hash Table (DHT) for >>>> REsource LOcation And Discovery (RELOAD) >>>> Publication Date : September 2014 >>>> Author(s) : J. Maenpaa, G. Camarillo >>>> Category : PROPOSED STANDARD >>>> Source : Peer-to-Peer Session Initiation Protocol RAI >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
