Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)

Ted Lemon <Ted.Lemon@nominum.com> Mon, 08 September 2014 13:44 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: paws@ietfa.amsl.com
Delivered-To: paws@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2736D1A880E; Mon, 8 Sep 2014 06:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level:
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham
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 3us0EOEg75oD; Mon, 8 Sep 2014 06:44:56 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB721A8829; Mon, 8 Sep 2014 06:44:42 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AF9EF1B8638; Mon, 8 Sep 2014 06:44:42 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7DD0A53E074; Mon, 8 Sep 2014 06:44:42 -0700 (PDT)
Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Sep 2014 06:44:42 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <CABEV9RMWhMV2hum7QhS95C=ckEqA4eRA7Exj=p2+=j5LLsTiPg@mail.gmail.com>
Date: Mon, 08 Sep 2014 09:44:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <83BA02F0-4D05-4626-9DB1-57DB530BB815@nominum.com>
References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <CABEV9RMX6DPBCmao5owW3ajrNchnWCzRPR2=PCVU=1WYSMdxYg@mail.gmail.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <CABEV9ROXdJnhY1M-NcAJeHyRQx+N08ZDXFKFRzTPcGuCN3gF0Q@mail.gmail.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <CABEV9RN-yzaW885FJZaVArEECbb9-WOOfBdMZmg1x-1K9D6qfw@mail.gmail.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> <CABEV9RORY=6p6P_BiBp0t2aaNXpQYn25rWtCBGX3r3qYBWBBOA@mail.gmail.com> <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> <CABEV9RMWhMV2hum7QhS95C=ckEqA4eRA7Exj=p2+=j5LLsTiPg@mail.gmail.com>
To: Vincent Chen <vchen@google.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/T2TI7-hByudmutSZuHBxM3rGSFY
Cc: "paws@ietf.org" <paws@ietf.org>, "paws-chairs@tools.ietf.org" <paws-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-paws-protocol@tools.ietf.org
Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws/>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 13:44:57 -0000

On Sep 8, 2014, at 1:37 AM, Vincent Chen <vchen@google.com> wrote:
> LOL. That was the exact wording in Draft 12, but one of the ADs found it confusing and suggested rewording.

I agree that it's not ideal, but the new wording was actually ambiguous, whereas the wording I offered is merely confusing. :)

How about:

   If the Database examines the registration for each
   ruleset and can find no ruleset for which it can
   accept registration, the Database MUST return the
   NOT_REGISTERED error (See Error Codes (Section 5.17)).

I think this is less confusing, but lacks the ambiguity of the new text that the other AD proposed. :)