Re: I-D Action: draft-wilde-updating-rfcs-00.txt

Brian E Carpenter <> Thu, 22 December 2016 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E144129498 for <>; Wed, 21 Dec 2016 16:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 82QS-Sk9icJd for <>; Wed, 21 Dec 2016 16:38:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E45961293F5 for <>; Wed, 21 Dec 2016 16:38:42 -0800 (PST)
Received: by with SMTP id y62so38722965pgy.1 for <>; Wed, 21 Dec 2016 16:38:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8itFFea/gB3MXigfuT/OSZ5B59lfR/TD5PaFYULt3Oo=; b=tb53gwuoFGUlsy9LA73kzxFRjABwqCDR4crWJS1z1E+kQWQ5lPibcLW18EejHqWhTK cxZl1NS3mJxsP7XObtWOps5C5xAU81krSIg8LO5GsyRqUyuXl/YhiLZfeP2jvi5cxfuZ 1jQwx/HzXLiZUOhUSy3XIyptKOa9n/YSHgH1N+c4uuC+7NxQxtb0J66QD9gWrCgZFIZH iEiVhCRcCHUz9P91jNouT69cm1W8YGKWenvHMVWNa2vlKIZtrmKvvyjylKfCcusNjMKR 0yMHZ9Ap1a9iNhiutWlWLtV6yYUn9t6lcwcEqrjqkmUgmSbgk0rTHWjhI0xMffPJBouF WtkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=8itFFea/gB3MXigfuT/OSZ5B59lfR/TD5PaFYULt3Oo=; b=Q5/8KHELPRohjRXYLu+JWnTuFB1sdk9kR+MjamzZAPvBsHkasWWv6Pp0YyAGqbHQoU 5xNwo0UVK1yM6ndEcGTsjvDggofyFWGm5ABtwcaabzm5kiLMmmsDGyTrBRyvkZtREddL 2VeXisgCpq3baOVWLN9nePf7knNp+VZYiaAjbmlAGsNA6e8AQvd8eo4oR+s1tgTENWK2 fkObGCQN24mzqiq39Jg62w0Ty/mzujqq8l8lVbwyoJ8X8m6xoWb+qWdytdhZIlyOwXOo HyG+Z9yCaoPXy5SxJzCZ8cuZpGBfSXi9b1jMi+AOIEuqjIbfJGwZMR/XxbBJDDTWZ6bw 3ufw==
X-Gm-Message-State: AIkVDXJlleksQN+qTL+lrnRjeu2OXmwNlFCWkvkhhaM/K4YkMA4fnfFGyJLRVQb0uTxixg==
X-Received: by with SMTP id o18mr14014947pli.45.1482367122426; Wed, 21 Dec 2016 16:38:42 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id e1sm34137364pga.37.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 16:38:41 -0800 (PST)
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
To: Spencer Dawkins at IETF <>
References: <> <> <> <> <66D4FC4D5384B187F1571399@JcK-HP8200> <> <378400590145685410530968@JcK-HP8200> <> <> <> <E186A6708FBC8836D0DC4655@JcK-HP8200> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Thu, 22 Dec 2016 13:38:46 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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: Thu, 22 Dec 2016 00:38:44 -0000

Hi Spencer,

On 22/12/2016 07:03, Spencer Dawkins at IETF wrote:
> So, backing up a tiny bit ...
> What follows is me, speaking as a currently serving AD, and as a survivor
> of NEWTRK (so, an inmate who is now helping to steer the asylum, although I
> didn't take it over).
> I have had the pleasure of talking with the most recent three IESGs about
> what UPDATES actually means in relationship to a specific document on a
> current telechat agenda. Those have not been easy discussions.

Which, I think, explains why tying this down to formal requirements
around the use of <rfc updates="xxxx"> is not easy either.

> I have been talking to Rick about AD sponsoring some version of his draft,
> and he's not quite sure what to do next, because any discussion of his
> draft opens a Pandora's Box of stuff that's broken about the way we have
> tried to document protocols over a very long period of time. I was hoping
> that it would be possible to do something useful with a narrow scope, that
> doesn't involve fixing everything, but might fix a few things.
> I'd like to hear opinions about that.

I think that it's pretty much impossible to make firm rules about this. I do
think that those writing, reviewing and approving documents SHOULD spend time
on ensuring that an implementer of the updating and updated RFCs is in no
doubt about what to write in her code. But I just don't see how to reduce
that to a formula. The discussions you mention haven't been easy because
the topic isn't easy.

> More broadly,
> is a perfectly serviceable list of stuff that was broken in 2006, and since
> we haven't changed much since 2006, still seems to be broken today.

2004 actually:

> What I'm remembering about NEWTRK, and other folks may remember it
> differently, was that we had pretty ambitious goals, and proposals like
> reflected
> those goals.
> For instance, I'm re-reading
> (one of
> the few NEWTRK documents I'm not even acknowledged in - but I liked it a
> lot at the time), and remembering that we assumed that all STDs would have
> ISDs (even if they were basically formulaic, with little or no explanation
> initially).
> NEWTRK petered out almost simultaneously with the beginning of narrative
> minutes for IESG telechats, so it's hard for non-IESG members to
> reconstruct all the concerns expressed at the time, but I'm remembering
> discussions about who would write this descriptive text, and who would
> approve it - and talking to at least a couple of IESG members after the
> fact, who'd told me they'd assumed the IESG would have to provide those
> descriptions, or at least approve them.

You can also look at the minutes of the 2005 IESG retreat:
and the resulting IESG message:

Clearly there were individuals in the IESG with divergent opinions,
so that message was a compromise.

> What I'm wondering now, is how un-ambitious we could be, and still do
> something useful to get started.
> John did a couple of examples of ISDs, in
> (John,
> is that the best pointer for this?) on SMTP (complicated) and on POP/IMAP
> Authentication with CRAM-MD5 (much simpler), circa 2004 or so.
> Is it worth taking a look at that, and producing samples for a couple of
> protocols that are more complicated than a single RFC, and less complicated
> than (for SIP) or
> (for TCP), and seeing what we end
> up with?

First, an observation: nothing in the last ten years has actually prevented
someone proposing an ISD to the relevant AD as a Proposed Standard under
the "applicability statement" category defined by RFC2026. Agreed, there would
be some compromises compared to the actual ISD proposal, but IMHO nothing in our
rules would prevent such a publication. For example, we could suggest that
the authors of
format that document as an ISD.

I had ISDs in mind when I originally drafted

So yes, a nearly-ISD experiment could start today, IMHO.

> Administrivia: both Jari's position on the IESG and mine are under review
> by the current Nomcom, and I'm loath to get very far down the road without
> talking to Jari's replacement, and without knowing whether I will be able
> to AD sponsor drafts after IETF 98, so I'd like to do some homework now,
> but not go crazy yet.

Fair enough, but if the community wants to do this, that's a community choice.