[eppext] AD review of draft-ietf-eppext-keyrelay-10

Barry Leiba <barryleiba@computer.org> Fri, 20 November 2015 20:02 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 48E4D1B33DF; Fri, 20 Nov 2015 12:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.122
X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8jMSYNZV2L51; Fri, 20 Nov 2015 12:02:16 -0800 (PST)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 EFCE51B33E6; Fri, 20 Nov 2015 12:02:12 -0800 (PST)
Received: by vkbs1 with SMTP id s1so4797093vkb.1; Fri, 20 Nov 2015 12:02:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=eC+28Zo60TyGEwyZfItfWG5JLks/QOK1jwsAIqpHkIM=; b=0m11LjLTZcDkOK97epoAAWrwckWAiPKhQZyiy4LgEaCIcCEYaq0nkz357TK+AQXU/C LIWfmvLpNv3cLMwXEjEixHtK/BkUyHOReicGlBZLt79YaVOQvew7R4B/0kckwWsgxPnL eoHXucZ5Z8uowTd1uvl0p2XBakJ6tPAIhOMRFjMbBRwF+tJWOk0Mnaz5JmvE2RYcF1T6 Hh7qybl91rzfEGsVHTT/MMMAel5cyJ6KenbWixJ94h6+g5n8PljaAy3o4p/jMenlDn0g 8bO32b0L/mgMF+d8FdQ11M/jWpXpySLo/JwmI6lZagct9l87GVor0B14xzug96ANeFOp 14fw==
MIME-Version: 1.0
X-Received: by with SMTP id y129mr1247996vkd.156.1448049732027; Fri, 20 Nov 2015 12:02:12 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by with HTTP; Fri, 20 Nov 2015 12:02:11 -0800 (PST)
Date: Fri, 20 Nov 2015 15:02:11 -0500
X-Google-Sender-Auth: bqV0ltMudk8Aa_LO1CaP6f8L5UI
Message-ID: <CALaySJKWK2R+FrtRPCM77eeVgjGSFXt5iuet2FrYmhYeQjiA0w@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: draft-ietf-eppext-keyrelay@ietf.org, Rik Ribbers <rik.ribbers@sidn.nl>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/qNFbRv1v55IrZ3ynBj0acXAa0nk>
Cc: eppext <eppext@ietf.org>
Subject: [eppext] AD review of draft-ietf-eppext-keyrelay-10
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2015 20:02:17 -0000

My apologies for the long delay in handling this publication request:
I've had a month straight of travel, including a little personal
vacation at the beginning and end.  I'm back and running full steam,
and reviewing the backlog of publication requests from several working
groups.  Thanks for the patience.

This document is well written, and I have only a few editorial
comments of the most minor kind.  Please put fixes for these in your
edit queue -- none of them need to block last call, so I'll request
that tout de suite after I send this message.

-- Section 1 --

   There are certain transactions initiated by a DNS-operator, which
   require an authenticated exchange of information between DNS-
   operators.  Often, there is no direct channel between these parties
   or it is non-scalable and insecure.

A picky English usage thing: in the first sentence you should remove
the comma and change "which" to "that".  I can explain if you want to
know why (just ask), or you can look up the difference between a
restrictive clause (which it should be) and a non-restrictive clause
(which it is).

-- Section 1.2 (also Section 6) --
You refer to this as "this I-D", which won't make sense when it's
published as an RFC.  Please change to "this document".

-- Section 2.1.1 --
Should the two instances of "previously send" be "previously sent"?