Re: Last Call: Change the status of ADSP (RFC 5617) to Historic
Barry Leiba <barryleiba@computer.org> Wed, 20 November 2013 23:10 UTC
Return-Path: <barryleiba@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615F61AE180 for <ietf@ietfa.amsl.com>; Wed, 20 Nov 2013 15:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9Y3cm4aXWBq for <ietf@ietfa.amsl.com>; Wed, 20 Nov 2013 15:10:25 -0800 (PST)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A9B871AE16D for <ietf@ietf.org>; Wed, 20 Nov 2013 15:10:25 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id l13so3136414qcy.3 for <ietf@ietf.org>; Wed, 20 Nov 2013 15:10:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=buuzs4hoHxLFjzh4Ub+g9mbZInZfQ0ys1Ajuy7M3q88=; b=vtt9yAKSlCPcF6vQoucm6yxv3GwcJcvQ6jo6bv/iUNy7PJR7hJp0yiPIjYfSoLp01E JNFq7rVsoAQQj4yubWJnS3PX30c8IO+IHYkSRyO7nPg5eV9xIJkEAQOtgjLptZQqqI29 +eKFfLMVufZYW4bXTu1CrYQjKp1Q0gaSy11fNj+aP1UZGtZhmVRz6horSgVo7wihjZK5 iEfMkcjzZZlottF6JHXJplUb3+y5R1tnH9UAb5bznDZ/8fSDIGt6OxzkNHzZxy0BEvnE L03z1MLuONYbZKJkuEVO3iCr0dI24+3pIV+q+aNQB0aeGe+MsEtLg3znHtZalNcIxr4M EMlw==
MIME-Version: 1.0
X-Received: by 10.224.47.3 with SMTP id l3mr6068739qaf.25.1384989018715; Wed, 20 Nov 2013 15:10:18 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.224.66.194 with HTTP; Wed, 20 Nov 2013 15:10:18 -0800 (PST)
In-Reply-To: <528D3DB9.1090301@dcrocker.net>
References: <20131002145238.78084.qmail@joyce.lan> <524D846A.6030905@tana.it> <CAC4RtVBb9FVtmjK4X5hCQpMorHnjmyJLU1sYbNh==iBh8SqztQ@mail.gmail.com> <528CF075.9000204@dcrocker.net> <528CFCBC.30200@cisco.com> <CALaySJ+E=84jTJxfP7dGx=kVHN1DE1b3TyYhRA3454Z0oK+J-w@mail.gmail.com> <528D0CD9.5010300@cisco.com> <9FC35D4E-4A7D-4682-8C94-9FBC31E09A96@harvard.edu> <528D3DB9.1090301@dcrocker.net>
Date: Wed, 20 Nov 2013 18:10:18 -0500
X-Google-Sender-Auth: UO4-XbRAy-en67YXjMlBJcFB0No
Message-ID: <CALaySJJhETrpdgO1mt-9YHY1NJ=Ykg++9V-03GwggtdQUN4PXA@mail.gmail.com>
Subject: Re: Last Call: Change the status of ADSP (RFC 5617) to Historic
From: Barry Leiba <barryleiba@computer.org>
To: IETF discussion list <ietf@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2013 23:10:27 -0000
>> it would seem to me to be a dereliction of duty to not publish a document >> that says why such a change >> is made - ... > https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ Just to make this all very clear: When we had no obvious "metadata", we would publish an RFC that said that a previous RFC is now Historic, and we hoped that people would see both and know what the situation was. Then we established metadata that goes with an RFC, and the RFC's status and the "obsoletes" and "updates" chains are part of the metadata. No need to hope any more: Anyone who looks at the datatracker or tools versions of the RFCs will see that metadata, so (1) we can now rely on having the "Historic" status be clear, and (2) the RFC that updates or obsoletes the old one is now called out clearly. Then we set up special documents by which we process status changes. The cited one above is one of them. Those special documents are also tied to the original document's metadata. So here's the thing: 1. If RFC 9999 were to "obsolete" RFC 5617 and declare it Historic, someone looking at the datatracker page for RFC 5617 would see (1) that it's Historic and (2) that RFC 9999 obsoletes it. They would, therefore, know to look at RFC 9999 to understand what happened. 2. But if we just process this status change as currently proposed, someone looking at the datatracker page for RFC 5617 would see (1) that it's Historic and (2) that status-change-adsp-rfc5617-to-historic made that status change. They would, therefore, know to look at status-change-adsp-rfc5617-to-historic to understand what happened (and there's a convenient, clickable link). If you want another example, look at RFC 6376: https://datatracker.ietf.org/doc/rfc6376/ ...and see how the status change document that made it Internet Standard is clearly linked at the top of the page. See how that document contains the explanation for the action. As we change our tools, we need to understand that the ways we used to handle certain things are no longer necessary, because the improved tools have made things better. This is one of those situations. So: Yes, we could publish an RFC that basically has the content that status-change-adsp-rfc5617-to-historic now has, and that new RFC could obsolete RFC 5617. Personally, I don't see why that's necessary or even useful. We have a *new* tool for this, and we should use it. That said, the IESG, not I alone, will decide, and will take all the input y'all have given -- thanks for that input. Barry
- Re: Last Call: Change the status of ADSP (RFC 561… John Levine
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- RE: Last Call: Change the status of ADSP (RFC 561… ietfdbh
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Alessandro Vesely
- Re: Last Call: Change the status of ADSP (RFC 561… Scott Kitterman
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Douglas Otis
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- How to protect DKIM signatures: Moving ADSP to Hi… Hector Santos
- Re: How to protect DKIM signatures: Moving ADSP t… Barry Leiba
- Re: How to protect DKIM signatures: Moving ADSP t… Hector Santos
- Re: How to protect DKIM signatures: Moving ADSP t… Douglas Otis
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Re: How to protect DKIM signatures: Moving ADSP t… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Alexey Melnikov
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Bob Braden
- Re: Last Call: Change the status of ADSP (RFC 561… Eliot Lear
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Eliot Lear
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Bradner, Scott
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Bradner, Scott
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Procedural Changes through side-effect (was: Re: … John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Procedural Changes through side-effect (was: … S Moonesamy
- Spontaneous Procedure Invention ( was Re: Procedu… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… S Moonesamy
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… S Moonesamy