Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf-fix

"Murray S. Kucherawy" <> Wed, 18 July 2018 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F3B41311AC for <>; Wed, 18 Jul 2018 09:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Iru_wl3y_nIo for <>; Wed, 18 Jul 2018 09:38:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28D76130EA8 for <>; Wed, 18 Jul 2018 09:38:22 -0700 (PDT)
Received: by with SMTP id r13-v6so4664079ljg.10 for <>; Wed, 18 Jul 2018 09:38:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fqUfUPDIYQ8xinInocvJ6cll0iYdd8O8MxQMWB9y9Ds=; b=MCFc/Zqm12Y0snMpmTlyC+1HqroIymrxfHNrNWCXVnbcyYwI8THbXu++hbdzKZ+Gjw 3npNb31xWq9GuljQHXBI5ddpUP9yFDPJD7go2rove+4aEB6vCX1qjuQDOjkxHfS7wLNx mZ8pizmopAbhBuF13IU7kN66r6IEZ8sDKd5JoxobNuSku/2kurSKKSU/eCWPMlpjwSqE p7uJSoSS6NshZB3t/79Rnz43NrhgCevWggOO38O3ZIn4cZ8SRPN8uc8qa5FHJBhlP/ut J/nGIcJCsQYOL7LX2CtbDTb8hphQeTVunIGGr/2tSqe6jxfLg+SBu+wKjX//9PCt/3PC Gn8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fqUfUPDIYQ8xinInocvJ6cll0iYdd8O8MxQMWB9y9Ds=; b=Q2u5CTfGkqDa1XnDjiNTOvqkRNK7Zg2HjLo7Wy2dhotw4xnQyFKXdv32TYh6qpC7/J nAEvzj47gp95oiux2dDpSCUdNIbZkoLQ8wimPoub1HOWtL1WfzG9w+IQBcz1uapffP/U h+wH8MiPxwJYn13xjbASbLASKQFAYGN5z7MMWRrekix0qWrjvCiIZ5KPFX8YlmfsEA+Y gnipDdbJtBUiRPEv9VA5QcaSw3nVuS7ETa8zLaHztztUa0c66nltsd1aJnBHESyOF/dq D/Ffb5vawzbmbmCauVSINq+q69yw0fPewK2OsToVsIo+zQ4iboDVbbrJTtBDC+3Ns1Y+ Fv0g==
X-Gm-Message-State: AOUpUlF9/4CFAY1VMbQGZM3S4HviL4g/8BGe7S60TPdt1v4cNhPwUjMz bYIi7x75YTJnLBCdQLzW9PUXwlqshq9ndlkZrTw=
X-Google-Smtp-Source: AAOMgpfDzZ7yOd5RfGfdmlantJyJ8dnfAqQdku7ufmxj8M0JHMhpxlc2qSQb/jIgUCDPCJ/rZQIqkgGgzyniOM8UfIM=
X-Received: by 2002:a2e:4357:: with SMTP id q84-v6mr5023756lja.13.1531931900361; Wed, 18 Jul 2018 09:38:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 09:38:19 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: "Murray S. Kucherawy" <>
Date: Wed, 18 Jul 2018 12:38:19 -0400
Message-ID: <>
To: Dave Crocker <>
Content-Type: multipart/alternative; boundary="000000000000bdbf24057148b09d"
Archived-At: <>
Subject: Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf-fix
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jul 2018 16:38:26 -0000

On Wed, Jul 18, 2018 at 12:33 PM, Dave Crocker <> wrote:

> On 7/18/2018 8:37 AM, Murray S. Kucherawy wrote:
>> Section 3.2 replaces text in Section 4.1 of something, but I don't know
>> what; the prior paragraph refers to multiple other documents.  I suggest:
>> (a) clarify which document's 4.1 is being replaced, and (b) don't bother
>> including the original (replaced) text.
> I'll add reference to the RFC being modified, closer to the modification
> text, but I'd rather keep the old language in there, to reduce the
> likelihood that someone will replace too-much/not-enough of the existing
> text.

My concern here is based on past ART efforts where direct citation was said
to risk inaccurate copying, and thus semantic drift.  Naturally in each
instance it's easy to argue "This is a correct copy of the text being
replaced" but it's still a generally discouraged practice.

Over in DCRUP, we faced the same problem and instead produced Section 3 of
RFC8301 with this in mind, for example.