Re: [regext] Opsdir telechat review of draft-ietf-regext-dnrd-objects-mapping-08

Barry Leiba <> Sat, 25 July 2020 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A4AE3A0C46; Sat, 25 Jul 2020 09:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IHq9vOXuE4iI; Sat, 25 Jul 2020 09:30:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 203603A0B30; Sat, 25 Jul 2020 09:29:57 -0700 (PDT)
Received: by with SMTP id k23so12818856iom.10; Sat, 25 Jul 2020 09:29:57 -0700 (PDT)
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; bh=G+WkukrnDsX/FwroXzdI0AXBvQIPfMfzWshKqleHixM=; b=pt+DdfpDLZi487qLykQurLxGoYW5WBfW9NpLkAICs/OORP1X0vORnoCnzgEzyvQssw it1P5y3kcTOG+Y3OyVVvnzCmS8XGvpo30EmmS5Fog1HEEZ2WrTsjA/gGQNzKUa1Ep12B kIZVvr9hiTCsx2yNMp87F6DEfs87E8MJn1u2CumpJl3TKWaKgvhRfzaWDqNtdP6p90oc En63SOxSUlGaEnjDWlt/L/Fi5mVWEtjeH38HKoR0Ht/tRN9x1/dK7BTMY2rlBh2xy2W5 wcuSVFNuoBBs64J+dFjuaR6RBw23jPJ/h1q08W7N2rM/UI7UHiggaGrUoteBykM55Isv g2Gg==
X-Gm-Message-State: AOAM530ISc5wHep0C61YtRk3ivdffl7yfV+6BGWi/UVWuKgvxwKE4NY4 MSChqkGoViqBeO8qgL7cT/4hv6H/DFeOFrE5vWM=
X-Google-Smtp-Source: ABdhPJzimPbwQEYt+e9ay6p6JMf0czGfULxTIhyQUuvxOeM6kd/lAlJwrrHmoH0W6ONGe9kcPWCMUChvnS4YWWfTa8E=
X-Received: by 2002:a6b:1885:: with SMTP id 127mr9438464ioy.17.1595694596191; Sat, 25 Jul 2020 09:29:56 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Sat, 25 Jul 2020 12:29:45 -0400
Message-ID: <>
To: Joe Clarke <>
Content-Type: multipart/alternative; boundary="00000000000093787e05ab4699ef"
Archived-At: <>
Subject: Re: [regext] Opsdir telechat review of draft-ietf-regext-dnrd-objects-mapping-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Jul 2020 16:30:02 -0000

Thanks for the reminder and the review, Joe.  I will make sure your
comments are addressed before the document moves forward.


On Sat, Jul 25, 2020 at 11:47 AM Joe Clarke via Datatracker <> wrote:

> Reviewer: Joe Clarke
> Review result: Has Issues
> I didn't see any of my comments addressed in the text nor do I recall
> seeing a
> reply to my previous review.  I;m copying my previous review here.
> I have been assigned to review this document on behalf of the Ops Area
> Directorate.  This document augments the work set forth in
> I-D.ietf-regext-data-escrow to specify the objects that can be used in
> Domain
> Name Registration Data escrow deposits.  What I found most useful in this
> document is the incremental examples of the objects with the full XML and
> deposit (and diff deposit) examples at the bottom.  In general, the fields
> in
> the object models were well specified and coupled with the examples, it
> helped
> to piece together the product one might need to produce.
> That said, I went back and forth between "Has Nits" and "Has Issues".  One
> thing that would really help this document is a full terminology/glossary
> section that includes expansions of abbreviations like RDE, EPP, NNDN,
> etc.
> Some abbreviations like TLD, CSV, and IDN are expanded, but this is very
> much
> required for all and throughout with very common ones done so in the
> terminology section.
> Next, in Section 4.4, you talk about CSV file checksums.  First, you
> reference
> ISO-3309 (HDLC?) but there is no actual reference like there is with
> ISO-3166-1.  But why use crc32 for a file checksum?  Why reference HDLC as
> the
> model?  I would think a SHA-2 checksum would be better for an actual file
> to
> ensure it has not been tampered with.
> When you talk about file compression for CSV (Section, you mention
> compression may use zip or gzip.  There is no normative language here, and
> I
> can imagine escrow holders would need to know the allowed values.  If I
> use xz
> will that be allowed?  Will the consumer know how to decompress that?
> What is
> "zip" and "gzip" exactly and how should they be handled?  My advice is some
> normative text here explaining the supported or allowed formats and by what
> standard those are defined.
> Finally, as a nit, I noticed two instances of IPv6 address
> 1080:0:0:0:8:800:200C:417A when showing XML model examples.  In the CSV
> examples you use an address from the doc range.  Did you mean to do so
> here as
> well?