On Monday, January 14, 2019 06:40:09 PM Alexey Melnikov wrote: > On Mon, Jan 14, 2019, at 6:32 PM, Scott Kitterman wrote: > > On Monday, January 14, 2019 10:06:02 AM Kurt Andersen wrote: > > > On Mon, Jan 14, 2019 at 9:39 AM Scott Kitterman <[email protected]> > > > > > > wrote: > > > > On January 14, 2019 3:02:01 PM UTC, "Kurt Andersen (b)" > > > > <[email protected]> > > > > > > > > wrote: > > > > >On Mon, Jan 14, 2019 at 6:16 AM Murray S. Kucherawy > > > > ><[email protected]> > > > > > > > > > >wrote: > > > > >> On Mon, Jan 14, 2019 at 5:03 AM Scott Kitterman > > > > > > > > > ><[email protected]> > > > > > > > > > >> wrote: > > > > >>> > I see sender-id still has full citizenship. Now I'm not clear > > > > > > > > > >which > > > > > > > > > >>> will be > > > > >>> > > > > >>> > first, but my feeling is that rfc7601bis and > > > > >>> > status-change-change-sender-id-to-historic are going to be > > > > > > > > > >published > > > > > > > > > >>> more or > > > > >>> > > > > >>> > less at the same time. > > > > >>> > > > > > >>> > When a method is moved to historic, are the corresponding > > > > > > > > > >parameters in > > > > > > > > > >>> the > > > > >>> > > > > >>> > IANA registry moved to deprecated? If yes, should the move be > > > > > > > > > >stated by > > > > > > > > > >>> > which document? > > > > >>> > > > > >>> A quick look at Domainkeys in the registry and RFC 7601 will > > > > >>> answer > > > > > > > > > >that > > > > > > > > > >>> question for you. Let's not hold this up. > > > > >> > > > > >> +1. This was not identified in IESG Review as something that needs > > > > > > > > > >fixing > > > > > > > > > >> so I'd just as soon not make more changes now. If we keep changing > > > > > > > > > >it, > > > > > > > > > >> it's going to need another cycle through the working group. > > > > > > > > > >I had flagged the lack of deprecating Sender ID in my notes to > > > > >Murray. > > > > >Since he did not comment back on that, I had assumed he was good with > > > > >ripping it all out (or marking it as obsolete). > > > > > > > > The registry update policy is expert review. We won't need another > > > > RFC to > > > > deprecate Sender ID when the time comes. > > > > > > Understood, but I was thinking that cutting Sender ID mostly out of > > > 7601bis > > > would be appropriate. > > I think removing them from 7601bis != removing them from the IANA registry. > > > So far we have not removed any registry entries, only marked them > > deprecated (domainkeys for example). I don't think there's any > > particular rush to start now. > > Entries should never be removed from an IANA registry, as this would defeat > one purpose of having a registry. They can only be marked > historic/deprecated/obsolete, as appropriate for the registry.
Right, but taking it out of 7601bis would leave the problem then of what's the appropriate reference in the registry, which, more generally, is how we got to the full text replacement of 7601. Leaving it out of 7601bis would just replicate the problem that the latest update was created to fix. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
