My suggestion would be, if Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into consideration. Thanks, Gabor
From: [email protected] [mailto:[email protected]] On Behalf Of ext Anthony Mancuso Sent: Wednesday, January 23, 2013 1:17 PM To: Pete Resnick Cc: [email protected] Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 Thanks Pete. I went through the list quickly and they seemed like very sensible suggestions and calls for clarification. I will go over these (and any new ones) once we hear back (or don't hear) from the WG as you suggest. Tony On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick <[email protected]<mailto:[email protected]>> wrote: 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<tel:%2B1%20%28858%29651-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
