Robert, Thanks so much for your comments. Just a quick note that I'm working my through them and will post a reply in the next couple of days.
-vince On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks <rjspa...@nostrum.com> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-paws-protocol-12 > Reviewer: Robert Sparks > Review Date: 3 July, 2014 > IETF LC End Date: 7 July, 2014 > IESG Telechat date: 10 July, 2014 > > Summary: This document is not ready for publication as a Proposed Standard. > > I apologize in advance if I've missed where one of the questions below is > already answered. There's a lot to take in here. > > Major Issues > > - The document says it "describes" the use of HTTP/TLS as the transport > for the protocol. Was it the intent to allow others? If not, the language > should be firmed up. > > - The document still says "TBD Define message format" in the section on > Listing Servers. I understand from reading the list that what the document > is going to say about Listing Servers is going to change (to not include > how you talk to them?). This change needs to be finished before the > document can be reviewed for completeness. > > - It's not clear when a server should use the HTTP level redirection > discussed in section 7 vs the databaseChange mechanism in the protocol's > responses. There should be some discussion about what the Device should do > when the databaseChange mechanism results in a redirect loop. > > - The document needs to be clear where the primitive types (like string, > float, and integer) in the UML-ish diagrams in section 4 are defined. I'm > guessing from context that you're assuming the definitions in RFC4627. If > that's true, there are several places that you talk about string where your > text should change. RFC4627 says string is UNICODE, and may be encoded many > ways (see section 3 of that document). If your intent is to restrict all > strings to UTF-8 encoding say that, and adjust the text you currently have > that mentions UTF-8. (The various places where you say a string MAY contain > UTF-8 do not make sense - if you're assuming the encoding is UTF-8 and > trying to reinforce that there may be non-ASCII range UTF-8 here, say that > explicitly). There are other related phrases that don't make sense such as > where you say things like "The length of the string MUST NOT exceed 64 > US-ASCII characters." > > - The descriptions of messages in section 4 all contain *other:any. None > of those are reflected in the concrete schema of section 6. Should they be? > > - The INIT_RESP description requires one or more RulesetInfo objects. What > is a database supposed to do if it has no rulesets to return (possibly > because it doesn't have anything overlapping with the list of ruleset IDs > listed in the DeviceDescriptor in the INIT_REQ.). Should this have been > 0..* (along with the corresponding change to the text), or is there an > Error that the database should return when this happens. If the latter, it > would be good to call it out in 4.2.2. > > - Section 4.4 talks about returning OUTSIDE_COVERAGE when the location > specified in the request is outside the regulatory domain (could that be > domains?) supported by the database. The sections on init and registration > (4.2 and 4.3) don't have this discussion. Should they? > > - A databaseChange (at least as described in 4.4) can provide one or more > alternate database URIs, affecting the Device's configuration. When there's > more than one, is there any preference to what order the Device should try > to use them in? Is there any expectation that they will give the same > answers to a given request? If not, do you want to say anything about > discouraging devices from asking all the databases it knows about to find > an answer it likes best? > > - If the requirements to act as if there is no available whitespace when > you can't reach a Listing Server remain in the document, the security > considerations should call out that any attack that would prevent reaching > a Listing Server would result in all devices relying on that Listing Server > ceasing their use of any whitespace. > > - Please check the description of 'timeRange' in section 5.9 > (SpectrumSpec). I think you meant to say "in which there is _NO_ available > spectrum". > > - The definition of SpectrumProfile (section 5.12) needs clarification. Is > this allowed? > "profiles" : [ > {"hz": 5.18e8, "dbm": 30.0 }, > {"hz": 5.24e8, "dbm": 37.0 } > ] > If so, what does it mean? Do I do linear interpolation between points > (33.5 dbm (~2.25 watts) at 521Mhz)? > Similarly, does this specify a ramp up and then back down? (shaped like a > ^)? > [ > {"hz": 5.18e8, "dbm": 30.0 }, > {"hz": 5.21e8, "dbm": 33.5 }, > {"hz": 5.24e8, "dbm": 30.0 } > ] > If not, what text disallows it? > > > - You are using the schema language defined in draft-zyp-json-schema to > define your message format. That makes it a normative reference. The draft > is expired - are there plans to progress it? > > - Something needs to talk about case-sensitivity of the various protocol > elements. JSON-RPC says that member names are case sensitive and is > otherwise silent. The string "sensitive" doesn't appear in RFC4627. So, you > have an example that says "authority":"us". Is that the same as > "authority":"US", and where does the spec answer that question? My read of > JSON-RPC says that "authority":"us" and "Authority":"us" are _not_ the same > thing, and that the second would not be a recognized property of a > RulesetInfo object. > > Minor Issues > > - I'm not finding where you define the protocol version. I see "1.0" in > the json examples in section 6. Where is it specified? Within a given > method, the only extension point I find other than changing the protocol > version is the *other concept in messages, which MUST be ignored when > either side doesn't understand them. So there should be some discussion > about what kind of change would require the protocol version number to > change. Suppose you wanted to allow batching requests from several slaves > into one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but > allowing a list of DeviceDescriptors perhaps). Does this require a new > protocol version, or is it just a new request type in this version? If you > think it's a new request-type, should there be a request and response type > and/or method registry? And yes, I see how you could do this with JSON-RPC > batch, but if that's where you'd send this idea, why didn't you do > AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figure out > what "The initialization message also represents extension points for > database implementations or rulesets that require the explicit handshake." > is trying to say. Can you rephrase that more simply?) > > - It's not clear what it means to "support" a ruleset. I infer that this > means that the device has code that implements what's required by the name. > Can you state that explicitly? Does a Master device have to have this code? > Could it simply be a box that only serves to answer requests from Slave > devices? If so, why does it care what the rulesets actually are. If a slave > can ask and a database can answer, should a master just shovel the bits, or > is there a requirement that the master device be configured to handle a > ruleset before a slave can ask about it? > > - In the last paragraph of section 4.1 (before 4.1.1 starts), "If the > Device is already operating" assumes that the device could only be > operating if it had previously contacted some database. The problem is that > the device was able to reach a database at one point and now it can't reach > any. It would read more clearly if you said that explicitly. > > - Please point somewhere for a definition of the terms 'uncertainty' and > 'confidence' (I suggest draft-ietf-geopriv-uncertainty). The GEOPRIV > working group has gone through many iterations of disagreement about what > these terms mean and how they should be used. For a taste, skim some of < > https://mailarchive.ietf.org/arch/search/?email_list=geopriv&q=uncertainty>. > If you don't point to a hard definition, your implementation community will > have to go through the same arguments. > > - Should the security considerations section talk about the risk of > collisions in serialNumber (since it is the only required element in > DeviceDescriptor, and isn't a particularly secret thing)? Is there any harm > at the database if two devices innocently end up sending the same serial > number (without providing any of the optional information that would > otherwise disambiguate the devices)? Can a device learn anything useful > about another device by spoofing it? Is it possible that in some regulatory > realm, some devices would get more access than others, encouraging devices > to ask about what their competition gets to do? Can harm be done by a > device sending SPECTRUM_USE_NOTIFY messages claiming to be some other > serial number (and perhaps manufacturer) maliciously? I think this needs > more discussion than what RFC6953 contains. > > - The use of the "id" parameter from JSON-RPC deserves more discussion. > The JSON-RPC spec allows it to be string, numeric (without a fractional > part), NULL or missing. You've chosen to require it (since you're not using > json-rpc notifications), and not allowing numeric values (why?). Are you > making any other assumptions about what it should contain? I think you're > assuming a level of uniqueness that would let you use the Batch mechanism > in section 6 of JSON-RPC (otherwise, the HTTP request/response context is > enough to associate the request and response and the id might as well be > constant). > > - Section 7 says a server can reject a GET with a 404 - wouldn't that have > consequences for a later POST? Why wouldn't it use a 405? > > - The draft calls for the creation of a special list for review requests > for the IANA assignments. This may be ok (mailing lists are easy to set > up), but is there not an existing list that would serve the purpose just as > well? > > Nits > > - RFC 2616 has been obsoleted - the references should be updated. > > - It would help to have an example of a ruleset in the definition in the > Terminology section and perhaps for that definition to more strongly convey > that it is a name in a namespace, and what that rule means is elsewhere. > (Right now the definition says that the ruleset is the actual set of > rules, not a name, and it made reading the protocol overview much harder > than it needed to be). At the very least, pointing to the examples in > section 9 early would help. > > - Is the document loosely borrowing UML, or are the diagrams used in > section 4 of a format formally defined in some other RFC? A pointer to a > definition of the format, or a brief description noting it's based on UML > along with where the base types are defined would be useful. > > - "One approach to manage spectrum sharing" is awkward. Would "One > approach to managing spectrum sharing" or "One approach to the management > of spectrum sharing" work? > > - There are several instances of "The Device needs to use the information > to update its list". Consider clarifying 'needs to'. Should this have been > MUST? > > - "The vertices MUST be defined in a counter-clockwise direction" assumes > you are looking at them from above - please be explicit. > > - Section 9.1.2's first paragraph should say "FCC and ETSI" the same way > 9.2.2 does. You could generalize that to "any particular set of > authorities". > > _______________________________________________ > paws mailing list > p...@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
