Re: [tsvwg] Wanted: recovering IETF process wonk to explain the "Updates:" header
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 25 July 2016 16:57 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F5012D1DD for <tsvwg@ietfa.amsl.com>; Mon, 25 Jul 2016 09:57:16 -0700 (PDT)
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 vSTsSKpr0s8L for <tsvwg@ietfa.amsl.com>; Mon, 25 Jul 2016 09:57:15 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 D88FC12D1CA for <tsvwg@ietf.org>; Mon, 25 Jul 2016 09:57:14 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id j12so150700555ywb.2 for <tsvwg@ietf.org>; Mon, 25 Jul 2016 09:57:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hUvlDZZjgYNe1sEMUzxA+TAQ8Le8OrSfFY5fJO1WyEU=; b=QaDycI4O4HseghRXOJf+ad7rrjhaPn1agnbuRHifx1YNz3fwsFaIPTZ07YWDUHpRNf kUgOjZ7BDyVEvJ3fuzvNgqPOpMKYqBFYufXlXBl84B5XAM/Mfml6Y+mc1sWeutZga7g9 oUucYwUYq4EVRJhO5+ELxHmqH4dUUVSWl/vredelcO7tIEmeIPERSYhx0L939423rRQt sqT8p1KUEussrEPEUUK5Jw1PEiTR1w4B9gIJtqSIjBv7qMjDRfi9sLUGr8C2u1xFMc1x yd2Sqw7oKD69h0LgiTBhv9jq3FXQDYv0fxFpm3I3vHJ6Sz5XEnclfIT79dzzLHGCqJXV xOWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hUvlDZZjgYNe1sEMUzxA+TAQ8Le8OrSfFY5fJO1WyEU=; b=Yngu2zmrdc3+i/HtMwzD/8qCXkMyuZP4qjW62STvRbyjG3cwtqULsW53gDx3XO6edS KdxHpz1xvfWE6N/uZdOPZ3acBimE7VTFIuSSmz6kpmMAv/i98+kWoGKbPsFjXpKsRLIq GuzZsw7ZdjVWDUaV3SJtgF3Op1P80tvjRR2k74iAP9b375QJYmG/VoQ/KYpHMsBakLm/ +y4RfxNGPcmVsOr2Cdfa5M0bUOLxGg0ELevigdGIhVneOXGGZSbYk3pvrxcd3tJckc4g rz59kMAt7wIyOnHe+2hg4rdEe6mallMy2duHw8GlSdMC3GIZyhI9zJWa6mDBVAKlE3If HkHQ==
X-Gm-Message-State: AEkoouv0x7uacXzJANDKJYegIX0Ls8NQVnY+wdocUazruLcA5aAbKtr2w29669Uq09VNpHCbiTH+7W8XM5UNIw==
X-Received: by 10.129.73.207 with SMTP id w198mr15945380ywa.64.1469465834029; Mon, 25 Jul 2016 09:57:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.231.20 with HTTP; Mon, 25 Jul 2016 09:57:13 -0700 (PDT)
In-Reply-To: <5794CE1E.5020608@bobbriscoe.net>
References: <5794CE1E.5020608@bobbriscoe.net>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 25 Jul 2016 11:57:13 -0500
Message-ID: <CAKKJt-f=h8CJcc4J0cJkyDzBp+P_7JgWCZzKdJLpg=zQOj-DhA@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Content-Type: multipart/alternative; boundary="001a114dc91c0c08b3053878ad17"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/w-6dFNrNkH8cac5fXuIftq_ANhk>
Cc: tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: [tsvwg] Wanted: recovering IETF process wonk to explain the "Updates:" header
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2016 16:57:17 -0000
Hi, Bob, On Sun, Jul 24, 2016 at 9:18 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote: > Spencer, > > I searched for " recovering IETF process wonk" and a link to your > biography was ranked top {Note 1}. > > I'm looking for incontrovertible advice on whether I am correct to place > various long-standing tunnelling RFCs in the updates header of this draft: > https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis As a RIPW (my own words, FWIW), I don't think incontrovertible advice exists for this. A variety of IESGs have had a variety of opinions about Updates over time, and even with every IESG there's likely a range of opinions. I am told in another e-mail that the RFC Series Advisory Group was talking about the definition of Updates (and the even more dreaded Obsoletes) in Berlin last week, so , this is not an exact science. But, since you ask me, I'm the responsible AD and I have an opinion. My opinion is that you can say Updates for RFC FOO if you want everyone who implements RFC FOO to implement your draft, too. But rather than leave you with my vague opinion, I'd say that if you Tell The Reader what your draft is updating in RFC FOO and why, it will be a lot easier for reviewers to figure out whether the Updates header is legit. Sometimes that's obvious. Maybe you're correcting something that has already resulted in an Errata being accepted - RFC FOO says "meat" when it should have said "potato". Sometimes it's less obvious, especially when (as I believe the case is here) RFC FOO didn't say anything about "potato" at all, but anyone implementing RFC FOO needs to know whether to add potatoes. So, your explanation, that RFC FOO said "cook dinner" and didn't give all the details an implementer needs, would be very helpful, no matter what the Updates header turns out to say. Does that help? Thanks, Spencer > I believe it cannot be claimed that these RFCs did not already specify how > to process the ECN field, because it is not possible to encapsulate a > packet with a new IP header without creating a new ECN field. > Therefore, to my mind, definition of ECN field propagation is an update > not an optional addition to these RFCs (as I said in response to Mirja in > tsvwg on Friday). > > To be clear about the implications of this decision, if the IESG > eventually approves rfc6040bis as an RFC, if it states that it updates > L2TPv3 (for instance), I believe it would mean that an implementation of > L2TPv3 could no longer claim to comply with the L2TPv3 spec [RFC3931] until > it had implemented ECN propagation compliant with RFC6040. > > Cheers > > > Bob > > PS. Thanks for the advice to state explicitly how the text of each RFC > could be updated. > Will do. > > {Note 1}: I was initially worried that an RFC I co-authored was ranked > second, but I was relieved to discover that we had used all those words in > a purely technical context: the RFC talked about packet *process*ing and > *recovering* keys and C.K. *Wong* was a cited author. > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > >
- Re: [tsvwg] Wanted: recovering IETF process wonk … Black, David
- Re: [tsvwg] Wanted: recovering IETF process wonk … Spencer Dawkins at IETF
- [tsvwg] Wanted: recovering IETF process wonk to e… Bob Briscoe
- Re: [tsvwg] Wanted: recovering IETF process wonk … Spencer Dawkins at IETF
- Re: [tsvwg] Wanted: recovering IETF process wonk … Bob Briscoe