The Last Call should be coming out of the secretariat soon. Trimming the
message to things where I still have some comments. Please consider the
following part of the Last Call comments:
On 1/29/13 5:15 PM, Anthony Mancuso wrote:
Abstract
End of the first paragraph, perhaps add: "The IETF has undertaken to
develop a protocol for that management database."
___
Mancuso: Done
_____
Introduction
Also added reference to the PAWS protocol to 1.1.
Please don't refer to the WG, either in the Abstract or in the Intro.
First of all, there ought to be no references in the Abstract anyway
since the Abstract is often displayed in announcements and other places
without the rest of the document. But more importantly, I don't think
what you put in flows very well. In the Abstract, just saying "protocol"
is sufficient. In the Intro, I'd suggest simply changing the last
paragraph to:
This document includes the problem statement for the development of a
database query protocol to access a database of whitespace
information followed by use cases and requirements for that protocol
associated with the use of white space spectrum by secondary users.
3.1 & 3.2: Throughout this section, there's no need to use the term
"master". These services exist whether a device is acting as a master
for other devices or whether it is acting on its own. Given that
there's been no discussion of slave devices yet (that happens in 3.2),
I found the use of the term "master" confusing in these sections. (I
suppose you could expand the definition of master in 2.2 to explain
that it could refer to a device acting on its own with no slaves, but
I still think that might be confusing.
_____
Stanforth: Broadcast use case is a master with no slave, at least in
the context of a slave that communicates with or is controlled by a
master.
_____
Resnick: So are you saying we do or do not need the term "master" in
these sections?
_____
Mancuso: I clarified the definition of master device: "A device that
queries a database, on its own behalf and/or on behalf of a slave
device, to obtain available spectrum information.". I think this
definition plus the definition of a slave device ("A device that
queries the database through a Master Device.") makes the use of the
term in this and latter sections and illustrations appropriate --
namely, a master device is one that contacts a database to obtain
spectrum (for itself or other devices). Slave devices under these
definitions, do not contact the db directly, omitting them from the
discussion and refering in the text or illustrations solely to a
master device makes sense, and is not dependent on also referencing a
slave device. Another way of saying it: we use the term master only as
a way of describing a device used to query the db directly for
spectrum availability. Denoting a device as master does not
necessarily imply the use of slaves (devices that are not used to
query the db directly) in a particular use case or illustration.
That's all fine, but then in the first sentence of 3.1, it says "A white
space radio network is created by a master device." That's not true, or
at least not necessarily true. The white space network is created by
either the master or the high-power slave. What defines something as a
master is not that it creates a white space radio network. A master is
simply defined as that which queries the database. So I suspect the word
"master" in this section is wrong and the first paragraph of 3.1 needs a
bit more work to remove all reference to creation of the whitespace
network. Creating the network is not part of the discovery phase at all.
3.2: Similar questions regarding regulatory domains. For example, "2.
To register with the database, the master device sends the database
the registration information required under regulatory rules." How
does the device determine which regulatory rules it is under and
therefore which information to send to the database. If the answer is,
"It queries the database", then it is not the regulatory rules the
device cares about; it is the information the database is configured
to ask for (which will presumably be in accordance to some
regulations, but are out of band of any protocol work). If the answer
is, "It is pre-configured in the device", then the regulatory rules
are again out of band. Either way, mention of them would be unnecessary.
___
Mancuso: Agreed. I think this was simply a matter of misphrasing.
Deleted the extra language to read: "To register with the database,
the master device sends registration information to the database.
There are still several references in 3.2 to "regulatory domain" and
"regulatory requirement" that I think are unnecessary and confusing and
should be removed.
4.2: This scenario was confusing to me because the master seems
completely unnecessary to the example. Please explain.
_____
Mancuso: As noted, the master is optionally used by the slave to query
the db for spectrum. And again, master only connotes the device's
ability to query the db directly.
OK, this section still does not make sense to me. The slave is getting
whitespace in this scenario. But in the diagram, the slave doesn't have
the antenna; the master does. That doesn't jibe with the rest of the
example. If it's the slave that wants to move away from it's metered
service and use whitespace, then it should have the antenna. If the
slave wants to talk to an AP that's going to use the whitespace, there
should be a box for the AP in the diagram. If you want to say that the
master and the AP can be one device, still show two boxes but say they
can be in the same box. If the master is doing the querying and setting
up the whitespace and the "slave" is doing nothing with regard to
whitespace but simply using the master as an Internet gateway, then the
"slave" is not a slave.
5.1, item 1: Is this referring to the Internet connectivity between
the WS device and the database? If so, as above, does it necessarily
need to be an air interface?
___
Mancuso: This wasn't meant to imply air the exclusive interface --
Made this clearer by using "any" air interface used by devices;
further limited reference to messages betweein devices and db as
messages from master device to db (since, by definition, slave devices
don't communicate directly to db).
You missed one bit of what I was asking: Couldn't the interface between
the database and the master be wired, not air at all?
Requirements:
_____
P.1: "The master device may validate the database against a list of
approved databases maintained by a regulatory body." I don't
understand that as a protocol requirement. What is being required?
___
Mancuso: (Moved info up from Operation requirements per later
comment). Rephrased to clarify that the master device MUST identify a
db, and MAY discover or be pre-configured with db URIs, and MAY
validate db URIs against a list of approved databases maintained by a
regulatory body."
I don't think I explained my question well enough. So let me try it this
way. Here's what you currently have:
P.1 The master device MUST identify a database to which it can
register, make spectrum availability requests, etc.
That's not the requirement. Here you're just describing what the master
is going to do. So MUST isn't needed here. "will" is probably
sufficient. Next comes the requirement:
The master
device MAY select a database by discovery at run time or by means
of a pre-programmed URI address.
That's fine, but it doesn't make it clear that the discovery protocol is
a requirement. Shouldn't it say, "The protocol must support the
discovery of an appropriate database given a location provided by the
master device. The master device may select a database..."?
The master device MAY validate
discovered or configured database addresses against a list of
approved databases maintained by a regulatory body.
Here's my original confusion. I think this would be better as, "The
master device may validate discovered or configured database addresses
against a list of known databases (e.g., a list of databases approved by
a regulatory body)." That is, the requirement (and it's not a protocol
requirement) is that the master will have the ability to (optionally) do
the validation against a list. Where that list comes from, e.g., a
regulatory body, is not part of the requirement.
O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy
required by the database"?
_____
Stanforth: Acceptable Location Accuracy is defined by the regulator
and applied to the calculations of the database
_____
Resnick: So the database will tell the device what level of accuracy
is required?
_____
Mancuso: Clarified as follows: "Locations MUST be determined to the
accuracy required by the applicable regualtory domain." These are
operational requirements, and not part of the protocol. Accuracy is
verified by certification of devices by regulators.
Oh, I think that made it worse. If the regulators are determining the
accuracy and certifying the devices, this is not an operational
requirement; it's all going to be pre-configured. Is that what you mean?
O.4: Again, "regulatory body" seems unnecessary here. Substituting
"database" seems sufficient, since you'll be getting the rule set from
the database.
_____
Stanforth: General observation about this and the next couple of
comments. The FCC Certifies a radio and a database as a "system" Ofcom
is not considering a system. Other regulators may have other thoughts.
In the case of the FCC some of the function is validated/certified,
what ever you want to call it for the combination not as a function of
one or the other.
So while it seems logical to have an implementation within a database
it is not necessarily considered as such.
_____
Resnick: Again, I'm not understand your reply. Can you expand on what
you mean here?
_____
Mancuso: The statment here is regarding the rule set, which is from
the regulator, so the current phrasing seems OK.
I think we are talking past each other: How does the master device
determine the rule set? Is it getting it from the database? Is it
pre-configured? In any event, does the master device know that the rule
set came from the regulator? If not, then there's no need to mention the
regulator at all.
Note there are a significant number of device-only rule-set
requirements (complexity is to be expected), so the operational
requirement here is for the master to obtain "information." The
current expectation is that the db may communicate the name of the
applicable regulatory ruleset to the device, but not the specific
parameters.
But the master device is only dealing with the name of the rule set. It
doesn't have semantics to the master device. The master device DOES NOT
CARE that the rule set came from a regulator, or the manufacturer, or
from invaders from Mars. The concept of the regulator is irrelevant to
the operational requirement.
_____
O.5 (and O.9 through O.10 and O.12 through O.14): As above, you can
change "local regul8atory policy" to "the database rule set",
"determined by regulator policy" can be "enumerated in the database
rule set", etc.
____
Mancuso: A db can serve multiple regulatory domains, and hence,
rulesets. And note that the currently applicaple rule set may not come
from a local regulatory domain, but be imported from a foreign
regulator (e.g., Brazil decides to use FCC rules)
_____
Security Considerations
Section 8, generally: Same issue with "regulatory". See if there are
any that are more accurately "database rules".
____
Mancuso: Again, multiple rule sets may apply for a given regulatory
domain.
See above.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
