[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.
- [paws] Ted Lemon's Discuss on draft-ietf-paws-pro… Ted Lemon
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Vincent Chen
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Ted Lemon
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Vincent Chen
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Ted Lemon
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Ted Lemon
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Vincent Chen
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Ted Lemon
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Vincent Chen
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Ted Lemon
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Vincent Chen
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Vincent Chen
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Ted Lemon
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Barry Leiba
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Ted Lemon
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Vincent Chen
- Re: [paws] Ted Lemon's Discuss on draft-ietf-paws… Ted Lemon