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
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.
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)).
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?
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.
-- 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".
-- Section 3.1 --
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".
-- 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.
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.
-- 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?
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.)
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.
-- Section 5 --
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".
In Figure 11, note that there could be multiple databases serving
white space devices.
There is no Figure 11. You mean 7?
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.
-- Section 5.1 --
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.
-- 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?
-- Section 6.1 --
The Data Model MUST support WGS84 (see NGA: DoD World Geodetic
System 1984 [3]).
I think this statement makes that reference normative.
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?
-- 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.)
-- 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".
-- Section 8 --
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?)
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.
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.
Threat 6: Expand "MiM".
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)"
-- Section 9 --
This section is entirely unnecessary, and you should remove it.
There's no need to repeat what you've already said.
Barry