Re: [paws] Gen-art LC review: draft-ietf-paws-protocol-12

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 
<rjsparks(_at_)nostrum(_dot_)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
> paws(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/paws


-- 
-vince