Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

Joe Touch <touch@isi.edu> Fri, 03 June 2016 20:51 UTC

Return-Path: <touch@isi.edu>
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 B51BE12D99B for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 13:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 jOsVoZCedbVr for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 13:51:15 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABC712D992 for <ietf@ietf.org>; Fri, 3 Jun 2016 13:51:15 -0700 (PDT)
Received: from [128.9.184.224] ([128.9.184.224]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u53KoLNG012066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Jun 2016 13:50:22 -0700 (PDT)
Subject: Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice
To: Barry Leiba <barryleiba@computer.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <20160419141640.31545.54742.idtracker@ietfa.amsl.com> <575185A2.70908@cs.tcd.ie> <EDA3CD0D-BDCA-4AC6-AA67-318670080338@sobco.com> <CAC4RtVBngkPc-yQ8P0qyvwsG9L4qjDMDPZ5xwa4gR84=ov4iUg@mail.gmail.com> <CAF4+nEHzvVOq_1L2ukX-OcPGkVFgR2OOD5puLMBJGif3a=Hzaw@mail.gmail.com> <CAC4RtVC6sKnYQS3mOay8-rSLQ0+U5mYGVhBbSSD=0xNX6dt2ng@mail.gmail.com> <5751D5E8.6030803@cs.tcd.ie> <CALaySJ+3jorRopPKNHjy19fo1v1=dZEHarMJ1-gB89vNbkFxaw@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <5751ED8B.4020508@isi.edu>
Date: Fri, 03 Jun 2016 13:50:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CALaySJ+3jorRopPKNHjy19fo1v1=dZEHarMJ1-gB89vNbkFxaw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/rY8f2FWH6CWnpqU66uvUEKXID_4>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 03 Jun 2016 20:51:17 -0000

FWIW, IMO this is all make-work.

IANA pointers to the old doc should turn up "obsoleted by" notices. That
ought to be enough to trigger the user to follow the right path.

Otherwise, IMO, this doc should basically say "IANA pointers should be
updated as deemed useful". In some cases, there's a benefit, but not in
all cases. E.g., we have docs that obsolete protocols but IANA still
keeps a pointer to the codepoint. I don't want the new pointer to be to
the doc that obsoletes them; I would want the pointer to be to the
original spec.

I.e., remember that "obsoleted by" can also effectively mean "moved to
Historic by". I.e., nobody looking at TCP-MD5 should necessarily get the
RFC to TCP-AO. And there's no way to know what's in active use *somewhere*.

I'd prefer to trust the author to do the right thing that to engineer
this document with an algorithm.

Joe

On 6/3/2016 12:47 PM, Barry Leiba wrote:
>>> Would anyone object, and would this address your concern, Stephen, if
>>> I should change the text like this:
>>>
>>> OLD
>>>    If information for registered items has been or is being moved to
>>>    other documents, then, of course, the registration information should
>>>    be changed to point to those other documents. In no case is it
>>>    reasonable to leave documentation pointers to the obsoleted document
>>>    for any registries or registered items that are still in current use.
>>> NEW
>>>    If information for registered items has been or is being moved to
>>>    other documents, then the registration information should be changed
>>>    to point to those other documents. In most cases, documentation
>>>    references should not be left pointing to the obsoleted document
>>>    for registries or registered items that are still in current use.
>>> END
>> That is better, but I'm still worried that it'd be used by well meaning
>> folk to force authors to do more work than is needed for no real gain.
>>
>> My preferred OLD/NEW would be:
>>
>> OLD
>>    If information for registered items has been or is being moved to
>>    other documents, then, of course, the registration information should
>>    be changed to point to those other documents. In no case is it
>>    reasonable to leave documentation pointers to the obsoleted document
>>    for any registries or registered items that are still in current use.
>> NEW
>>    If information for registered items has been or is being moved to
>>    other documents, then the registration information should be changed
>>    to point to those other documents. Ensuring that registry entries
>>    point to the most recent document as their definition is encouraged
>>    but not necessary as the RFC series meta-data documents the relevant
>>    relationships (OBSOLETED by etc) so readers will not be misled.
>> END
> Well, and *that* is so fluffy that I strongly object to it.  I think
> it's bizarre to directly say that it's unnecessary and you don't need
> to worry about it.  I can't think of any other place where we so
> casually accept stale references.  For example, we flag I-Ds that
> point to obsolete references and ask for justification to leave them
> in... otherwise, they're updated before or by the RFC Editor (usually
> before).
>
> I think the change I've already proposed is a reasonable compromise.
> "In most cases" isn't "in all cases".
>
> Barry