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

Ted Lemon <Ted.Lemon@nominum.com> Fri, 22 August 2014 13:20 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 1AD361A037B; Fri, 22 Aug 2014 06:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 GXzZcgaUA4Wf; Fri, 22 Aug 2014 06:20:39 -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 81EC71A026E; Fri, 22 Aug 2014 06:20:39 -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 4B2E61B86EC; Fri, 22 Aug 2014 06:20:39 -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 2A87853E070; Fri, 22 Aug 2014 06:20:39 -0700 (PDT)
Received: from vpna-167.vpn.nominum.com (64.89.227.167) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 22 Aug 2014 06:20:38 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <CABEV9ROXdJnhY1M-NcAJeHyRQx+N08ZDXFKFRzTPcGuCN3gF0Q@mail.gmail.com>
Date: Fri, 22 Aug 2014 09:20:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@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>
To: Vincent Chen <vchen@google.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [64.89.227.167]
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/3JbH-YXp7aFIpJLQkMh5bHQZIr8
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: Fri, 22 Aug 2014 13:20:41 -0000

[Resent because I forgot to Cc everyone.]

On Aug 22, 2014, at 3:03 AM, Vincent Chen <vchen@google.com> wrote:
>> It should not occur in practice for well-behaved devices.
>> 
>> When it is preconfigured, there must be a preconfigured value for each ruleset.
>> Of course, a device may choose to use preconfigured values for only a subset
>> of the rulesets it supports.
>> 
>> Note that, in practice, a device needs to be certified for each "ruleset" by
>> whatever process is defined by each applicable regulatory body, so that
>> any preconfigured values will be certified to be compliant.
> 
> If this is how it works, shouldn't the document say so?   Or was that in the requirements document?   I admit it's been a while since I read it. :)
> 
> I'll clarify the text some. Note, however, that INIT_RESP return these values
> as part of a RulesetInfo structure, so that it is implied that preconfiguration also
> must be on a per-ruleset basis.

To be clear, what I was suggesting ought to be documented is that the information has to be preconfigured and certified by the regulatory authority.   If this is already mentioned in the requirements document, there's no need to mention it here, although a reference to the previous document might be helpful for neophytes like me.   I don't really know what the mental context of a reader of this document would be, so please forgive me if I'm being ridiculous here.

>> In 4.4.2, I think that if none of the rulesets are accepted, the intent
>> is that the database should return a REGISTRATION_RESP with the error
>> element, and will not return a rulesetInfos list.   However, the
>> specification does not make an exception for this case when it says "A
>> RulesetInfo list MUST be included" and  "The list MUST contain at least
>> one entry".   I can't think of another valid interpretation, but you've
>> stated a MUST, so you need to say that it doesn't apply in the case of
>> the error.
>> 
>> Ah, right. There is language from INIT_RESP that needs to be repeated here.
>> 
>>       If the Database does not support the device or any of the rulesets
>>      specified in the DeviceDescriptor, it MUST instead return an error
>>      with the UNSUPPORTED (Table 1) code in the error response.
> 
> That doesn't fix it, though—you need to fix the other MUST to say "unless there's an error" or words to that effect.
> 
> Actually, REGISTRATION_RESP is returned only when there is not error,
> so if it is returned, it must have one or more entries.
> 
> The "it MUST instead return an error" should suffice to clarify this?

The problem I have with this text actually stems from the first paragraph of the section:

  The registration response message acknowledges successful
  registration by including a RulesetInfo message for each ruleset in
  which the registration is accepted.  If the Database does not accept
  the registration for any of the rulesets it supports, the Database
  MUST return the NOT_REGISTERED error (See Error Codes
  (Section 5.17)).

In reviewing this just now, I realized that I may have completely misinterpreted the second sentence.   It probably means either:

 If the database does not accept the registration for any single
 ruleset it supports, the database MUST return the NOT_REGISTERED
 error.

Or:

 If none of the rulesets being registered are accepted by the
 database, the database MUST return the NOT_REGISTERED error.

Right now, your use of "any" could be interpreted either way.

And then, what I was asking you to change in this DISCUSS item was this:

  rulesetInfos:  A RulesetInfo (Section 5.6) list MUST be included in
     the response.  Each entry corresponds to a ruleset for which the
     registration was accepted.  The list MUST contain at least one
     entry.   [If an error is being returned, this list MUST be
     omitted.]

The text in brackets is what I am proposing that you should add.   Otherwise you are giving the implementor conflicting instructions--a MUST is a MUST, and has to be followed, but of course it can't be followed if no rulesets match.  I'm just asking you to make that explicit so that nobody gets confused.

Anyway, it sounds like we're converging.   Let me know if what I'm saying still doesn't make sense.