Re: [rfc-i] draft-kuehlewind-update-tag/

Brian E Carpenter <> Fri, 27 March 2020 03:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF6773A02BC for <>; Thu, 26 Mar 2020 20:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hu4IxHdu4Bm8 for <>; Thu, 26 Mar 2020 20:34:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E30C93A08C8 for <>; Thu, 26 Mar 2020 20:34:34 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 043FDF4071F; Thu, 26 Mar 2020 20:34:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D60D8F4071F for <>; Thu, 26 Mar 2020 20:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SNn1lEyfm4iy for <>; Thu, 26 Mar 2020 20:34:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) by (Postfix) with ESMTPS id 93C37F4071E for <>; Thu, 26 Mar 2020 20:34:19 -0700 (PDT)
Received: by with SMTP id h72so3850825pfe.4 for <>; Thu, 26 Mar 2020 20:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7ZarYymKWkamM8dKJxK0TVQDQSwKQ4JQYdLtT8ppjPg=; b=n0XJ1CihZ7y0s3ASaPHVlXdD/0dRegez/uFRtJtVfX9/WZjg1gv6fWLLQ72nvsoYAP PCDQPwyL2nRtUqyGQng1b/0x/sVO9LkabIqkkThPm8K2YT1zHCROr+yzgwfGlr1X/f29 LFicoM5aPC9TkRLs2nV93uP+FOGpVrDPCk7RLzCN3XC210ypmUeuY8+xoC+K19NDv2GH GjZt3Un6D/mQvaOv+4YNxcs5pPhnmSIsBVQZWyakW3XzrSxhBEL9LE1oThm/+zNPlnjw Y5NYfgyDkiIU8IFotMussnnrHiIQ5TlVWFp91pCLQ1KC6ZRoa+0KK50FqSiDWJbQzN9u sRzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7ZarYymKWkamM8dKJxK0TVQDQSwKQ4JQYdLtT8ppjPg=; b=kDHXl3H7u/hJ94iaqopbPSNIlOHkTLLRG0Tr8mWG8jJuvFrN0JmsBQdq3JgoSl3IKB VDC8YRKbbWWSoyG2ix92Ykdffit4gYZUvQhfkvxRRkvh3g+Fc6wF8SVyiSlyrTIEd3+R mWuCVtAqd0JcSWHhiOvYfh3Lsh5X0+0W5lWdzYAz8/dCd5898Seo2jI1EEeuh5vdz5FJ fGHMhV8e9jHfWzxpTsYBrt6cf0TLgpabQAwIcWxdlFCfW9i+gYsKp80qvlfygBw/rHR3 jDHoaKjmkj+gbF3hGp//KpUcWXx5BUwkih+8w0Y7fxi+WbiTuD1ynjxnx+N8Beta6S+l i70g==
X-Gm-Message-State: ANhLgQ37wHrBQmP2a+1p0WnfF2mYQx6aXbfRd7fzH6YqKxZVanmCAH8R an7xTgKHeCTZsmMmYvh/wmo=
X-Google-Smtp-Source: ADFU+vt5dW87RRc51UHOJFVgmH8KCki+AjHPwdyVymgGjQx4P0wXueDmApp66wtF4EWhN4p11rw6Hg==
X-Received: by 2002:aa7:9dc1:: with SMTP id g1mr12686122pfq.308.1585280069818; Thu, 26 Mar 2020 20:34:29 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id ev21sm2698723pjb.24.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2020 20:34:28 -0700 (PDT)
To: Joseph Touch <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Fri, 27 Mar 2020 16:34:23 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Language: en-US
Subject: Re: [rfc-i] draft-kuehlewind-update-tag/
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Cc: Toerless Eckert <>, "" <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: "rfc-interest" <>


On 27-Mar-20 16:01, Joseph Touch wrote:
>> On Mar 26, 2020, at 6:43 PM, Brian E Carpenter <> wrote:
>> ekr,
>> On 27-Mar-20 06:44, Eric Rescorla wrote:
>> ...
>>> You and the proponents should feel free to do so. However, at present, the situation is that this proposal doesn't have anything like consensus (and yes, that's because a number of us are of the opinion that no action is needed) and so the burden on the proponents is to try to build that.
>> It doesn't have consensus, but the question (when it gets to Last Call) is whether it has rough consensus.
>> fwiw I agree that there is a manifest problem with ambiguous use of Updates and I think that the proposed solution is good.
> How about giving us some concrete examples? Or perhaps the authors could (should)?

Yes, I would prefer to leave that to recent IESG members. Any examples in my
mail archive would be quite old.

However, I will quote what the IAB opined in RFC6709:

>    1.  Modifications or extensions to the underlying protocol.  An
>        extension document should be considered to update the underlying
>        protocol specification if an implementation of the underlying
>        protocol would need to be updated to accommodate the extension.

The problem, I think, is uses of "Updates" in extension documents that
do not match that definition.

>> On 26-Mar-20 11:41, Martin Duke wrote:
>>> But I dislike the idea of having "Extends" and "See Also". I foresee foundational documents (like RFC 793) with a few pages of RFC references before the text starts.
>> I very much doubt it. At the moment RFC793 shows:
>> "Updated by: 1122, 3168, 6093, 6528"
>> Whether those are amendments or extensions I don't know.
> And that’s part of the point. It isn’t clear. It never will be.
> What does 
>> Certainly it's incomplete; for example RFC7474 amends RFC793.
> How so? It doesn’t even cite it or use the term “TCP”. You meant RFC7414 maybe?

Yeah, brain meltdown possibly brought on by mandatory self-isolation.
I meant 791, which is updated (amended) by 7474, so a completely
bogus example. Sorry.

>> And so what anyway? If an important RFC like 793 is amended or extended by 50 RFCs, that should definitely be in the metadata.
> 7414 doesn’t itself update or emend anything.  It lists things that update, emend, or do both to 793.
> Draft-tsvwg-udp-options - does what?
> 	- it extends UDP with options
> 	- but it also alters UDP to prohibit UDP length values that 786 allows
> Is that extends or emends?

Both. Why would it be a problem to use both tags if they both apply?

> I’d really llke to see a list of *ALL* current “updates” and a proposed disposition to each as whether it uniquely and unambiguously extends or emends (or see also).

That's a ridiculous amount of work to suggest. There 1017 RFCs that carry the "Updates" tag, and 861 occurrences of "Updated by", according to the RFC index of yesterday.

Stay well,

> If the authors can’t present that, then they have failed to demonstrate that their “solution” is a step in the right direct.
> We’ll wait.
> Joe

rfc-interest mailing list