On Sat, Jun 1, 2019 at 2:01 AM Alexey Melnikov <aamelni...@fastmail.fm> wrote:
> > On 1 Jun 2019, at 09:18, Dave Crocker <d...@dcrocker.net> wrote: > > > >> On 6/1/2019 10:13 AM, Murray S. Kucherawy wrote: > >> On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov < > dilyan.palau...@aegee.org <mailto:dilyan.palau...@aegee.org>> wrote: > >> Shall I submit an erratum to RFC7489? > >> I would, yes. And this should certainly be recorded as something we > need to fix for standards track DMARC, whether by chasing down RFC7489 > errata or via a dedicated issue in this WG's tracker. > > > > Hmmm... > > > > The formal rule for errata in the RFC system is rather constrained: Only > errors that mis-specify what was intended are permitted. > > > > So, errors in thinking or failures to provide for cases don't count as > errata. > > You are right, but I can always mark this issue as “hold for update”, so > that it can be tracked for the -bis document. > My understanding matched Dave's originally, but then I found this: https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ It's not surprising this sort of need to record a deficiency for later handling has come up before, and we've adapted a way to deal with it. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
