[DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

Tim Wicinski <tjw.ietf@gmail.com> Sat, 28 July 2018 09:30 UTC

Return-Path: <tjw.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD83130E13 for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 02:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CrqzdH2BCpr for <dnsop@ietfa.amsl.com>; Sat, 28 Jul 2018 02:30:07 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430AD130DC9 for <dnsop@ietf.org>; Sat, 28 Jul 2018 02:30:07 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id v14-v6so7416108wro.5 for <dnsop@ietf.org>; Sat, 28 Jul 2018 02:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JOj32FAEFHpivsX8XaYtHXZ9rKqrqELqe1faplf0O1g=; b=hjbxmol4qQcAklyXylK1tVrLZMxhzIJItAusxVMg29O2d3Ngegt/XVMau8dlJMxD+U 9YJGgUvCa8DmtKqZxI/KI9lgBI0CMdpNMSNsDhYOvOjmiFjwXKbRi34AykawDFglWXmT DkpTuaqTp0Poaagi6ZvX0bILwv8E7jWqzTe3u9C12Qu5hG9VW6MFNndCYxkcVSj4Wmz7 315BerfaBzrN5Hr78zJPt4xq8GMmeHXA4vebrlQu8B91pPYa+Upv4u2dlu+59sPk5Cka 8RBRzjEXG+oTqqd/7ZqhoiaDv9fyRTv7iKybcVMOdukG9RFsFIZnJF/1ucbVK7sjagPa ndAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JOj32FAEFHpivsX8XaYtHXZ9rKqrqELqe1faplf0O1g=; b=JPRLjQKv5RDlrlPDtTaOCDnvSPgSyT3x9v4v7r5OL+KcYsXBcecTomFhxMOJ+qo56q 52jzhcN0xP+wDLZctGZ+ILtr/NJS/UHmL1/uL1LxBFPJ0Y51kgnp0rDsfRDTPxxb/XrD 8SYfgUI9w8qhrKSmUp3a8oavAt1EfHOEhxfthkIYw/l0K5OCubQNFNmTgoV2Z1kErxDW 1J4hl4NmaHIpBtJByElbaamoeG9v9VYN9VB1tkMJRrQqctUDwkw9mXOsnu4sVe2Y0Mic kBNHUV5f+o0RYgr7wnkMeQLN/VyFfsx9wHWblmTtafiQ8tQluV+TW2JaQlvkoLLtuWb3 1xXQ==
X-Gm-Message-State: AOUpUlHD0H2ayHTho/FO6+3v3gXbZ7bDXr8KkRBVsGPdOjgNuklBt6Wo sleqAq7ketnEWOJHRzxP8c59sB/BZxSckz+tVqMjL3jN
X-Google-Smtp-Source: AAOMgpedLYpxBj426ZV4YEmCnnM1uKpOrOJBj5wHOTgB+vIbBnnzxfi80ft9tuI6MPSvYGSguONNX8PBWZXifTh4OuE=
X-Received: by 2002:adf:9086:: with SMTP id i6-v6mr8319622wri.271.1532770205700; Sat, 28 Jul 2018 02:30:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 02:30:05 -0700 (PDT)
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Sat, 28 Jul 2018 05:30:05 -0400
Message-ID: <CADyWQ+HizOJsE9EZ=VEvrbnnyPwaG_yBRg7fP5VvUNTdnidXZA@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a2189005720bdfef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rwOGqDVU6kCv2zhgeImwQUKXMIw>
Subject: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Jul 2018 09:30:10 -0000

(these are just my comments alone. So take it as such)

The draft states in the Motivation section:

 "The motivation and design of this protocol enhancement is tied to the DNS
root zone [InterNIC]."

Your Design Overview states that this will work for zones that are
"relatively stable and have infrequent updates".  I think some descriptive
text about the type of zone this RR type attempts to address should be more
clearly spelled out in your Abstract.

For the ZONEMD RR Type, where in the registry do the authors think it
should go?  While some of that falls on the Expert Review process,  I think
the document authors should capture their rationale in the document.  If
the proposed RR Type is greater than 256 (which I think it does), it does
not appear to require a Standards Track document, just Expert Review.

I ask this since the document is listed as "Standards Track" and the
document is narrowly scoped to focus on the Root  Zone. Additionally the
document states: "This specification is OPTIONAL to implement by both
publishers and consumers of zone file data."   This appears to be
contradictory to me, but hopefully someone can illuminate me.

I ask all of this because we have seen the working group start to push back
on similarly scoped Proposed Standards (kskroll-sentinel).

Though I do find it amusing that you use "The Camel" as the excuse for such
a limited scope use case, even while requesting a Proposed Standard!

Now I will find that you've already answered all these questions and I
failed to find them in the mail archive.

tim