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,
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@xxxxxxxxxxxx> wrote:
At 05:24 01-02-2013, The IESG wrote:I read the draft. I am okay with whatever the working group decides.
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@xxxxxxxx mailing lists by 2013-02-15. Exceptionally, comments may be
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
_______________________________________________
paws mailing list
paws@xxxxxxxx
https://www.ietf.org/mailman/listinfo/paws