[DNSOP] Re: [dnsext] [Technical Errata Reported] RFC 4035 (8037)
"Eric Vyncke \(evyncke\)" <[email protected]> Fri, 2 Aug 2024 13:11:57 +0000
| Newsgroups | gmane.ietf.dnsop,gmane.ietf.dnsext |
|---|---|
| Message-ID | <PH0PR11MB49666DF5324D7BC7C13D9EE3A9B32@PH0PR11MB4966.namprd11.prod.outlook.com> |
--===============5107222351605557157== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_PH0PR11MB49666DF5324D7BC7C13D9EE3A9B32PH0PR11MB4966namp_" --_000_PH0PR11MB49666DF5324D7BC7C13D9EE3A9B32PH0PR11MB4966namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Paul, [adding dnsop] As you kindly added me in cc, Iet me chime in (after a couple of PTO days):= per the IESG statement on errata processing [1]: - as the errata clearly does not represent the DNSEXT WG intent at the publ= ication time, this erratum cannot be =93verified=94 - nevertheless, it can be =93held for document update=94 (and I will act ac= cordingly on Monday if I hear no strong objection) as the IESG statement in= cludes =93any future update of the document *might* consider it=94 Perhaps time to write an I-D updating RFC 4035 in DNSOP ? Regards -=E9ric [1] https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-= errata-for-the-ietf-stream-20210507/ From: Paul Hoffman <[email protected]> Date: Tuesday, 30 July 2024 at 20:49 To: Elias Heftrig <[email protected]> Cc: Rose, Scott W. (Fed) <[email protected]>, Rob Austein <[email protected]= >, RFC Errata System <[email protected]>, [email protected] <[email protected]>= , [email protected] <[email protected]>, [email protected] <ek.= [email protected]>, Eric Vyncke (evyncke) <[email protected]>, [email protected] <= [email protected]>, [email protected] <[email protected]> Subject: Re: [dnsext] [Technical Errata Reported] RFC4035 (8037) On 29 Jul 2024, at 13:48, Elias Heftrig wrote: > as I take it from the IETF120 hallway discussions on the errata an update= to the RFCs is a viable way to deal with these flaws as well. Since update= s seem to take quite a while until published, the errata, as reported, offe= r some benefit of warning new implementers about the flaws in the meantime = (albeit their visibility being somewhat limited). Serving that purpose, fro= m my own perspective, an errata status of "Held for Document Update" might = be the way to go, or else a "Rejected", but with a very clear comment that = the reported flaws (errata 8037 and 8038) are in fact an issue and need to = be dealt with by an update to the according RFCs. "Held for Document Update= " might be a bit clearer in that regard. > > If I missed out on any discussions behind the scenes and things have beco= me clearer in the meantime, please don't hesitate to send me an update. Errata are the wrong way to propose technical changes to a protocol, which = is what this errata report does. They cannot be marked as "Held for Documen= t Update" because that presumes that the WG will later fully agree with the= proposed changes to the protocol. The IETF update process is indeed somewhat heavyweight. The decision to mak= e it that way balances long-term protocol stability against flexibility. Re= gardless, using the errata process (which is poorly defined and not all tha= t well executed) as a way to propose protocol changes is not a good alterna= tive to doing the hard work of proposing updates. --Paul Hoffman --_000_PH0PR11MB49666DF5324D7BC7C13D9EE3A9B32PH0PR11MB4966namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Aptos; panose-1:2 11 0 4 2 2 2 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:#467886; text-decoration:underline;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style> </head> <body lang=3D"en-BE" link=3D"#467886" vlink=3D"#96607D" style=3D"word-wrap:= break-word"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Paul, [adding dnsop]<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">As you kindly added me in cc, Iet me chime in (after= a couple of PTO days): per the IESG statement on errata processing [1]:<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">- as the errata clearly does not represent the DNSEX= T WG intent at the publication time, this erratum cannot be =93verified=94<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">- nevertheless, it can be =93held for document updat= e=94 (and I will act accordingly on Monday if I hear no strong objection) a= s the IESG statement includes =93any future update of the document *<b>might</b>* consider it=94<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Perhaps time to write an I-D updating RFC 4035 in DN= SOP ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Regards<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">-=E9ric<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">[1] <a href=3D"https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-= of-rfc-errata-for-the-ietf-stream-20210507/"> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-erra= ta-for-the-ietf-stream-20210507/</a><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <div id=3D"mail-editor-reference-message-container"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar= gin-bottom:12.0pt;margin-left:36.0pt"> <b><span style=3D"color:black">From: </span></b><span style=3D"color:black"= >Paul Hoffman <[email protected]><br> <b>Date: </b>Tuesday, 30 July 2024 at 20:49<br> <b>To: </b>Elias Heftrig <[email protected]><br> <b>Cc: </b>Rose, Scott W. (Fed) <[email protected]>, Rob Austein &l= t;[email protected]>, RFC Errata System <[email protected]>, = [email protected] <[email protected]>, [email protected] <[email protected]= state.edu>, [email protected] <[email protected]>, Eric Vyncke (evyncke) <[email protected]>, [email protected] <[email protected]>, = [email protected] <[email protected]><br> <b>Subject: </b>Re: [dnsext] [Technical Errata Reported] RFC4035 (8037)<o:p= ></o:p></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"font-siz= e:11.0pt">On 29 Jul 2024, at 13:48, Elias Heftrig wrote:<br> <br> > as I take it from the IETF120 hallway discussions on the errata an upd= ate to the RFCs is a viable way to deal with these flaws as well. Since upd= ates seem to take quite a while until published, the errata, as reported, o= ffer some benefit of warning new implementers about the flaws in the meantime (albeit their visibility being somewhat li= mited). Serving that purpose, from my own perspective, an errata status of = "Held for Document Update" might be the way to go, or else a &quo= t;Rejected", but with a very clear comment that the reported flaws (errata 8037 and 8038) are in fact an issue and need to= be dealt with by an update to the according RFCs. "Held for Document = Update" might be a bit clearer in that regard.<br> ><br> > If I missed out on any discussions behind the scenes and things have b= ecome clearer in the meantime, please don't hesitate to send me an update.<= br> <br> Errata are the wrong way to propose technical changes to a protocol, which = is what this errata report does. They cannot be marked as "Held for Do= cument Update" because that presumes that the WG will later fully agre= e with the proposed changes to the protocol.<br> <br> The IETF update process is indeed somewhat heavyweight. The decision to mak= e it that way balances long-term protocol stability against flexibility. Re= gardless, using the errata process (which is poorly defined and not all tha= t well executed) as a way to propose protocol changes is not a good alternative to doing the hard work of propo= sing updates.<br> <br> --Paul Hoffman<o:p></o:p></span></p> </div> </div> </div> </div> </body> </html> --_000_PH0PR11MB49666DF5324D7BC7C13D9EE3A9B32PH0PR11MB4966namp_-- --===============5107222351605557157== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============5107222351605557157==--