At long last, I got through my AD review of
draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say that
this draft is very much improved. The comments I have below are not (as
far as I can tell) showstoppers. I have not had a chance to go through
all of the commentary in Anthony's note from last week yet; I wanted to
get this out ASAP, so if there are things in the note that answer some
of my comments below, let me know.
Now: Don't Panic! As I said, none of the issues are showstoppers. But
the list is long. I am willing to take direction from the chairs on
this: I'll wait at least until tomorrow to issue the IETF wide Last
Call. If upon reviewing these, the WG thinks, "Gee, if Pete didn't get
the point there, perhaps we should fix the document before issuing the
Last Call", let me know that and I'll hold off for a bit. But if you
think all of these issues can be handled easily along with the rest of
the Last Call comments, I'll go ahead and issue the Last Call and you
can put these into your queue along with any new comments received.
So, here are the comments. If you can have a look in the next 24 hours,
that would be great.
------
Abstract: End of the first paragraph, perhaps add: "The IETF has
undertaken to develop a protocol for that management database."
Also add the above to 1.1.
1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with
the database using a well-defined protocol."
2.2: For "Device ID", it says, "that identifies the manufacturer, model
number, and serial number." Does the device ID have to identify that
information? Can it simply be unique?
"Device Class" is only used once in section 5.1. No need for the
definition here.
"Location Based Service" is only used once in section 3. No need for the
definition here.
"Protected Entity" is only used once in section 4.1. No need for the
definition here.
"Protected Contour" is never used. No need for the definition at all.
"Radio Access Technology" is only used once in section 5.1. No need for
the definition here.
3.1 This section (and its subsections) seems oddly placed. It is not use
cases, but general protocol services that cut across use cases. Perhaps
3.1 and 3.2 should be separate top-level sections?
3.1 "A complete protocol solution must enable all potential white space
services." That seems a bit absolute. How about "must enable many
different potential white space services"?
3.1.1 & 3.1.2: Throughout this section, there's no need to use the term
"master". These services exist whether a device is acting as a master
for other devices or whether it is acting on its own. Given that there's
been no discussion of slave devices yet (that happens in 3.2), I found
the use of the term "master" confusing in these sections. (I suppose you
could expand the definition of master in 2.2 to explain that it could
refer to a device acting on its own with no slaves, but I still think
that might be confusing.
3.1.1, item 2: This says that the device will discover the database "in
the local regulatory domain". How does the device determine the "local
regulatory domain"? I suspect that the phrase "in the local regulatory
domain" is meaningless for purposes of this sentence. If it is not,
there's something that's not explained.
3.1.2: Similar questions regarding regulatory domains. For example, "2.
To register with the database, the master device sends the database the
registration information required under regulatory rules." How does the
device determine which regulatory rules it is under and therefore which
information to send to the database. If the answer is, "It queries the
database", then it is not the regulatory rules the device cares about;
it is the information the database is configured to ask for (which will
presumably be in accordance to some regulations, but are out of band of
any protocol work). If the answer is, "It is pre-configured in the
device", then the regulatory rules are again out of band. Either way,
mention of them would be unnecessary.
3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in
2.2, it's only a slave for purposes of talking to the database. But
there is an implication in these sections that the slave device uses the
master for internet connectivity. I don't think that's the intent, but
either way there's some clarification that's needed. Further confusing
me about this point is (a) the master device is always the one in the
diagrams with the antenna, but as far as I can tell, a master device
doesn't need an antenna, the slaves do; and (b) most of the links marked
"Air" seem to me not to require an air interface, but could also be
wired. I could use some explanation.
3.2.1, item 7: Does the slave provide its location, device identifier,
and antenna height, the same way the master does when it queries? If so
(especially in the case of the master sub-allocating for the slaves),
doesn't the master have to provide the set of locations for all of the
slaves in step 5? Some further explanation might be in order.
3.2.1, item 8: It says that the white space is allocated to slaves "for
communication over the network". That's not right is it? In this
scenario, the allocated white space could be used for network (I read
"Internet") communication *or anything else*, can't it?
3.2.1, item 9: Is this an important part of the scenario? Why wouldn't
it be perfectly reasonable for communication between the master and
slaves continue on its original connection and that the white space is
only used for other communications the slave wishes to do?
3.2.2: This scenario was confusing to me because the master seems
completely unnecessary to the example. Please explain.
3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary
in the example, since there are no slaves.
4: "Master" seems unnecessary to the example. Also, I suggest in the
second-to-last paragraph, you say "The databases are locale specific"
instead of "country specific", and delete the word "competing" from the
last sentence of that paragraph.
4.1, item 1: Is this referring to the Internet connectivity between the
WS device and the database? If so, as above, does it necessarily need to
be an air interface?
4.1, item 3: Again I suggest changing "operate in any country" to
"operate in any locale" and change "country-specific" to
"locale-specific". (The other occurrence of "country" seems correct.)
4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply
"domain" be sufficient?
5.1 and 5.2: I don't understand the distinction between "Normative" and
"Non-normative" requirements in this context. Isn't it sufficient that
you've separately labeled "Data Model Requirements", "Protocol
Requirements", and "Operational Requirements"?
P.1: "The master device may validate the database against a list of
approved databases maintained by a regulatory body." I don't understand
that as a protocol requirement. What is being required?
P.5 and P.6: The requirement here is for *message-level* integrity and
encryption? That's OK, but I want to make sure that's what you mean.
P.8 and P.14: I don't think "result codes" and "response codes" are the
requirement here, are they? It sounds like the requirement is
"indication of success or failure".
P.15: I'm not clear on what this requirement means in practical terms.
Some more explanation seems in order.
P.16: Shouldn't this be combined with P.9?
O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy
required by the database"?
O.3: This seems to indicate that database discovery will be out of band,
that the WG is not developing protocol to do so. Is that what you meant?
If not, this should be turned into a protocol requirement instead of an
operational requirement.
O.4: This requirement seems a bit overly obvious and silly to state as a
requirement. Why is it necessary to say that you need a connection?
O.5: Again, "regulatory body" seems unnecessary here. Substituting
"database" seems sufficient, since you'll be getting the rule set from
the database.
O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can
change "local regulatory policy" to "the database rule set", "determined
by regulator policy" can be "enumerated in the database rule set", etc.
Section 7, generally: Same issue with "regulatory". See if there are any
that are more accurately "database rules".
Threat 7: This doesn't strike me as a security consideration per se.
This might make more sense incorporated into an operational requirement.
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
