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

Barry Leiba <barryleiba@computer.org> Fri, 03 June 2016 20:13 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 4D4D112D989 for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 13:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lbUHwdu39EFw for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 13:13:44 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 7D00012D988 for <ietf@ietf.org>; Fri, 3 Jun 2016 13:13:44 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id o189so76955159ioe.2 for <ietf@ietf.org>; Fri, 03 Jun 2016 13:13:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=FIelXM4aAzH2ScobejpRJjVBqymnDsitQ+bnk/GPzBo=; b=bFBNMzYRuSrgTPRae9bLhA1MhRMgqUQht/n4iS3id/INnsO7CXF50+JG4jrl4ni4lo 3JB1EQUovwPXn6sJNqurlszPWEyqexhvkpa1UFdYA2YBxEFmZGTZIWRYu2NQ635kOBuC YzHdo+dIQVpT/e5DXktZ41EEOj6S/NuoJpUT2dwURyXvcqj068lpqATVuP1dX6OC/t9x fQk34WAfhrIr0tJB+3iLmmbsuPK8f1/LLhSVDRBSr3sWMsITDJJ4+6lFtC4TPm2Q8tYI +x0Nifm2kibgrJkIKmM6caGaaq2YZDjo8fWatJ1BRRqwLm0AdOrte6PF1a/jVJ9NxCCn vk5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=FIelXM4aAzH2ScobejpRJjVBqymnDsitQ+bnk/GPzBo=; b=ZhxbtUH3zlAxUyjxJ8Z0+M3XIlSJaqGYOL4WhFvQBS68yhux+Tcuhjfbi1CzhMyUso C8KfJuaNh0wmOwgU/63m7S7HUC/5FydT2vcWDd0P7dFuuMNcIh7iTwAfexCssJ7fBdpl /JmfBBGbCoPQU8mQ+EreHlwVfPuGmreCOZPkxccNT6yJrNxUkxH7bJu+YGw5bs73ZMbr eLCjva6KBvJ+g1Hc1gcwct1ah0D5A8qRTTDCTAoR2qcgPAYwnec2I1rCbJVEIalxx+Ga LsfG63oCQ05FW0N+gaVeGZ4EghGopf+mKs2RZPkzrw9VEQCZB03XZ4mHnCpnyY0EYfvZ WN+A==
X-Gm-Message-State: ALyK8tLfrixsspaShz6GNErtc3BsKx/cFWw44u/3e5FGInnCW4N8c4Q9ss47xPGFzS4YGn8zYIwxOXzFfn+UCw==
X-Received: by 10.36.58.75 with SMTP id m72mr2059304itm.96.1464984823781; Fri, 03 Jun 2016 13:13:43 -0700 (PDT)
MIME-Version: 1.0
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.107.140.78 with HTTP; Fri, 3 Jun 2016 13:13:42 -0700 (PDT)
In-Reply-To: <5751E066.8030802@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> <5751E066.8030802@cs.tcd.ie>
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 03 Jun 2016 16:13:42 -0400
X-Google-Sender-Auth: gCvI9NiklNEzgD65b5LFwQLvb8Y
Message-ID: <CAC4RtVCKHS74Aess6ANgm4eX8ymDzRqqg-=bvR-BP4kR+gi9jg@mail.gmail.com>
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: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/iCcdqPW5CCp_8dUxNRugHEQLpC4>
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:13:46 -0000

>> I think the change I've already proposed is a reasonable compromise.
>> "In most cases" isn't "in all cases".
>
> I accept that you think that:-)
>
> Do you think "in most cases" would have meant you and the author
> concerned would/would-not have had that discussion a couple of years
> ago? If you would have had it anyway, then I don't think "in most
> cases" is usefully different from the OLD text.

I think I'd have had it even with your text, because I simply think
it's monstrously stupid to intentionally retain obsolete references
when we have a newer reference available and it's easy to correct (I
had even provided text).

> And to go back to the nub or the argument, I don't think we have IETF
> consensus for that (but you do). I note that so far we only have people
> disagreeing with the current draft text.

I don't agree with that: Donald said this:
"The only constant
principle, I think, is that the reference(s) for the registry and for
the code points in that registry should be the best references
reasonably available..."

SM said this:
"Is it useful to point to RFCyyyy when the information about the code
point in RFCxxxx?  I don't think so."

Both of those seem to be arguing for updating the references to be current.

But let's put the specific options there and ask:

Community... which of these (or none) do you think reflects the best
practice that should be in BCP 26?:

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-1
   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.

NEW-2
   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.

(And, Stephen, for what it's worth I'd be OK with a variant of your
version if the last sentence said, simply, "Ensuring that registry
entries point to the most recent document as their definition is
encouraged but not required.")

-- 
Barry