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 <> Fri, 03 June 2016 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D03AB12D1BB for <>; Fri, 3 Jun 2016 07:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Status: No, score=-1.701 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zrqXoCsXY8x1 for <>; Fri, 3 Jun 2016 07:31:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E50C12D1BF for <>; Fri, 3 Jun 2016 07:31:16 -0700 (PDT)
Received: by with SMTP id z123so81529099itg.0 for <>; Fri, 03 Jun 2016 07:31:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sTpVarvypOUn3e0pnqdEWR6UFz5FjH5pNIx2ZjwIafo=; b=N227gju7xGebWsJcBK4Bh4ygrLSf/4WOl0TCZcaEA9eVNzV3mk6dpkRPw0Ka1hetMw X6va9aYvU/Dfq5TVY/48xwVWKA+HuUXziXiXj8WmSSHWbR7wUg025iyxwa0l9Mlfct/H yMn+KUmpO6WLm6xMwTh7vQoQ34ZWhsp3R/JQhR0qJxC5kN6CPj81iWrpCK9AdYHdO/yk tdcABAf+5PIp7Q036sqxDkfVXK++BTMl17AXx7zwxneLCtuSpb+Xios3CvkmY7LsfS/h logEAq7dSJpygrfNEiKP4eIu/WoDxJVyYEYwb6UTWLTKvvlOCLKEux5VP8xgVBeE2ETy lg6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sTpVarvypOUn3e0pnqdEWR6UFz5FjH5pNIx2ZjwIafo=; b=FIWjMYLxR/YGkASMHswkfEI7KpKoDaEGLK91pXuCWRGgcYiLfd6atgYoZW7DWyrsQd JjMwPpWIHNunRBQWDu86JZ6kIlSeRUVPVu95HDWouBChnxAj4z8hyrXDHEInFaULqLQr agM38LdbHYlZq1ssnLPqh/lPc1Ea68EWqEKFaAI2TmTHJYOR5d2TP1c9tt7VVX7esgoA XqpgU48uTXehKtTwLMa6eTWTMFwaVWzuO7H684FvRqEzynBqZ99UasoP/yHKjWNU7HGN VTSUKbWJHSKYLDsBXYYbjC7j1xJ92I7P3NPdDhhzGszVuczfGlmot8GBNWLcBFDhLFSG 4bNg==
X-Gm-Message-State: ALyK8tLBIcG+Rbkx3djP4pwz/1Jm5tgkPCs7IPSHkZfm34l78slC2r7rQsmMyyD68UTMOGB10vSvmltCiBXrMg==
X-Received: by with SMTP id 81mr10836333itd.76.1464964275634; Fri, 03 Jun 2016 07:31:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Jun 2016 07:31:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Barry Leiba <>
Date: Fri, 3 Jun 2016 10:31:15 -0400
X-Google-Sender-Auth: 8XiN_gu5qaay4Q-38ikQO4mbv58
Message-ID: <>
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: Scott Bradner <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Jun 2016 14:31:18 -0000

>> The issue iirc is that if say RFCxxxx is obsoleting RFCyyyy
>> must the IANA considerations in RFCxxxx say that all the
>> registries that used point at RFCyyyy need to be updated to
>> point at RFCxxxx? I don't think that needs to be done (but
>> it can be done). I think Barry's position, and the text of
>> the 5226bis draft say that it has to be done.
> seems like a good make-work requirement with little actual benefit
> of course, if the details of the registry changed with the replacement
> RFC that is a different case

Well, the point is that RFCyyyy defined the BANANA option for protocol
LMNOP, so it registered the BANANA option in the "LMNOP Options"
registry, with a reference that points to RFCyyyy.

Now we have a "yyyy-bis" that becomes RFCxxxx, and that is now the
current definition of the BANANA option -- RFCyyyy is now obsolete.

What is the point of having the reference in the registry?  If it's
needed at all, it should be kept current.  Is it OK that it's left to
point to the obsolete definition of the BANANA option?  Is it better
to change it to point to the current definition in RFCxxxx?  Is it
important to do that?  Is it necessary to do that?  What should BCP 26
say about that?