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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 22 December 2016 08:06 UTC

Return-Path: <spencerdawkins.ietf@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 B84F412947E for <ietf@ietfa.amsl.com>; Thu, 22 Dec 2016 00:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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 75HYrm5NfjJD for <ietf@ietfa.amsl.com>; Thu, 22 Dec 2016 00:05:58 -0800 (PST)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 8D0991293D8 for <ietf@ietf.org>; Thu, 22 Dec 2016 00:05:58 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id a10so111543574ywa.3 for <ietf@ietf.org>; Thu, 22 Dec 2016 00:05:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=utbRAG2YGeXGnyENFZR1rX5SXIxTRhDPYEUiClmmrOE=; b=lltxKXBSX+anpfNDOeDfwY0kgQw4SuXoo0WmPkh1p9pFZRR8x/mj8P8vnJqcObOvCC 7EOVP7UkRSH0JGKNTrUZUPx7lwvXTu3kEMK1/dngMN/iq44I7ulwsZhxTOYNkGpQGZvd v8Aw8WNGyjefbuum4ktbl7dwMZOUyjvT03y11Ao4OlNAjDGd12dS5lfm+/Bb4agPLCUG wcklKew26bXL67CTY8LDZWYXTt/QS+DFb5evJ+1/KJqVhfCJHSAJnwZZilsoO4l5IOeH W9FTuyAmt09dUQ+c3c+qFTVPWqHRQSvbUL2ivez41no6OeLXQWF5MWw04YgWkqdPDzpC pDNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=utbRAG2YGeXGnyENFZR1rX5SXIxTRhDPYEUiClmmrOE=; b=d+pS/p+ab41azKVYCKNHxQiDRWX6MiShhloZFQ+z3qtSZlNSnWi8WaB4FzU8/3+Adh 4XVsbN64Ez7/70hsY9pCBt7mL7rD6UrZI37dYzYdkA6iqZGCzUSrQT3H6P9xMpmcfDRJ M1v+W0zM1rJxNmnmeLxhr2oeoa6cOyxxLv4R7h0+NIYjHZO87fxkEL5tzWtbKPXF0I5u dclgDZidnkcSwBtR1HdS4FUtFyeRYeu8l/uYlygflPc5n00kvsQ44MSmH3ioZLFdYVVy WD8HpoS3wlXTRtw2EES/IXuv+scJLQ4516WZvycE3ONEnTGAj8GZbLne2jbbK7fqsRre 2bbA==
X-Gm-Message-State: AIkVDXJA1b7pm+v79RdmTRbHvhU5jww/UffmUYyVvYU21qob/TAd4CiD/NhNFon3tMpWDGPxN2CB6qt+bo943w==
X-Received: by 10.13.253.6 with SMTP id n6mr7110141ywf.26.1482393957670; Thu, 22 Dec 2016 00:05:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.176.5 with HTTP; Thu, 22 Dec 2016 00:05:57 -0800 (PST)
In-Reply-To: <c6fae9d5-0eb4-e886-b143-196a83db968f@gmail.com>
References: <147389550726.29872.13885747896056913688.idtracker@ietfa.amsl.com> <0f129603-20c0-921f-6a67-e5a4c74b3c41@gmail.com> <CAA=duU0NNCeL1EP5iJo9YxDmgdtgXSpa+GO1Xs_i38HMrFxSKQ@mail.gmail.com> <b4ab1536-0eb4-0bb4-d441-79cfd74cfd9c@joelhalpern.com> <66D4FC4D5384B187F1571399@JcK-HP8200> <9a3ff314-e778-b416-182f-0dd687f434ce@dret.net> <378400590145685410530968@JcK-HP8200> <25066.1481576196@obiwan.sandelman.ca> <896.1481578272@obiwan.sandelman.ca> <d527c6cd-bc0c-66b6-e481-2510f747879e@gmail.com> <E186A6708FBC8836D0DC4655@JcK-HP8200> <49012BDE-738C-4755-B5B3-A95A2ED64BE7@sobco.com> <CAKKJt-cWJhLnqXdM80vxBwddJzxKTvrENy=0BXTVMLX_5a1Nvw@mail.gmail.com> <c6fae9d5-0eb4-e886-b143-196a83db968f@gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 22 Dec 2016 02:05:57 -0600
Message-ID: <CAKKJt-dz7KsAB5ZJk-_+BQj6qRsHe-Djx7nJOtOa2BTvyAag4Q@mail.gmail.com>
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c06b16443a62605443abd40
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/IulCO1_7cnW4OU3YGwSdhYT9aTI>
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: Thu, 22 Dec 2016 08:06:01 -0000

Hi, Brian,

On Wed, Dec 21, 2016 at 6:38 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

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


Right. We can make it harder than it needs to be by trying to do too much,
but it isn't easy, in any case.


> > More broadly,
> > https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-
> isd-04#appendix-A
> > 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:
> https://tools.ietf.org/html/rfc3774#section-2.4
>
> >
> > What I'm remembering about NEWTRK, and other folks may remember it
> > differently, was that we had pretty ambitious goals, and proposals like
> > https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04
> reflected
> > those goals.
> >
> > For instance, I'm re-reading
> > https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04 (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:
> https://www.ietf.org/iesg/archive/iesg-retreat-2005-04.txt
> and the resulting IESG message:
> https://www.ietf.org/mail-archive/web/newtrk/current/msg00991.html


Thanks for the pointers.


> 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
> > https://www.ietf.org/archive/id/draft-ietf-newtrk-sample-isd-00.txt
> (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 https://datatracker.ietf.org/doc/rfc5411/ (for SIP) or
> > https://datatracker.ietf.org/doc/rfc7414/ (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 https://tools.ietf.org/html/draft-clw-rfc6434-bis-00
> format that document as an ISD.
>
> I had ISDs in mind when I originally drafted https://www.ietf.org/about/
> process-docs.html
>
> So yes, a nearly-ISD experiment could start today, IMHO.
>

This sounds right to me.


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


Of course.

My point is that I'd rather be sure that I can AD sponsor work on this
after March, rather than start something that another AD will have to
finish.

Spencer