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

Warren Kumari <> Tue, 03 December 2019 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35AD212002F for <>; Tue, 3 Dec 2019 12:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zh_Ngy-0ueTj for <>; Tue, 3 Dec 2019 12:22:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D431D12000F for <>; Tue, 3 Dec 2019 12:22:57 -0800 (PST)
Received: by with SMTP id d202so4855947qkb.1 for <>; Tue, 03 Dec 2019 12:22:57 -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:content-transfer-encoding; bh=lBirvs7pvlq0LsSF8RCQZe/tD0RWlIznuMIGlxwi/Ek=; b=L+NVn7w7pG/eKIWbJuNTgPXD5sEpMhe4xxb9emt4duagPMWoTLK1Y4jEIfsQhYI0h0 V8MviPKcWeQzTDs7JS4q+Tbc8wVf2wKy01GJSMd8kCDgqm0hKORn5skwe/mwxWixqWgU 94h+NEvAI+h1piFILqZac+Zx5Kvq/t5ZjSFeOCtOAzlQBuPjw7BKemSESLa2yuSOM9Dz o0iAxDyI2WTm2G3iomIOckxUA2FhoqJGJLv8bYweKt5gonOeSceP9Vus5yLsAX4YoTDl AcBiV3ZIY5SBf+CUX6kqXg0qOi3w3/TZOIqAy+PylL9rXDFU6YxenI+HaUwkP5kMlvvj M2ow==
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:content-transfer-encoding; bh=lBirvs7pvlq0LsSF8RCQZe/tD0RWlIznuMIGlxwi/Ek=; b=dQgDtuIlbD+fyfKvVoLR6bFM+fXajtB/0Uk4lEisnYrPVF+Qi586zQPGLz9ISPRLpV xKsjOO++ZjxW1Rv4cdNBgFoV0fAj1+hVqp6h1QWXTiAaWxGCbh0DP4z4JQydv6E/AuSh v9sZjvrffxm2oj5jxXqic+4qPGHf1kka8LNAsUaA7kMPkyxHpw89okzi8Qx22aSUhupQ 14M7VNcdfULPfYhMH7w7aFAGNF+w1r+XQstqr9NDwNCxcd+cajRUgfx9G4lhFFIhJzyu xBD2TJfkjjjs2yhDZbD2V6W+fnGWIiW/3LXRlJBLcBwN2OJXsiQwd0pe5pFi4z8a0HTv +xoA==
X-Gm-Message-State: APjAAAWZgaIDZY5NFoWBSQiR/H1zx54ejep1gPx3YZfPHUs3S0jylKeC 44uXeMbezltRL7qW4ylBfYJDQVmYnxKETnOc3QbICw==
X-Google-Smtp-Source: APXvYqzYadtrGlkdJTl3o9e2SZhlni/zFtpCBzwmkUDU80gP+DTOx4cwTdya8fL2TG/RtqHwQqRkrJ85uabyEOpSAnM=
X-Received: by 2002:a05:620a:94f:: with SMTP id w15mr7336006qkw.63.1575404576479; Tue, 03 Dec 2019 12:22:56 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Tue, 3 Dec 2019 15:22:20 -0500
Message-ID: <>
To: Mirja Kuehlewind <>
Cc: Dave Lawrence <>, The IESG <>,, DNSOP-Chairs <>, dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 20:23:00 -0000

On Tue, Dec 3, 2019 at 1:28 PM Mirja Kuehlewind <>; wrote:
> 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).

Note: Author hat only.

I'm not 100% sure, but I suspect you meant: "I think that is also the
case here and there is nothing in RFC6982 that **prevents** keeping
this ..."?
I'm personally in favor of keeping the information - even if it ends
up out of date, it still seems useful to me.


> Mirja

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.