Re: [TOOLS-DEVELOPMENT] Draft of inline-errata SoW

Eric Rescorla <> Thu, 31 January 2019 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6ACC7130F00 for <>; Thu, 31 Jan 2019 12:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 qAzMn6Swxlcn for <>; Thu, 31 Jan 2019 12:45:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41B4E130EF3 for <>; Thu, 31 Jan 2019 12:45:03 -0800 (PST)
Received: by with SMTP id z13so3364806lfe.11 for <>; Thu, 31 Jan 2019 12:45:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nZVqbpO2wN/KMAZB2GzX916qI/MDjjMAz+R58q5WW/E=; b=OIyHfp2lUhFtvHtBeYhnsLC5LD+Yn1ORuut5tCjLoNhcwZhkN6oMAZwOW7evEFz6lJ nkJJkSUCXKK2tMQjR7zIsEA8J2SZZ8g3CytOIVmaQH9WGmPOpsb3ThSMfEzPH91KL+Pu QWD8pIxtTGd1UVMXR4LcsNM8PgZ4nnIQlNKQSOCIRSzGkHiSvpJzbEozesHLPTjcPUDT xh30WEVdkujDTuEoQWNoSMQ1ZJZPfolE1me2wHhGQjvv1lrxq6uB3ycUYxn0Jnd8m4Te AGhOATOwhIwaZMyuT1G2OdfxxBZoIf9a84grj+TxvSv8E2zNOH5akiINIlaX2oWt+yY2 HOZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nZVqbpO2wN/KMAZB2GzX916qI/MDjjMAz+R58q5WW/E=; b=KNwUMtwHulEjgBiecXF2O5x+E2HJ4esFNIBiM5VlJ9k4QfxC6Bl1DTHRVBmBAdgOdw zhjlKZMp/Fi4vj/rKc+YB2SyUIvYZs1eGkH0cyXyLWeqR+Cp01bnIxWviiNTUZOUJa6t yXBRYo0VwmF2clvWnpM0trlZN9ovtARW1CFVK/GM7pBCB4vemvI72UkjYKE+mt+3JXu0 w38N2jqne/swxmuRFRB9PyW1Vs2Hlg/L5CQlTr7KhYJMT/w+sysi0Ium5+yqtsAVQKPw 6rzQM97YYu8QmGF0nJFEkbhQE5zNs8mNS4ezLzSrnRRUO8fYR/kWNd91lmEoeO292wpD Kp6A==
X-Gm-Message-State: AJcUukeiFQGKVGh/9sk6rxbx3pErM3ZweGej23IpuvHJAX4czTIOKTSj mQpPF6yENUj6Vrlwd1tK0m3oVXEiTZ7xgquJvDYDqQ==
X-Google-Smtp-Source: ALg8bN7sHKe9jCBvcOXaJimlT1IPdkfZpnl1D/BGKtHmcqauGP3eS2fHA7vvaQCcufZQtGVV/hJgvkH1EWGlBXr3ZcM=
X-Received: by 2002:a19:3fcf:: with SMTP id m198mr26027696lfa.106.1548967501070; Thu, 31 Jan 2019 12:45:01 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 31 Jan 2019 12:44:24 -0800
Message-ID: <>
To: Heather Flanagan <>
Cc: Sandy Ginoza <>, IETF Tools Development <>
Content-Type: multipart/alternative; boundary="000000000000ab9a6c0580c71910"
Archived-At: <>
Subject: Re: [TOOLS-DEVELOPMENT] Draft of inline-errata SoW
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Development list server <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Jan 2019 20:45:10 -0000

On Thu, Jan 31, 2019 at 12:20 PM Heather Flanagan <>

> Hi ekr,
> I understand your point, but must disagree - these documents will not be
> fully archived,

I don't see how this is relevant. In my hypothetical, the version which is
"fully archived" is simply wrong (and in fact, self-contradictory), so it's
not sensible to talk about having normative status on that point.

and the verification process is outside the consensus process (which I
> think is important for IETF documents).

This seems like an interesting point, but is actually mitigated by the fact
that if the approver makes a mistake, we can change the erratum again.

Taking a step back: an RFC -- at least a protocol specification --  is a
set of instructions for how to implement a protocol. And what people need
to know is how to actually implement the protocol. And when there is a
clear error in the specification that doesn't match how the specification
is being interpreted in practice, then it isn't helpful to act as if the
error has normative force. The question is what the best interpretation of
the RFC is at a given time.


> -Heather
> On Jan 31, 2019, at 11:29 AM, Eric Rescorla <> wrote:
> Hmm... I'm not sure that that's quite the desirable outcome.
> Let's take the example of a clear (and minor) technical error: in the body
> of the text, the RFC says that we use code point X and in the IANA
> considerations it says code point Y and the code point that people use is
> actually "Y". So, someone files an erratum that changes the body of the
> text to read Y. In this case, we absolutely do want people to think that
> the annotated version is the one with normative force.
> -Ekr
> On Thu, Jan 31, 2019 at 9:28 AM Heather Flanagan <>
> wrote:
>> Hi Sandy,
>> You know I like the idea of a sandbox space - the RFC Editor needs a
>> better way to explore ideas in a visible way. That said, there is concern
>> about any hint of normative-ness to the annotated docs, and hosting them on
>> the RFC Ed website might suggest some amount of officialness. I think we
>> can potentially mitigate that by including something in the CSS that THESE
>> ARE NOT NORMATIVE DOCUMENTS, but other ideas are welcome.
>> -HEather
>> On Jan 30, 2019, at 6:47 PM, Sandy Ginoza <> wrote:
>> Hi all,
>> I figured this comment/question would be more appropriate here rather
>> than as feedback for the SoW.  I can’t remember if placement was decided
>> when the IESG discussed this topic at the last IETF, so sorry if this is
>> re-raising discussion I should already be aware of.
>> The text says:
>> This tool will initially be used to create pages served somewhere other
>> than the RFC Editor’s website ( After gaining
>> experience and community feedback, the pages might be moved to that
>> website. Thus, the development of the tools should assume that the way the
>> results are deployed will change over time.
>> The RFC Editor has been talking about creating an experimental space on
>> our site.  I think it’s worth considering having these annotated documents
>> live in an experimental space on the RFC Editor site so they’re on the site
>> from the beginning.  This seems like a perfect use for an experimental
>> space.  Also, I believe that once these documents live somewhere, that is
>> where users will look for them; if they become the de facto RFCs, I think
>> we want them to be on our site.
>> Thanks,
>> Sandy
>> On Jan 29, 2019, at 12:07 PM, Robert Sparks <> wrote:
>> Adam's developed an initial draft for the inline-errata SoW. He started
>> it as a google-doc and my initial set of feedback changes were easy enough
>> to make there. Unless someone objects, I suggest we continue the
>> development of this one using that tool. If you do object, for any reason,
>> please let me know and I'll send a PDF while we adjust.
>> RjS
>> _______________________________________________
>> TOOLS-DEVELOPMENT mailing list
>> _______________________________________________
>> TOOLS-DEVELOPMENT mailing list
>> _______________________________________________
>> TOOLS-DEVELOPMENT mailing list