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

"Ted Lemon" <ted.lemon@nominum.com> Thu, 21 August 2014 13:30 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 668051A02DB; Thu, 21 Aug 2014 06:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 L5EIgIq5GPsO; Thu, 21 Aug 2014 06:30:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0BA1A02D8; Thu, 21 Aug 2014 06:30:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "Ted Lemon" <ted.lemon@nominum.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140821133025.17118.4987.idtracker@ietfa.amsl.com>
Date: Thu, 21 Aug 2014 06:30:25 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ii0fXQdIcGjEeYB7QilE4eiuWrU
Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org
Subject: [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
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: Thu, 21 Aug 2014 13:30:27 -0000

Ted Lemon has entered the following ballot position for
draft-ietf-paws-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a cool document—I'm glad the IETF is working on this.   Please
don't take the following comments as anything other than an attempt to
address what I think are some relatively minor issues with the document,
hopefully easily addressed.

4.1 says "Some regulatory domains may have specific rules regarding how
long the spectrum data remains valid in these cases."   It might be worth
adding that in such cases the initialization procedure is required.  
This is addressed to some extent in section 4.3, but I'm not sure it's
completely addressed.   The potential problem I see is that a device
might be used in a regulatory regime where this is required, but might
have pre-configured values for some other regulatory regime.   If these
values are not valid in the regime that applies for its current location,
it might have a too-long refresh interval configured, fail to detect that
this is the case, and as a result accidentally break the law.   Can a
scenario like this occur in practice?

Section 5.2 says that the manufacturer ID and model ID are optional, but
may be required by some rulesets.   Section 4.3.1 does not say what error
is returned when a deviceDesc that does not contain one or both of these
parameters is sent to the server, but the matching ruleset requires
either parameter.   I suspect the answer is straightforward, but I think
it needs to be stated explicitly in 4.3.1.   E.g., if the optional but
required parameters are accepted in the initialization but rejected in
the registration, it would be good to say so explicitly.

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.

In 4.5:

       If some
       locations within a batch request are outside the regulatory
       domain supported by the Database, the Database MAY return an OK
       response with available spectrum for only the valid locations;
       otherwise, if all locations within a batch request are outside
       the regulatory domain, the Database MUST respond with an
       OUTSIDE_COVERAGE error.

What should the database do if it doesn't follow the MAY?   Should it
return an OUTSIDE_COVERAGE error?   It seems to me that this MAY is going
to require some unclear heuristics on the side of the master device.  
Why isn't this a MUST?   I think if this were a MUST, it would be clear
how implementations should behave; by making it a MAY, there's a big gap
that I think will lead to interoperability problems as different
implementors make different choices about how to treat this situation.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3 describes spectrum-usage messages as purely informational.  
Section 4.5 says that the database can require that such messages be
sent.   Which is it: is it sometimes required, or always purely
informational?   Or does "purely informational" just mean that the
protocol provides no mechanism for tracking such notifications?  It would
be helpful if this were clearer.

In 4.1, the database URI change spec seems incomplete.   Is there a time
when a database starts announcing its URI change after which it need no
longer provide service on the old URI?   I see Alissa asked a similar
question, so I imagine you could address both questions together.

In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be
somewhat fluid.   I think you intend for it to mean one specific thing,
which might imply one of several other things.   But you don't say the
one thing that it means: instead you mention possible implications.   It
would be helpful to try to make this more explicit.

I think Stephen noticed this same problem, but to be clear, it appears
that section 4.5 says that when the master is sending a request on behalf
of a slave, it sends its own location.   But section 4.5.1 says that the
master sends the slave's location.   It appears that there are two
parameters, one being the master location, which is required, and the
other being the slave location, which is optional.   However, this is
never really stated explicitly; it might be helpful if it were.

I have to confess that the use of "master" and "slave" throughout this
document makes me quite uncomfortable in reading it.   It would really be
preferable to use terms that have less painful history associated with
them, like "core" and "leaf" or "coordinator" and "supplicant."   I
realize this is a matter of taste, and I do not at all mean to suggest
that there's anything wrong with the use of these terms, which are
certainly common in the computing industry.   This is just a comment, and
whether you address it is entirely up to you.

In 4.6.1, it would help to have text that explains what it means to
validate a device.   It's certainly not required for interoperability,
but might be helpful for implementors of database servers.

In 5.3, it's a little puzzling that antenna direction, radiation pattern,
gain and polarization aren't defined, because they seem like properties
that should have universal applicability, even if they are not required
in all cases.   Is this being left as future work, or is there some more
subtle reason why these haven't been defined explicitly?

In 5.11, power is expressed in dbm, which leads me to wonder if this is
the product of the antenna gain and the input power to the output
amplifier, or whether it's just the input power to the amplifier, or
whether it's being left intentionally ambiguous.