Skip to main content

Last Call Review of draft-ietf-paws-protocol-12

Request Review of draft-ietf-paws-protocol
Requested revision No specific revision (document currently at 20)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-08-05
Requested 2014-07-03
Authors Vincent Chen , Subir Das , Lei Zhu , John Malyar , Pete McCann
I-D last updated 2014-07-15
Completed reviews Genart Last Call review of -14 by Robert Sparks (diff)
Genart Last Call review of -12 by Robert Sparks (diff)
Genart Telechat review of -14 by Robert Sparks (diff)
Secdir Last Call review of -12 by Catherine Meadows (diff)
Secdir Last Call review of -14 by Catherine Meadows (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-paws-protocol by General Area Review Team (Gen-ART) Assigned
Reviewed revision 12 (document currently at 20)
Result Not ready
Completed 2014-07-15
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-paws-protocol-12
Reviewer: Robert Sparks
Review Date: 3 July, 2014
IETF LC End Date: 7 July, 2014
IESG Telechat date: 10 July, 2014

Summary: This document is not ready for publication as a Proposed Standard.

I apologize in advance if I've missed where one of the questions below
is already answered. There's a lot to take in here.

Major Issues

- The document says it "describes" the use of HTTP/TLS as the transport
for the protocol. Was it the intent to allow others? If not, the
language should be firmed up.

- The document still says "TBD Define message format" in the section on
Listing Servers. I understand from reading the list that what the
document is going to say about Listing Servers is going to change (to
not include how you talk to them?). This change needs to be finished
before the document can be reviewed for completeness.

- It's not clear when a server should use the HTTP level redirection
discussed in section 7 vs the databaseChange mechanism in the protocol's
responses. There should be some discussion about what the Device should
do when the databaseChange mechanism results in a redirect loop.

- The document needs to be clear where the primitive types (like string,
float, and integer) in the UML-ish diagrams in section 4 are defined.
I'm guessing from context that you're assuming the definitions in
RFC4627. If that's true, there are several places that you talk about
string where your text should change. RFC4627 says string is UNICODE,
and may be encoded many ways (see section 3 of that document). If your
intent is to restrict all strings to UTF-8 encoding say that, and adjust
the text you currently have that mentions UTF-8. (The various places
where you say a string MAY contain UTF-8 do not make sense - if you're
assuming the encoding is UTF-8 and trying to reinforce that there may be
non-ASCII range UTF-8 here, say that explicitly). There are other
related phrases that don't make sense such as where you say things like
"The length of the string MUST NOT exceed 64 US-ASCII characters."

- The descriptions of messages in section 4 all contain *other:any. None
of those are reflected in the concrete schema of section 6. Should they be?

- The INIT_RESP description requires one or more RulesetInfo objects.
What is a database supposed to do if it has no rulesets to return
(possibly because it doesn't have anything overlapping with the list of
ruleset IDs listed in the DeviceDescriptor in the INIT_REQ.). Should
this have been 0..* (along with the corresponding change to the text),
or is there an Error that the database should return when this happens.
If the latter, it would be good to call it out in 4.2.2.

- Section 4.4 talks about returning OUTSIDE_COVERAGE when the location
specified in the request is outside the regulatory domain (could that be
domains?) supported by the database. The sections on init and
registration (4.2 and 4.3) don't have this discussion. Should they?

- A databaseChange (at least as described in 4.4) can provide one or
more alternate database URIs, affecting the Device's configuration. When
there's more than one, is there any preference to what order the Device
should try to use them in? Is there any expectation that they will give
the same answers to a given request? If not, do you want to say anything
about discouraging devices from asking all the databases it knows about
to find an answer it likes best?

- If the requirements to act as if there is no available whitespace when
you can't reach a Listing Server remain in the document, the security
considerations should call out that any attack that would prevent
reaching a Listing Server would result in all devices relying on that
Listing Server ceasing their use of any whitespace.

- Please check the description of 'timeRange' in section 5.9
(SpectrumSpec). I think you meant to say "in which there is _NO_
available spectrum".

- The definition of SpectrumProfile (section 5.12) needs clarification.
Is this allowed?
   "profiles" : [
     {"hz": 5.18e8, "dbm": 30.0 },
     {"hz": 5.24e8, "dbm": 37.0 }
If so, what does it mean? Do I do linear interpolation between points
(33.5 dbm (~2.25 watts) at 521Mhz)?
Similarly, does this specify a ramp up and then back down? (shaped like
a ^)?
     {"hz": 5.18e8, "dbm": 30.0 },
     {"hz": 5.21e8, "dbm": 33.5 },
     {"hz": 5.24e8, "dbm": 30.0 }
If not, what text disallows it?

- You are using the schema language defined in draft-zyp-json-schema to
define your message format. That makes it a normative reference. The
draft is expired - are there plans to progress it?

- Something needs to talk about case-sensitivity of the various protocol
elements. JSON-RPC says that member names are case sensitive and is
otherwise silent. The string "sensitive" doesn't appear in RFC4627. So,
you have an example that says "authority":"us". Is that the same as
"authority":"US", and where does the spec answer that question? My read
of JSON-RPC says that "authority":"us" and "Authority":"us" are _not_
the same thing, and that the second would not be a recognized property
of a RulesetInfo object.

Minor Issues

- I'm not finding where you define the protocol version. I see "1.0" in
the json examples in section 6. Where is it specified? Within a given
method, the only extension point I find other than changing the protocol
version is the *other concept in messages, which MUST be ignored when
either side doesn't understand them. So there should be some discussion
about what kind of change would require the protocol version number to
change. Suppose you wanted to allow batching requests from several
slaves into one request to the database (similar to
AVAIL_SPECTRUM_BATCH_REQ but allowing a list of DeviceDescriptors
perhaps). Does this require a new protocol version, or is it just a new
request type in this version? If you think it's a new request-type,
should there be a request and response type and/or method registry?  And
yes, I see how you could do this with JSON-RPC batch, but if that's
where you'd send this idea, why didn't you do AVAIL_SPECTRUM_BATCH_REQ
that way? (Possibly related: I can't figure out what "The initialization
message also represents extension points for database implementations or
rulesets that require the explicit handshake." is trying to say. Can you
rephrase that more simply?)

- It's not clear what it means to "support" a ruleset. I infer that this
means that the device has code that implements what's required by the
name. Can you state that explicitly? Does a Master device have to have
this code? Could it simply be a box that only serves to answer requests
from Slave devices? If so, why does it care what the rulesets actually
are. If a slave can ask and a database can answer, should a master just
shovel the bits, or is there a requirement that the master device be
configured to handle a ruleset before a slave can ask about it?

- In the last paragraph of section 4.1 (before 4.1.1 starts), "If the
Device is already operating" assumes that the device could only be
operating if it had previously contacted some database. The problem is
that the device was able to reach a database at one point and now it
can't reach any.  It would read more clearly if you said that explicitly.

- Please point somewhere for a definition of the terms 'uncertainty' and
'confidence' (I suggest draft-ietf-geopriv-uncertainty). The GEOPRIV
working group has gone through many iterations of disagreement about
what these terms mean and how they should be used. For a taste, skim
some of
If you don't point to a hard definition, your implementation community
will have to go through the same arguments.

- Should the security considerations section talk about the risk of
collisions in serialNumber (since it is the only required element in
DeviceDescriptor, and isn't a particularly secret thing)? Is there any
harm at the database if two devices innocently end up sending the same
serial number (without providing any of the optional information that
would otherwise disambiguate the devices)? Can a device learn anything
useful about another device by spoofing it? Is it possible that in some
regulatory realm, some devices would get more access than others,
encouraging devices to ask about what their competition gets to do? Can
harm be done by a device sending SPECTRUM_USE_NOTIFY messages claiming
to be some other serial number (and perhaps manufacturer) maliciously? I
think this needs more discussion than what RFC6953 contains.

- The use of the "id" parameter from JSON-RPC deserves more discussion.
The JSON-RPC spec allows it to be string, numeric (without a fractional
part), NULL or missing. You've chosen to require it (since you're not
using json-rpc notifications), and not allowing numeric values (why?).
Are you making any other assumptions about what it should contain? I
think you're assuming a level of uniqueness that would let you use the
Batch mechanism in section 6 of JSON-RPC (otherwise, the HTTP
request/response context is enough to associate the request and response
and the id might as well be constant).

- Section 7 says a server can reject a GET with a 404 - wouldn't that
have consequences for a later POST? Why wouldn't it use a 405?

- The draft calls for the creation of a special list for review requests
for the IANA assignments. This may be ok (mailing lists are easy to set
up), but is there not an existing list that would serve the purpose just
as well?


- RFC 2616 has been obsoleted - the references should be updated.

- It would help to have an example of a ruleset in the definition in the
Terminology section and perhaps for that definition to more strongly
convey that it is a name in a namespace, and what that rule means is
elsewhere.  (Right now the definition says that the ruleset is the
actual set of rules, not a name, and it made reading the protocol
overview much harder than it needed to be). At the very least, pointing
to the examples in section 9 early would help.

- Is the document loosely borrowing UML, or are the diagrams used in
section 4 of a format formally defined in some other RFC? A pointer to a
definition of the format, or a brief description noting it's based on
UML along with where the base types are defined would be useful.

- "One approach to manage spectrum sharing" is awkward. Would "One
approach to managing spectrum sharing" or "One approach to the
management of spectrum sharing" work?

- There are several instances of "The Device needs to use the
information to update its list". Consider clarifying 'needs to'. Should
this have been MUST?

- "The vertices MUST be defined in a counter-clockwise direction"
assumes you are looking at them from above - please be explicit.

- Section 9.1.2's first paragraph should say "FCC and ETSI" the same way
9.2.2 does. You could generalize that to "any particular set of