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

Heather Flanagan <> Thu, 31 January 2019 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7823F130DC0 for <>; Thu, 31 Jan 2019 09:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XpLcB5dWo5B2 for <>; Thu, 31 Jan 2019 09:28:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3624130DC4 for <>; Thu, 31 Jan 2019 09:28:17 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66E8D1C5E6B; Thu, 31 Jan 2019 09:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id roBbzd2Y8AJV; Thu, 31 Jan 2019 09:27:51 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 0844F1C5E65; Thu, 31 Jan 2019 09:27:50 -0800 (PST)
From: Heather Flanagan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A0745173-5C93-416E-BC99-468FC259FA0A"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 31 Jan 2019 09:28:16 -0800
In-Reply-To: <>
Cc: Robert Sparks <>, IETF Tools Development <>
To: Sandy Ginoza <>
References: <> <>
X-Mailer: Apple Mail (2.3445.102.3)
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 17:28:21 -0000

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.


> 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