> The IESG has received a request from the Protocol to Access WS database > WG (paws) to consider the following document: > - 'Protocol to Access White Space (PAWS) Database: Use Cases and > Requirements' > <draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt> as Informational > RFC Some Last Call comments, in advance of IESG Evaluation: -- General -- It's completely a non-starter that there's no email address for Anthony Mancuso; this has to be added. He won't get any of the IESG Evaluation messages this way, and the RFC Editor won't be able to contact him during the publication process. Abstracts should not contain citations, so the "[1]" citation should be removed. But perhaps more to the point, the Abstract is too long; the first paragraph can be trimmed after the second sentence (clipping everything beginning with "An obvious requirement", which doesn't need to be in the abstract (but should be and is in the Introduction)). The first and third references need to be in RFC reference form, and not simply as URIs. They should look something like this: [1] V. Chen, S. Das, Z. Lei, J. Malyar, P. McCann, "Protocol to Access Spectrum Database", draft-ietf-paws-protocol-01 (work in progress), December 2012 [3] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems", NIMA TR8350.2 Third Edition Amendment 1, January 2000, <http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html> For the second reference: the RFC Editor will not generally accept Wikipedia as a reference, because its contents are unstable. Perhaps you could use something like <http://fcc.gov/oet/cognitiveradio/> instead? Just an alert: the RFC Editor will probably add hyphens when "white space" is used as an adjective, as in "white-space spectrum". This is particularly notable when you have "non-white space spectrum", which looks like space that is non-white (as opposed to "non-white-space spectrum"). You may feel free to wait for them to do that. Or you can do it. -- Section 1.1 -- The first paragraph seems overlong, and could do with splitting. Perhaps start a new paragraph with "An obvious requirement", and then another with "Academia and industry". -- Section 3.1 -- It looks like a lot of stuff in these earlier sections used to have 2119 language, and got Peted. You missed one: the "MUST" in the second sentence should be "must". -- Section 3.2 -- Does Figure 1 actually show anything useful or interesting? It says it illustrates a registration requirement, but I don't see it. I'd say that "most current and up-to-date information" is redundant (this also shows up in 6.3). And anyway, step 1 isn't a step -- you don't *do* anything there. -- Section 4.1 -- Figure 2 (Figure 2) depicts the general architecture such a simple master-slave network You're missing an "of". And is there a reason for "Figure 2 (Figure 2)" (and with other figures) that I don't understand? Bullet 3: There is no Section 4.1.1 to see. Bullet 4: It's not really optional (which implies that it's at the option of the master). It's required if the database requires it, but not all databases require it. Can you re-word? (And there is no Section 4.1.2, either.) Bullet 5: The part beginning "Note that" is out of place here, but that's OK, because it's repeated where it belongs, in bullet 6. I suggest you just remove it from here. -- Section 5 -- The databases may be regulatory specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be regulatory independent. Is "should be" appropriate? I should think "has to be". In Figure 11, note that there could be multiple databases serving white space devices. There is no Figure 11. You mean 7? The databases are locale specific since the regulations and available spectrum may vary. I think you mean "location-specific"; in the App world "locale" has a particular meaning that I don't think you mean (in other words, this is not an issue of local language). This applies to the use of "locale" elsewhere in the document as well. -- Section 5.1 -- Bullet 3 confuses me. First it says that it's possible for the device to know what rules are applicable, because it knows its location. Then it says to note that even though it knows its location, it may not be able to know what rule set to use. Is that not contradictory, or am I misunderstanding? Then it gives an important requirement that's buried at the end. I suggest putting the requirement earlier, and then following it with the extended explanation of the need for it. -- Section 5.2 -- The device needs to determine the location of the specific database to which it can send queries in addition to registering itself for operation and using the available spectrum. I'm having a lot of trouble parsing this sentence, and I'm still not sure I understand what it means. Can you try rephrasing it? -- Section 6.1 -- The Data Model MUST support WGS84 (see NGA: DoD World Geodetic System 1984 [3]). I think this statement makes that reference normative. D.3 The Data Model MUST support device description data that identifies a device (serial number, certification IDs, etc.) and describes device characteristics, such as or device class (fixed, mobile, portable, indoor, outdoor, etc.), Radio Access Technology (RAT), etc. Is the "or" in there a stray, or is there something else wrong? -- Section 6.2 -- P.9 The protocol MUST support an available spectrum request from the master device to the database. These parameters MAY include any of the parameters and attributes required to be supported in the Data Model Requirements. "These parameters" implies that you've mentioned parameters before, but you haven't. What parameters? (Same comment for P.10 and P.11.) -- Section 6.3 -- O.5 The master device MAY register with the database according to local regulatory policy. As above: this is not a correct use of MAY, because it's not at the option of the master device. In fact, as you say later in this requirement, it MUST register when it's required to. Please re-word this. (O.6) Parameters provided to the database MAY include device location, accuracy of the location Again... are these parameters provided purely at the option of the requestor (in which case "MAY" is fine), or are they provided because they're required by the database (in which case "MAY" is not right)? O.8 According to local regulator policy, a master device MAY inform the database of the actual frequency usage O.10 According to local regulatory policy, the master device MAY query the database with parameters received from the slave device. More of the same about the "MAY". -- Section 8 -- It is assumed that both the master device and the white space database have NOT been compromised from a security standpoint. Threat 1: User modifies a device to masquerade as another valid certified device Here's how I read these two adjacent paragraphs: (1) It is assumed that the device is not compromised; (2) Threat 1: A user compromises the device. Am I completely misunderstanding? (I also find the explanation below that to be convoluted. Can you work on it, and try to un-convolute it?) A master device MAY need to identify itself to the database and be authorized to obtain information about available spectrum. Totally wrong "MAY"; make it "might". Remember that "MAY" means that something is entirely optional. "MAY need to" is pretty much always wrong. Threat 4: The available spectrum information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using spectrum that is not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. That's quite a sentence. Please unravel it and re-word. Threat 6: Expand "MiM". The security requirements arising from the above threats are captured in the requirements of Section 6.1 (Section 6.1). There's that duplication again: "Section 6.1 (Section 6.1)" -- Section 9 -- This section is entirely unnecessary, and you should remove it. There's no need to repeat what you've already said. Barry