Good suggestion Gabor. I will wait another day or so and then start on generating a new version in response to the comments and clarifications.
On Wed, Jan 23, 2013 at 1:55 PM, <[email protected]> wrote: > 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]> > 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 > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** >
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
