I just posted version 11 of the PAWS Use Case & Requirements draft to IETF.
In this draft, I responded to several of the comments posted to the list; I
left a few TODOs, and am awaiting further comments for the next draft.
My notes are in preparing this version are set out below.
Tony Mancuso
***************
Tony Mancuso Notes - PAWS Use Case & Requirements Notes v. 11 (I
consolidated Pete Resnick's initial comments with other comments received
on selected points together with my responses)
Abstract: End of the first paragraph, perhaps add: "The IETF has undertaken
to develop a protocol for that management database."
___
Mancuso: Done
_____
Also add the above to 1.1.
1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the
database using a well-defined protocol."
_____
Mancuso: Done:
_____
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?
____
Stanforth: 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
_____
Resnick: 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.?
_____
Mancuso: Waiting for further comment.
_____
"Device Class" is only used once in section 5.1. No need for the definition
here.
"Location Based Service" is only used once in section 3. No need for the
definition here.
"Protected Entity" is only used once in section 4.1. No need for the
definition here.
"Protected Contour" is never used. No need for the definition at all.
"Radio Access Technology" is only used once in section 5.1. No need for the
definition here.
_____
Nancy Bravin: 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.
_____
Resnick: 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.
_____
Mancuso: Deleted Protected Contour, and moved the definition of single-use
terms into the text.
_____
3.1 This section (and its subsections) seems oddly placed. It is not use
cases, but general protocol services that cut across use cases. Perhaps 3.1
and 3.2 should be separate top-level sections?
---
Mancuso: Done. Moved Protocol Services to new top-level head (Section 3);
Use Cases now in new Section 4.
_____
3.1 "A complete protocol solution must enable all potential white space
services." That seems a bit absolute. How about "must enable many different
potential white space services"?
____
Mancuso: Done.
_____
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.
_____
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 the section
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 at this point makes sense. 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.
_______________
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.
_____
Stanforth: The location of a device determines it regulatory domain.
However the device may understand this or it may be told.
_____
Resnick: 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.
_____
Stanforth: 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.
_____
Resnick: I think we're on the same page.
_____
Mancuso: The intent of the existing wording is simply that the master sends
out a request and waits for a response, not to imply that it the device
query is constrained or qualified by the device's understanding of its
regulatory domain. I deleted the extra language to read as follows: "The
master device constructs and sends a service request over the Internet."
_______
3.1.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. Again, 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."
_____
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.
_____
Stanforth
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.
_____
Resnick: OK, but does the low power device actually ever request white
space spectrum? If not, then it is not involved in this protocol, right?
___
Stanforth: 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.
____
Resnick: 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?
____
Mancuso: Waiting for any further input.
_____
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.
_____
Stanforth: As above a low power slave, under FCC rule, does not have to
provide any of this information but a high power slave does.
_____
Resnick: Does a low power slave talk to the database at all?
_____
Mancuso: Waiting for any further input.
______
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?
_____
Stanforth: 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.
_____
Resnick: I'm not sure whether you agree or disagree with my point here. I
don't understand your reply.
_____
Mancuso: Waiting for any further input.
_____
3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it
be perfectly reasonable for communication between the master and slaves
continue on its original connection and that the white space is only used
for other communications the slave wishes to do?
_____
Stanforth: same as Iten 8, above.
____
Mancuso: TODO.
_____
3.2.2: This scenario was confusing to me because the master seems
completely unnecessary to the example. Please explain.
_____
Mancuso: TODO. The master is optionally used by the slave to query the db
for spectrum. And again, master only connotes ability to query the db
directly by the device. I do think we need to eliminate the implication
that the slave then connects to the Internet through the master (it uses
white space spectrum, right)?
_____
3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in
the example, since there are no slaves.
____
Mancuso: Again, master only connotes ability to query the db directly by
the device.
____
4: "Master" seems unnecessary to the example. Also, I suggest in the
second-to-last paragraph, you say "The databases are locale specific"
instead of "country specific", and delete the word "competing" from the
last sentence of that paragraph.
________
Mancuso: Same response re masters as above. Made the suggested wording
changes re "locale" and "competing."
_____
4.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: TODO
_____
4.1, item 3: Again I suggest changing "operate in any country" to "operate
in any locale" and change "country-specific" to "locale-specific". (The
other occurrence of "country" seems correct.)
____
Mancuso: Made suggested wording changes.
_____
4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply
"domain" be sufficient?
_____
Stanforth: 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.
_____
Resnick: I don't think you answered my question.
_____
Mancuso: I changed to "domain specific". Not that the db may not be
locale-based (a South American country may opt for FCC domain rules).
_____
5.1 and 5.2: I don't understand the distinction between "Normative" and
"Non-normative" requirements in this context. Isn't it sufficient that
you've separately labeled "Data Model Requirements", "Protocol
Requirements", and "Operational Requirements"?
_____
Mancuso: Agreed. Changed the heads and organization.
_____
Mancuso: Remaining items TODO.
_____
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?
P.5 and P.6: The requirement here is for *message-level* integrity and
encryption? That's OK, but I want to make sure that's what you mean.
P.8 and P.14: I don't think "result codes" and "response codes" are the
requirement here, are they? It sounds like the requirement is "indication
of success or failure".
P.15: I'm not clear on what this requirement means in practical terms. Some
more explanation seems in order.
P.16: Shouldn't this be combined with P.9?
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?
_____
O.3: This seems to indicate that database discovery will be out of band,
that the WG is not developing protocol to do so. Is that what you meant? If
not, this should be turned into a protocol requirement instead of an
operational requirement.
O.4: This requirement seems a bit overly obvious and silly to state as a
requirement. Why is it necessary to say that you need a connection?
O.5: 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?
_____
O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change
"local regulatory policy" to "the database rule set", "determined by
regulator policy" can be "enumerated in the database rule set", etc.
Section 7, generally: Same issue with "regulatory". See if there are any
that are more accurately "database rules".
Threat 7: This doesn't strike me as a security consideration per se. This
might make more sense incorporated into an operational requirement.
On Thu, Jan 24, 2013 at 3:19 PM, <[email protected]> wrote:
> Will wait for Tony to generate a new version by addressing the received
> comments, before issuing the Last Call.****
>
> ** **
>
> **- **Gabor****
>
> ** **
>
> *From:* [email protected] [mailto:[email protected]] *On Behalf
> Of *ext Pete Resnick
> *Sent:* Wednesday, January 23, 2013 2:59 PM
> *To:* Anthony Mancuso
>
> *Cc:* [email protected]
> *Subject:* Re: [paws] AD review of
> draft-ietf-paws-problem-stmt-usecases-rqmts-10****
>
> ** **
>
> Like I said, I'll await word from Brian and Gabor tomorrow for "go" or "no
> go" with the Last Call, even if there is no new draft ready to go. We can
> Last Call -10 if nobody thinks there's a strong reason to wait. I am fine
> with either path.
>
>
> pr
>
> On 1/23/13 4:54 PM, Anthony Mancuso wrote: ****
>
> I',m not sure I can turn around the doc by tomorrow since there are some
> technical points I need to collaborate on.****
>
> ** **
>
> On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <[email protected]>
> wrote:****
>
> I think if Tony can spin a rev before EOB tomorrow, we should do that, but
> I'm thinking that the current rev is good enough, and I'd prefer to get it
> into the Feb 7 telechat. ****
>
> ** **
>
> I don't feel very strongly about that, but…****
>
> ** **
>
> Brian****
>
> ** **
>
> On Jan 23, 2013, at 5:10 PM, Pete Resnick <[email protected]>
> wrote:****
>
> ** **
>
> One hitch: If you make the call by EOB tomorrow, I can get the Last
> Call sent out, which means (assuming the LC goes well) I can get it on the
> IESG telechat Feb 7. If we have to wait two additional weeks until the Feb
> 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to
> the Last Call by EOB tomorrow for me to sneak it on to the earlier telechat.
>
> pr
>
> On 1/23/13 4:04 PM, Anthony Mancuso wrote: ****
>
> Good suggestion Gabor. I will wait another day or so and then start on
> generating a new version in response to the comments and clarifications.**
> **
>
> ** **
>
> On Wed, Jan 23, 2013 at 1:55 PM, <[email protected]> wrote:****
>
> My suggestion would be, if Tony has the time and willingness, then
> generate a new version and try to address these comments, perhaps taking
> the clarifications from Peter (and any input from others if available until
> tomorrow) into consideration. ****
>
> Thanks, Gabor****
>
> ** **
>
>
>
> ****
>
> -- ****
>
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> <http://www.qualcomm.com/%7Epresnick/>****
>
> Qualcomm Technologies, Inc. - +1 (858)651-4478****
>
> _______________________________________________ ****
>
>
> paws mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/paws****
>
> ** **
>
> ** **
>
>
>
> ****
>
> -- ****
>
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> <http://www.qualcomm.com/~presnick/>****
>
> Qualcomm Technologies, Inc. - +1 (858)651-4478****
>
>
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
