Re: Last Call: <draft-resnick-retire-std1-00.txt> (Retirement of the "Internet Official Protocol Standards" Summary Document) to Best Current Practice

John C Klensin <john-ietf@jck.com> Fri, 06 September 2013 01:48 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F006621F85E8 for <ietf@ietfa.amsl.com>; Thu, 5 Sep 2013 18:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level:
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m-rhaI0gf3p for <ietf@ietfa.amsl.com>; Thu, 5 Sep 2013 18:48:35 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D4B1C21F9B8F for <ietf@ietf.org>; Thu, 5 Sep 2013 18:48:34 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VHl9s-000Chh-BF; Thu, 05 Sep 2013 21:48:24 -0400
Date: Thu, 05 Sep 2013 21:48:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: Pete Resnick <presnick@qti.qualcomm.com>, Scott O Bradner <sob@sobco.com>
Subject: Re: Last Call: <draft-resnick-retire-std1-00.txt> (Retirement of the "Internet Official Protocol Standards" Summary Document) to Best Current Practice
Message-ID: <F5687E757A27D1C116B972CB@JcK-HP8200.jck.com>
In-Reply-To: <522903A4.5040900@qti.qualcomm.com>
References: <20130903141655.29247.40354.idtracker@ietfa.amsl.com> <E74E1804-C61E-4CB2-A40A-CFFEF2714335@harvard.edu> <52260B63.6090504@qti.qualcomm.com> <522642FE.6060100@gmail.com> <52264A79.4020308@qti.qualcomm.com> <AC7694E1-C1A9-447C-B81C-34956C52CA0C@harvard.edu> <52264D5B.4060900@gmail.com> <52265FE1.5080500@gmail.com> <52266A80.707@qti.qualcomm.com> <6.2.5.6.2.20130903161345.0bb3bfc0@resistor.net> <522678D3.7000704@qti.qualcomm.com> <5228BB22.4030909@qti.qualcomm.com> <917325CE-1AC9-40CA-92F7-AD28B957DCC2@sobco.com> <522903A4.5040900@qti.qualcomm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 06 Sep 2013 01:48:41 -0000

--On Thursday, September 05, 2013 15:20 -0700 Pete Resnick
<presnick@qti.qualcomm.com> wrote:

>> IESG minutes as the publication of record
>>    
> 
> The only reason I went with the IESG minutes is because they
> do state the "pending" actions too, as well as the completed
> ones, which the IETF Announce list does not. For instance, the
> IESG minutes say things like:
>...
> The minutes also of course reflect all of the approvals. So
> they do seem to more completely replace what that paragraph as
> talking about. And we have archives of IESG minutes back to
> 1991; we've only got IETF Announce back to 2004.
> 
> I'm not personally committed to going one way or the other.
> The minutes just seemed to me the more complete record.

Pete, Scott,

The purpose of the "Official Protocol Status" list was, at least
IMO, much more to provide a status snapshot and index than to
announce what had been done.  I think the key question today is
not "where is it announced?" but "how do I find it?".  In that
regard, the minutes are a little worse than the announcement
list today, not because the announcement list contains as much
information, but because the S/N ratio is worse.

With the understanding that the Official Protocol Standards list
has not been issued/updated in _many_ years, wouldn't it make
sense to include a serious plan about information locations,
navigation, and access in this?  For example, if we are going to
rely on IETF minutes, shouldn't the Datatracker be able to
thread references to particular specifications through it?  The
tracker entries that it can access appear to be only a tiny
fraction of the information to which Pete's note refers.

   john