Re: Last Call: <draft-leiba-3967upd-downref-00.txt> (Updating when Standards Track Documents may Refer Normatively to Documents at a Lower Level) to Best Current Practice

Barry Leiba <> Tue, 18 October 2016 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84284124281; Tue, 18 Oct 2016 12:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bxjzlnQSnSVw; Tue, 18 Oct 2016 12:55:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C04812947D; Tue, 18 Oct 2016 12:55:15 -0700 (PDT)
Received: by with SMTP id o68so5942710qkf.3; Tue, 18 Oct 2016 12:55:15 -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=SuDaXaGCOhWKLLzTF53We2pKVzP0R7kO9omDLsS6KLk=; b=PYpwbusMg28SuuJa7NKB/Fnunv4oCtmtVF0o+HXs8gvfWaseaNPm/0jc3ffB/zbbi0 06/Ps4FNic6g/CGsUswyAGoTKf/0T0VjrfoRM4mT+gwN+M2HYbHT8vn6r61GCswPudTt giq0QYpA986qHwnN6K5rAK2nPGDTieh7b/wkb0LMlyqo5HYP4OZAcf9wwRmm08lYEutG Foz1Gm9PG9QhVekMHwLe2Ym8Qn3v07hzFp0MmbIcCGHa1T8klw05H554Cp7okQs4ROj7 SDtDlja8RAT1s0VE5BcJ6iC0/RLh4WDp9O8uw/FXsOhfTmkt/BRsSKyeWXr26arLuU32 lbGg==
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=SuDaXaGCOhWKLLzTF53We2pKVzP0R7kO9omDLsS6KLk=; b=mDhqfRGhwmirT1r9PweyFgv6BZ1TID/npoR8yUmWTz6uL0Vn8Y7k+4rHQIBrcj0Nw6 /5deG9y6Cb6kaBKwK9IHtX7zemGZmC94mrFoCGul3b45SLI1o8PZqJ1v6bWSWPOhLXWz TW1LE9qsszLE0cHx2DTnWpvTbC9bAh+3h5bL/8IJANi5wiScKxo9OX6cK0rdcQXv2xHC 0GLwqnWDRLHBczXDjTVOdcpjKJl1HtkMyPz4a0E7vA8/9OmUx5qi24pZagSxEhyK4mCo 03El1Ui+oeskom+g4s83phcrVrSQcHxEbLctHbumorudDln6vB2HzAMaRHn6DScTKJua TkPg==
X-Gm-Message-State: AA6/9RnffNBgSX0WL7Cln6KxrBMW7Gk5m/4cXlrja8oT7mJKytaRKgVPdVVOZ9SM+UntFz0xqmvP4ivJdxn7sQ==
X-Received: by with SMTP id x189mr2559895qkc.135.1476820514157; Tue, 18 Oct 2016 12:55:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 18 Oct 2016 12:55:13 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Barry Leiba <>
Date: Tue, 18 Oct 2016 15:55:13 -0400
X-Google-Sender-Auth: 0eGnShL2FPcRi7TZOxddFgOAAGA
Message-ID: <>
Subject: Re: Last Call: <draft-leiba-3967upd-downref-00.txt> (Updating when Standards Track Documents may Refer Normatively to Documents at a Lower Level) to Best Current Practice
To: Brian E Carpenter <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Ben Campbell <>,, 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: Tue, 18 Oct 2016 19:55:16 -0000

> I broadly in favour of this change, but I have a few comments.

Thanks, Brian.

> First, a minor suggestion on the text itself:
> OLD:
>    The responsible AD should
>    still check for downrefs before sending out the last call notice, but
>    any need to repeat a last call if this has not been done is at the
>    discretion of the IESG.
> NEW:
>    The responsible AD should
>    still check for downrefs before sending out the last call notice, but
>    if an undetected downref is noticed during last call or IESG review,
>    any need to repeat the last call is at the discretion of the IESG.

Yes, that reflects the intent and is more explicitly clear.  I like the change.

> Second,
>>    there are no related security
>>    considerations.
> That bothers me a tiny bit. A missed downref could have security implications.

I agree, but I contend that this doesn't make it any more likely that
we'll miss a downref.  In fact, this change is only operable when we
*don't* miss it -- it simply gives the IESG judgment on whether last
call needs to be repeated when we catch it.  And the Security ADs will
certainly have a say in that, if they think that broader review of the
downref is warranted for security checking.

> Third, I believe that in addition to this procedural change, there is a
> little work needed on the ecosystem:
> 1. Make the downref registry an intrinsic part of the data tracker. I mean that
> each document listed at
> would instead be tagged as 'downref allowed' in the tracker, with appropriate GUI
> support for the IESG to apply this tag.
> 2. Enhance idnits slightly to check this tag when it detects a downref.
> A downref to a 'downref allowed' document would be a warning, and a downref
> to a non-downref-allowed document would be an error.

I agree that those would be excellent changes, and I'll ask Ben, as
sponsoring AD, to send that request up to the tools team.  I don't
gather than you're asking that the document be held for that, correct?

The change you suggest above is in my working copy for the next draft revision.