IESG members (and PAWS list),
Below are the Last Call comments and my responses, which I am using to
generate v. 13 of the PAWS Use Cases & Requirements Draft. I expect to post
v. 13 soon, perhaps this Friday morning. Please follow up as soon as you
can with any further comments.
I list Pete Resnick's and Peter Stanforth's comments and my responses
first, followed by Barry Leila's, then SM's. Note: Some sections are
affected by multiple comments so you may need to read all the comments and
responses to a section to understand the final effect of all comments on a
section.
I apologize that some of the section references may be difficult to
coordinate with the last (and next) posted version of the doc since I did
some reorganizing (partially in response to these comments). I did my best
to show the new section numbers in my responses.
Thanks for all your comments. They greatly helped in clarifying this
material and tying it to an extensible protocol to access whitespace.
Tony Mancuso
*********************
Pete Resnick's comments:
Abstract
End of the first paragraph, perhaps add: "The IETF has undertaken to
develop a protocol for that management database."
___
Mancuso: For purposes of the abstract, I think this IETF doc speaks to the
our efforts to develop the protocol (but I added this sentence in the
Intro).
_____
Introduction
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.
-- Deleted reference in abstract. Changed last Intro paragraph as
suggested. Also moved the problem statement section up (as described in the
text, it should follow the Introduction and precede the Use Cases section.
Also moved the discussions of protocol services into the problem statement
(there were two db features mentioned and one (db discovery) was
duplicative of an existing section in the existing Problem Statement
section.
_____
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 referring 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.
-- This doc as originally written had a lot of extra wording (which we have
been working to prune and clarify). This section is an example of such
extra wording that needs trimming. I simplified this section to limit the
discussion to discovery. However, I still wonder why you say that a
high-power slave can establish a white-space network since, by our
definition, it can't query the database for available white space spectrum.
I think perhaps you are referring to a high-power portable device acting as
a master device, but I'm not sure.
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.
-- Removed references to regulatory domain and simplified the steps to
eliminate unnecessary discussion of regulatory requirements.
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 its 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.
-- Yes, the slave needs an antenna. I think the terms "master" and "slave"
(as we define them) were muddying the illustration. I changed the
illustration and text to clarify that the portable device here is using
white space to offload video streaming from a metered Internet service to
an unmetered AP Internet service (the portable device talks to the AP over
whitespace).
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 between 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?
--- Rephrased to be more explicit: "Interface agnostic - An interface
between a master white space device and database can be wired or unwired
(e.g., a radio/air interface technology such as IEEE 802.11af, IEEE
802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc.) However, the messaging
interface between a master white space device and the database should be
agnostic to the interface used for such messaging while being cognizant of
the characteristics of the interface technology and the need to include any
relevant attributes in the query to the database."
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.
-- Made the suggested wording changes.
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 regulatory 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?
-- Restated to: "A master device MUST be able to determine its location
including uncertainty and confidence level. A fixed master device MAY use a
location programmed at installation or be configured to determine its
location to the accuracy required by the applicable regulatory domain."
These seems like a valid operational requirement for devices that use the
protocol.
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" OFCOMis 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 statement 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.
-- The best I could do here, given the range of responses a db may
communicate to a device regarding a rule set (the name of the rule set, a
more detailed list of all parameters in a rule set, etc.) is "The master
device MUST be configured to understand the requirements of the rule set of
the regulatory body that apply to its operation at its location."
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 rule set 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.
-- Yes, but humans (perhaps invading Martians, someday?) will read this doc
--- the qualification to the rule set described here "rule set of the
regulatory body" is only meant to explain what rule set we are talking
about. Just mentioning "rule set" seems incomplete and ambiguous.
_____
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, rule sets.
And note that the currently applicable 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.
I agree with the request to pare down the references to regulatory domain.
Further, a lot of the "requirements" in this section either are not
requirements, strictly speaking, or restated protocol requirements. Hence,
I pared down this section significantly to state as simply as possible what
a device and db must minimally do to operate in white space.
****************
Barry Leila's comments:
Some Last Call comments, in advance of IESG Evaluation:
-- General --
It's completely a non-starter that there's no email address for
Anthony Mancuso; this has to be added. He won't get any of the IESG
Evaluation messages this way, and the RFC Editor won't be able to
contact him during the publication process.
___
Fixed this. Added email and other author (editor) information.
_________
The first and third references need to be in RFC reference form, and
not simply as URIs. They should look something like this:
[1] V. Chen, S. Das, Z. Lei, J. Malyar, P. McCann, "Protocol to
Access Spectrum Database", draft-ietf-paws-protocol-01 (work in
progress), December 2012
[3] National Imagery and Mapping Agency, "Department of Defense
World Geodetic System 1984, Its Definition and Relationships with
Local Geodetic Systems", NIMA TR8350.2 Third Edition Amendment 1,
January 2000,
<http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html>
For the second reference: the RFC Editor will not generally accept
Wikipedia as a reference, because its contents are unstable. Perhaps
you could use something like <http://fcc.gov/oet/cognitiveradio/>
instead?
____
TODO(amancuso): I'm working on these cites. I am still figuring out how to
do this in xxe.
I'll return to this after I respond to all the other last call comments.
-----
Just an alert: the RFC Editor will probably add hyphens when "white
space" is used as an adjective, as in "white-space spectrum". This is
particularly notable when you have "non-white space spectrum", which
looks like space that is non-white (as opposed to "non-white-space
spectrum"). You may feel free to wait for them to do that. Or you
can do it.
-----
added hyphens to "white-space" and "non-white-space" throughout.
-----
Abstract
Abstracts should not contain citations, so the "[1]" citation should
be removed. But perhaps more to the point, the Abstract is too long;
the first paragraph can be trimmed after the second sentence (clipping
everything beginning with "An obvious requirement", which doesn't need
to be in the abstract (but should be and is in the Introduction)).
-----
Removed cite. Trimmed down the abstract.
____
-- Section 1.1 --
The first paragraph seems overlong, and could do with splitting.
Perhaps start a new paragraph with "An obvious requirement", and then
another with "Academia and industry".
-----
Done.
_____
-- Section 3.1 -- (old section 3 moved into new section 3 subsections)
It looks like a lot of stuff in these earlier sections used to have
2119 language, and got Peted. You missed one: the "MUST" in the
second sentence should be "must".
---
Done.
_____
-- Section 3.2 --
Does Figure 1 actually show anything useful or interesting? It says
it illustrates a registration requirement, but I don't see it.
-----
Agreed. Deleted figure and renumbered successive figures.
____
I'd say that "most current and up-to-date information" is redundant
(this also shows up in 6.3). And anyway, step 1 isn't a step -- you
don't *do* anything there.
-----
N/A. Refers to deleted language.
-----
-- Section 4.1 --
Figure 2 (Figure 2) depicts the general architecture such a simple
master-slave network
You're missing an "of". And is there a reason for "Figure 2 (Figure
2)" (and with other figures) that I don't understand?
----
fixed "of"; Deleted extra figure names throughout.
-----
Bullet 3: There is no Section 4.1.1 to see.
Bullet 4: It's not really optional (which implies that it's at the
option of the master). It's required if the database requires it, but
not all databases require it. Can you re-word? (And there is no
Section 4.1.2, either.)
----
Subsection numbering was changed in last iterations of the doc.
Clarification: the db doesn't require registration -- the rules set of the
regulatory domain that applies to the device may. The db may notify the
device of the rule set name that applies to it. To avoid listing protocol
requirements here, though, I generalized the language differently, and
simply said that the device "may" register. This section is not meant to
define the required protocol steps, just common ones in a communication
exchange between the device and the db.
Bullet 5: The part beginning "Note that" is out of place here, but
that's OK, because it's repeated where it belongs, in bullet 6. I
suggest you just remove it from here.
----
Removed the redundant part covered in item 6 but kept the part that
mentions that a item 5 (spectrum availability request) may be made by the
master on behalf of a slave device.
-- Section 5 (now Section 3)--
The databases may be regulatory specific
since the available spectrum and regulations may vary, but the
fundamental operation of the protocol should be regulatory
independent.
Is "should be" appropriate? I should think "has to be".
-----
I rephrased to clarify the point trying be made here in relation to the
regulatory agnostic protocol steps: "While databases are expected to
support the rule set(s) of one or more regulatory domains, and the
regulations and available spectrum associated with each rule set may vary,
the fundamental operation of the protocol should be regulatory independent."
In Figure 11, note that there could be multiple databases serving
white space devices.
There is no Figure 11. You mean 7?
-----
fixed figure numbering
-----
The databases are locale specific since the
regulations and available spectrum may vary.
I think you mean "location-specific"; in the App world "locale" has a
particular meaning that I don't think you mean (in other words, this
is not an issue of local language). This applies to the use of
"locale" elsewhere in the document as well.
----
Deleted this sentence since it was peripheral to the main point about
multiple dbs. But I do agree that "locale" is an overloaded term, and
"location" is more appropriate. I changed "locale" to "location" throughout.
-- Section 5.1 --
Bullet 1 says "Radio/air interface agnostic", but seems to be talking
about the messaging between the master and the DB, which will not
necessarily be over an air interface. Please re-word this bullet,
being careful to make the distinction between white-space usage (which
will of course be over the air) and DB access (which could be over any
network interface).
----
this language was updated in response to earlier comments, and now makes it
clear that master-db connection nor constrained to air interfaces.
-----
Bullet 3 confuses me. First it says that it's possible for the device
to know what rules are applicable, because it knows its location.
Then it says to note that even though it knows its location, it may
not be able to know what rule set to use. Is that not contradictory,
or am I misunderstanding? Then it gives an important requirement
that's buried at the end.
I suggest putting the requirement earlier, and then following it with
the extended explanation of the need for it.
----
deleted extra wording that clouded the main (and general) point that the
protocol must support the communication of domain-specific rule set
information to devices: "To allow the global use of white space devices in
different countries (whatever the regulatory domain), the protocol should
support the database communicating applicable regulatory rule set
information to the white space device.."
-- Section 5.2 --
The device needs to
determine the location of the specific database to which it can send
queries in addition to registering itself for operation and using the
available spectrum.
I'm having a lot of trouble parsing this sentence, and I'm still not
sure I understand what it means. Can you try rephrasing it?
--
reworded (and renumbered) section 3.2 limits the discussion to db discovery
and explains the steps that can be taken to do this.
-----
-- Section 6.1 -- (new section 5)
The Data Model MUST support WGS84 (see NGA: DoD World Geodetic
System 1984 [3]).
I think this statement makes that reference normative.
----
I think you mean the cite should be to an RFC.
TODO(amancuso): Update the cite.
D.3 The Data Model MUST support device description data that
identifies a device (serial number, certification IDs, etc.)
and describes device characteristics, such as or device class
(fixed, mobile, portable, indoor, outdoor, etc.), Radio Access
Technology (RAT), etc.
Is the "or" in there a stray, or is there something else wrong?
-----
deleted stray "or"
-----
-- Section 6.2 --
P.9 The protocol MUST support an available spectrum request from the
master device to the database. These parameters MAY include any
of the parameters and attributes required to be supported in the
Data Model Requirements.
"These parameters" implies that you've mentioned parameters before,
but you haven't. What parameters? (Same comment for P.10 and P.11.)
----
the parameters referred to here are those listed as required data items in
the preceding data model section. I reworded to clarify, as follows: "The
protocol MUST support an available spectrum request from the master device
to the database, which may include one or more of the data items listed in
[xref to Data Model section]."
Added the same trailing clause to p. 10 & 11.
-----
-- Section 6.3 --
O.5 The master device MAY register with the database according to
local regulatory policy.
As above: this is not a correct use of MAY, because it's not at the
option of the master device. In fact, as you say later in this
requirement, it MUST register when it's required to. Please re-word
this.
(O.6)
Parameters provided to the database
MAY include device location, accuracy of the location
Again... are these parameters provided purely at the option of the
requestor (in which case "MAY" is fine), or are they provided because
they're required by the database (in which case "MAY" is not right)?
O.8 According to local regulator policy, a master device MAY inform
the database of the actual frequency usage
O.10 According to local regulatory policy, the master device MAY
query the database with parameters received from the slave device.
More of the same about the "MAY".
---
entire section reorganized and simplified in response t earlier comments to
eliminate material duplicative of protocol requirements and to delete
unnecessary references to regulatory domains.
----
-- Section 8 -- (now Section 7)
It is assumed that both the master device and the white space
database have NOT been compromised from a security standpoint.
Threat 1: User modifies a device to masquerade as another valid
certified device
Here's how I read these two adjacent paragraphs: (1) It is assumed
that the device is not compromised; (2) Threat 1: A user compromises
the device.
Am I completely misunderstanding? (I also find the explanation below
that to be convoluted. Can you work on it, and try to un-convolute
it?)
---
I reorganized the sentences to make the basic point the attackers can
eavesdrop on communication channels between master device and db. I deleted
the confusing statement that seemed to claim that the network was
uncompromisable.
A master device MAY
need to identify itself to the database and be authorized to
obtain information about available spectrum.
Totally wrong "MAY"; make it "might". Remember that "MAY" means that
something is entirely optional. "MAY need to" is pretty much always
wrong.
---
Simplified the wording to make the basic point that device id information
can be captured and reused by an attacker. Removed "permissive" wording.
_____
Threat 4:
The available spectrum
information or transmit power allowed type of parameters
carried in the response could be modified by the attacker
resulting in the master device using spectrum that is not
available at a location or transmitting at a greater power
level than allowed resulting in interference to the primary
user of that spectrum.
That's quite a sentence. Please unravel it and re-word.
-----
rephrased
-----
Threat 6: Expand "MiM".
---
rephrased
-----
The security requirements arising from the above threats are captured
in the requirements of Section 6.1 (Section 6.1).
There's that duplication again: "Section 6.1 (Section 6.1)"
---
fixed xref
---
-- Section 9 --
This section is entirely unnecessary, and you should remove it.
There's no need to repeat what you've already said.
-----
Agreed. Deleted section
-----
*****************
SM's comments:
I read the draft. I am okay with whatever the working group decides.
In Section 1.1:
"Academia and Industry have studied multiple cognitive radio [2]
mechanisms for use in such a scenario."
The reference seemed odd. It took me some time to understand that it was
put in to address a comment. However, the first (external) reference that
defines that is a 404.
TODO(amancuso): fix link
There are two occurrences of the RFC 2119 boilerplate in the draft.
-----
I think the MUST below is one of the two boilerplate words you had a
comment on. Is there another?
-----
In Section 3.1: (new 3.2)
"Before the master device can transmit in white space spectrum, it MUST
obtain the address of a trusted white space database, which it will
query for available white space spectrum."
Why is this a MUST?
---
In response to earlier comments, this section was reworded and "MUST"
changed to "must". I assume this is what you were questioning.
----
In Section 4.2:
"A simplified operation scenario of offloading content, such as video
stream, from the a metered Internet connection to the a WS connection
consists of the following steps:"
What is a metered Internet connection?
----
Usage is monitored (metered) and paid for. I rephrased to clarify: "more
congested or costly Internet connection, such as a metered
(fee-based-on-usage) wire, wireless, or satellite service."
In Section 4.4:
"To set up a replacement network, spectrum needs to be quickly
cleared and reallocated to the crisis response organization."
Is that what P.15 is about? BTW, O.17 uses a "should" for this.
---
cleaned up protocol and operational requirements in response to earlier
comments. This is a good example of a use case, but didn't fit comfortably
as a P or O requirement, and was deleted from requirements sections.
In Section 6.2: (Section 6 is now Section 5)
"P.3 The protocol MUST provide the ability for the database to
authenticate the master device."
"P.5 The messages sent by the master device to the database and the
messages sent by the database to the master device MUST support
integrity protection."
"P.6 The protocol MUST provide the capability for messages sent by
the master device and database to be encrypted."
This sounds like the usual IETF security stuff.
-----
The protocol requirements were written to tie in with the primary PAWS
messages that are needed.
-----
"P.8 The protocol MUST support a registration acknowledgement
indicating the success of failure of the master device
registration."
The "success of failure" might need fixing.
---
changed to "success or failure"
----
"P.14 The protocol MUST support a validation response from the
database to the master to indicate if the slave device is
validated by the WSDB. The validation response MUST indicate the
success or failure of the validation request."
What is WSDB?
---
White Space Database (used to be defined in terminology). Changed it simply
to "database".
In Section 6.3: (entire section simplified in response to other comments)
"O.1 The database and the master device MUST be connected to the
Internet."
What is the Internet?
----
This is a rather large container of worms. We kicked it around for about a
half-hour and concluded that since this doc is for the Internet Engineering
Task Force, most readers will understand (and forgive). Nonetheless, this
is a good point, so I generalized it as follows (while retaining the
commonly used (and loosely-understood) term: "The database and the master
device MUST be connected (e.g., through the Internet)."
"O.2 A master device MUST be able to determine its location including
uncertainty and confidence level."
Does the working group plan to build its deliverables upon the GEOPRIV
work?
----
This section only intends to state the general requirement. It is my
understanding that the current draft of the protocol specification
specifies JSON encoding of location parameters that is compatible with
GEOPRIV.
---
I found the draft easy to read. The draft goes into extraneous details in
some parts. As an off-topic comment I see that the working group had the
usual JSON versus XML discussion [1]. :-) I understood the concept of
white spaces as discussed in the draft. If I understood correctly the
usage of database is related to the data model in Section 6. On seeing
Figure 7 it seemed to me that what was missing is an architecture document
which provides a high-level view of how all this is supposed to work. I am
not suggesting a reorganization of the draft as it may end up as too much
work. The draft attempts to convince the reader about the importance of
white spaces and its use cases. It's basically about database queries.
----
The use cases, the focus of this doc, attempt to show the high-level
architecture and provide a description of typical (and simplified) white
space master/slave networks and their relationship to the white space
database. Database queries are a critical and necessary step in
establishing a white space network (i.e., to obtain an available spectrum
list).
--------------
Regards,
-sm
***************************
end of Last Call comments.
On Mon, Feb 4, 2013 at 9:18 AM, SM <sm(_at_)resistor(_dot_)net> wrote:
At 05:24 01-02-2013, The IESG wrote:
The IESG has received a request from the Protocol to Access WS database
WG (paws) to consider the following document:
- 'Protocol to Access White Space (PAWS) Database: Use Cases and
Requirements'
<draft-ietf-paws-problem-stmt-**usecases-rqmts-12.txt> as Informational
RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-02-15. Exceptionally,
comments may be
I read the draft. I am okay with whatever the working group decides.
In Section 1.1:
"Academia and Industry have studied multiple cognitive radio [2]
mechanisms for use in such a scenario."
The reference seemed odd. It took me some time to understand that it was
put in to address a comment. However, the first (external) reference that
defines that is a 404.
There are two occurrences of the RFC 2119 boilerplate in the draft.
In Section 3.1:
"Before the master device can transmit in white space spectrum, it MUST
obtain the address of a trusted white space database, which it will
query for available white space spectrum."
Why is this a MUST?
In Section 4.2:
"A simplified operation scenario of offloading content, such as video
stream, from the a metered Internet connection to the a WS connection
consists of the following steps:"
What is a metered Internet connection?
In Section 4.4:
"To set up a replacement network, spectrum needs to be quickly
cleared and reallocated to the crisis response organization."
Is that what P.15 is about? BTW, O.17 uses a "should" for this.
In Section 6.2:
"P.3 The protocol MUST provide the ability for the database to
authenticate the master device."
"P.5 The messages sent by the master device to the database and the
messages sent by the database to the master device MUST support
integrity protection."
"P.6 The protocol MUST provide the capability for messages sent by
the master device and database to be encrypted."
This sounds like the usual IETF security stuff.
"P.8 The protocol MUST support a registration acknowledgement
indicating the success of failure of the master device
registration."
The "success of failure" might need fixing.
"P.14 The protocol MUST support a validation response from the
database to the master to indicate if the slave device is
validated by the WSDB. The validation response MUST indicate the
success or failure of the validation request."
What is WSDB?
In Section 6.3:
"O.1 The database and the master device MUST be connected to the
Internet."
What is the Internet?
"O.2 A master device MUST be able to determine its location including
uncertainty and confidence level."
Does the working group plan to build its deliverables upon the GEOPRIV
work?
I found the draft easy to read. The draft goes into extraneous details in
some parts. As an off-topic comment I see that the working group had the
usual JSON versus XML discussion [1]. :-) I understood the concept of
white spaces as discussed in the draft. If I understood correctly the
usage of database is related to the data model in Section 6. On seeing
Figure 7 it seemed to me that what was missing is an architecture document
which provides a high-level view of how all this is supposed to work. I am
not suggesting a reorganization of the draft as it may end up as too much
work. The draft attempts to convince the reader about the importance of
white spaces and its use cases. It's basically about database queries.
Regards,
-sm
1. http://www.ietf.org/mail-**archive/web/apps-discuss/**
current/msg07261.html<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07261.html>
______________________________**_________________
paws mailing list
paws(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/**listinfo/paws<https://www.ietf.org/mailman/listinfo/paws>