> there's a WG that is doing a standards track update This is hardly a new situation. Normal procedure would be for that WG to initiate relevant actions to obsolete the alternative. I may be missing something, but I fail to see why this needs an IESG statement. Regards Brian On 2012-04-20 17:24, John Levine wrote: >> So, the standard question: what's the problem that needs solving here? > > I presume that the issue motivating this is RFCs 4405 through 4408, > which define two experimental mail validation schemes Sender-ID and > SPF that, for reasons that sort of made sense at the time, interpret > the same DNS TXT record in slightly different ways. As it turned out, > SPF has gained wide acceptance, and Sender-ID has disappeared, so > there's a WG that is doing a standards track update of RFC 4408 which > defines SPF. Since aproximately nobody uses Sender-ID, everyone > interprets the DNS TXT record the SPF way, and in practice there's no > ambiguity. > > In this particular case, it would be a good idea to report what > happened, and deprecate Sender-ID, probably by making 4405 through > 4407 historic. We have a draft that does this, which I think is worth > publishing, but that's different from inventing an entire process to > deal with a one-off situation that may well never occur again. > > The SPF RFC also defined a new RR for SPF which was intended to > resolve the ambiguity by moving SPF queries from TXT to the new RR. > Not surprisingly, after six years the new RR remains almost entirely > unused. We're deprecating that, too, which I suppose might be noted > in the IANA registry. But again, this doesn't seem to be a frequent > enough situation to require a policy. > > R's, > John > . >