Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

Mirja Kuehlewind <> Tue, 03 December 2019 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5D1B1200FD; Tue, 3 Dec 2019 10:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BaYVUBVpm8lo; Tue, 3 Dec 2019 10:28:45 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31F7F1200EC; Tue, 3 Dec 2019 10:28:45 -0800 (PST)
Received: from ([2001:16b8:24a7:d500:b415:78c7:b19a:2328]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1icCug-0000Ll-DC; Tue, 03 Dec 2019 19:28:42 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Tue, 3 Dec 2019 19:28:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Dave Lawrence <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1icCug-0000Ll-DC
Archived-At: <>
Subject: Re: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-dnsop-serve-stale-09=3A_=28with_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2019 18:28:47 -0000

Hi Dave,

Just on this point:

> On 2. Dec 2019, at 23:42, Dave Lawrence <>; wrote:
>> 2) I find the Implementation Status section (8) actually quite
>> interesting for this document and maybe it should be considered to
>> keep it in the document for final publication.
> I personally am in favor of this, not just for this document but for
> all RFCs.   RFC 6982 recommends that the section be removed, but I'd
> be happy to help evolve that recommendation.

RFC6982 recommends this because usually it's more important to have this information during the life-time of a draft (to understand the maturity of the protocol) but then it might quickly get out-dated after publication. However, we had also drafts were we retained the section for final publication because e.g. the whole draft was based on one specific implementation. I think that is also the case here and there is nothing in RFC6982 that permits keeping this information in the draft (if it seen as still useful in future).