Some observations and comments on your review. Posted inline below, I don't have any specific issues with what you say. Peter S.
From: Pete Resnick <[email protected]<mailto:[email protected]>> Date: Wednesday, January 23, 2013 3:54 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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? Regulators are asking for manufacturer and model number as they may require action, enforcement or denial by the DB on the set to manufacturer devices or a specific model of device "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. 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. 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. The location of a device determines it regulatory domain. However the device may understand this or it may be told. For instance our current US implementation validates that a device is within the regulatory domain. If not we deny it service but allowed for the DB to tell the device who or what it should contact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together with the comment below this may need some thought and additional work 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. The FCC, as an example, has two concepts of a slave. The first is a client served by a master, think 802.11 client using a channel served by an AP. This is the model for low power devices. If the device is a high power device the slave must get it's own channel list. It can use a master to do this, using white space spectrum, if it has no other means of contacting the database. 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. As above a low power slave, under FCC rule, does not have to provide any of this information but a high power slave does. 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? High power again. A slave may not get the same channel list as the master and may not be able to use the channel the master is currently using so a negotiation will be necessary. 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? Same comment as above 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? The regulatory domain is assumed to be similar to a country domain but need not be. A database could be permitted to serve a different definition. In the FCC case they currently limit the domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA. 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"? Acceptable Location Accuracy is defined by the regulator and applied to the calculations of 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. General observation about this and the next couple of comments. The FCC Certifies a radio and a database as a "system" Ofcom is 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. 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
