Replying to both Nancy and Peter. Trimming as I go:
On 1/23/13 3:33 PM, Nancy Bravin wrote:
I think since we are dealing with a protocol that can be used
globally, terms such as listed below, with definition, will make it
easier to those countries who are not English speaking, or the
translation to words, with no definition can be confusing. It is not a
deal breaker, but consideration for emerging countries that lack
experience in these areas. IMHO
Sorry, I think I wasn't clear enough. Other than "Protected Contour"
(which is not used anywhere), I was not suggesting having *no*
definition of the terms listed. I was just saying that if they only
occur once in the document, define them inline where they are used
instead of in the definitions section. But that's strictly an editorial
comment. Entirely up to you all whether you want to make a change.
On Jan 23, 2013, at 1:17 PM, Peter Stanforth wrote:
2.2: For "Device ID", it says, "that identifies the manufacturer, model
number, and serial number." Does the device ID have to identify that
information? Can it simply be unique?
Regulators are asking for manufacturer and model number as they may
require action, enforcement or denial by the DB on the set to
manufacturer devices or a specific model of device
I guess the question is: Are there any potential implementers of this
protocol (or potential regulatory bodies) that *don't* care about
manufacturer or model or etc.?
3.1.1 & 3.1.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.
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.
So are you saying we do or do not need the term "master" in these sections?
3.1.1, item 2: This says that the device will discover the database "in
the local regulatory domain". How does the device determine the "local
regulatory domain"? I suspect that the phrase "in the local regulatory
domain" is meaningless for purposes of this sentence. If it is not,
there's something that's not explained.
The location of a device determines it regulatory domain. However the
device may understand this or it may be told.
Right. That seems to indicate that the device that this section should
say, "for its current location" and not "in the local regulatory
domain". The device needs to know its location, but not its regulatory
domain.
For instance our current US implementation validates that a device is
within the regulatory domain. If not we deny it service but allowed
for the DB to tell the device who or what it should contact. In other
words you are now in Canada so you need to talk to xxx not to and FCC
DB. Taken together with the comment below this may need some thought
and additional work
I think we're on the same page.
3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in
2.2, it's only a slave for purposes of talking to the database. But
there is an implication in these sections that the slave device uses
the
master for internet connectivity. I don't think that's the intent, but
either way there's some clarification that's needed. Further confusing
me about this point is (a) the master device is always the one in the
diagrams with the antenna, but as far as I can tell, a master device
doesn't need an antenna, the slaves do; and (b) most of the links
marked
"Air" seem to me not to require an air interface, but could also be
wired. I could use some explanation.
The FCC, as an example, has two concepts of a slave. The first is a
client served by a master, think 802.11 client using a channel served
by an AP. This is the model for low power devices.
OK, but does the low power device actually ever request white space
spectrum? If not, then it is not involved in this protocol, right?
If the device is a high power device the slave must get it's own
channel list. It can use a master to do this, using white space
spectrum, if it has no other means of contacting the database.
This I understood until you said "using white space spectrum". It can't
use white space spectrum to talk to the master until it is allocated
spectrum by the database, can it? It talks to the master *not* using
white space spectrum, gets it's answer through the master about which
spectrum to use, and then stops talking to the master, correct?
3.2.1, item 7: Does the slave provide its location, device identifier,
and antenna height, the same way the master does when it queries? If so
(especially in the case of the master sub-allocating for the slaves),
doesn't the master have to provide the set of locations for all of the
slaves in step 5? Some further explanation might be in order.
As above a low power slave, under FCC rule, does not have to provide
any of this information but a high power slave does.
Does a low power slave talk to the database at all?
3.2.1, item 8: It says that the white space is allocated to slaves "for
communication over the network". That's not right is it? In this
scenario, the allocated white space could be used for network (I read
"Internet") communication *or anything else*, can't it?
High power again. A slave may not get the same channel list as the
master and may not be able to use the channel the master is currently
using so a negotiation will be necessary.
I'm not sure whether you agree or disagree with my point here. I don't
understand your reply.
4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply
"domain" be sufficient?
The regulatory domain is assumed to be similar to a country domain
but need not be. A database could be permitted to serve a different
definition. In the FCC case they currently limit the domain to the
12mile nautical limit and, as we speak databases are only permitted
to service the NE USA.
I don't think you answered my question.
O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy
required by the database"?
Acceptable Location Accuracy is defined by the regulator and applied
to the calculations of the database
So the database will tell the device what level of accuracy is required?
O.5: Again, "regulatory body" seems unnecessary here. Substituting
"database" seems sufficient, since you'll be getting the rule set from
the database.
So while it seems logical to have an implementation within a database
it is not necessarily considered as such.
Again, I'm not understand your reply. Can you expand on what you mean here?
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
