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

Robert,

Thanks again.

On Tue, Jul 15, 2014 at 2:42 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

>
> On 7/8/14, 9:21 PM, Vincent Chen wrote:
>
> Robert,
>
>  Thanks again for the review. I have place comments, questions, suggested
> text inline for each of your comments.
> Please take a look.
>
> I'll be in Toronto if you want to talk about any of these.
>

Still trying to decide if I can make it...

>
> Some small comments inline:
>
>
>  -vince
>
>
> On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks <rjsparks@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 protocol messages are meaningful independent of the transport, so we
> did not want to prohibit others. It that frowned on?
>
>
> Well, your security considerations, at least, should talk about what you
> require of the transport if you don't use TLS. You're leaning heavily on
> TLS for things like server authentication for example.
>

Acknowledged.

>
>
>
>>
>> - 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.
>>
>
>  Noted. Will ask again on the list.
>
>
>>
>> - 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.
>>
>
>  Thanks for pointing this out. I propose removing the HTTP-level 301
> Moved Permanently mechanism and only have the databaseChange mechanism.
>
> The group will have to chew on this I guess. You can't forbid HTTP-level
> 3xx responses, and you still want well defined application behavior when
> they're received.
>

I see about not forbidding 3xx responses. Perhaps just clarification that
the preferred mechanism is databaseChange.

>
>
>  Proposed modified text in Section 4.1:
>     A Database MAY indicate that its URI will be changing by including
>    the URI of one or more alternate databases (See DbUpdateSpec
>    (Section 5.7)) in its responses to a Device.  Before a Database
>    ceases operation, for example, it MUST include DbUpdateSpec in its
>    responses to notify Devices.  A Device will update its preconfigured
>    list of databases to replace (only) its entry for the responding
>    Database with the URIs of the alternate databases; the list of
>    alternate databases does not affect any other entries.  Note that the
>    ordering of databases in the list does not imply any preference and
>    does not need to remain the same for every request.  The Device
>    SHOULD detect infinite redirection loops; if a suitable database
>    cannot be contacted, the Device MUST treat this as equivalent to a
>    response indicating no available spectrum.
>
>
>
>>
>> - 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."
>>
>
>  OK. Specified UTF-8 and removed meaningless statements.
>
>  Proposed added text in Section 4:
>
>     The parameter tables in this section and Protocol Parameters
>    (Section 5) are for reference and contain the name of each parameter,
>    the data type of each parameter, and whether the existence of the
>    parameter is required for the protocol transaction in question.  The
>    diagrams are loosely based on UML, and the data types are defined
>    either in Protocol Parameters (Section 5) or are one of the following
>    primitive or structured types:
>
>     string  A string, as defined by The JavaScript Object Notation (JSON)
>       Data Interchange Format [RFC7159], restricted to the UTF-8
>        encoding.
>
>     int  A number, as defined by The JavaScript Object Notation (JSON)
>       Data Interchange Format [RFC7159], without a fractional or
>       exponent part.
>
>     float  A number, as defined by The JavaScript Object Notation (JSON)
>       Data Interchange Format [RFC7159].
>
>     boolean  A boolean, as defined by The JavaScript Object Notation
>       (JSON) Data Interchange Format [RFC7159].
>
>     list  A structured type the represents a list of elements, as defined
>       by The JavaScript Object Notation (JSON) Data Interchange Format
>       [RFC7159] array type.  For each list parameter, its diagram and
>       description include a reference to the data type its list
>       elements.  The diagram notation and description may include
>       additional constraints, such as minimum or maximum number of
>       elements.
>
>     NOTE: All parameter names are case sensitive.  Unless stated
>    otherwise, all string values are case sensitive.
>
>
>> - 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?
>>
>
>  This was intended to be capture by the note in Section 6:
>
>     NOTE: In general, all messages defined in this section are extensible
>    by adding additional properties to support ruleset-specific and
>    database-specific requirements.  In all cases, the Device or Database
>    MUST ignore any parameter it does not understand.
>
>
>
>>
>> - 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.
>>
>
>  This was indicated in the prior section for INIT_REQ, but propose adding
> the following as first paragraph:
>
>      The initialization response message communicates database parameters
>    to the requesting device.  This response is returned only when there
>    is at least one ruleset.  Otherwise, the Database returns an error
>    response, as described in INIT_REQ (Section 4.2.1).
>
>
>
>>
>> - 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?
>>
>
>  Yes. Added to those requests. Thanks.
>
>
>>
>> - 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?
>>
>
>  In general, there should be no difference in answers, because each
> Database must also conform to the regulatory rules. There is no
> significance implied by the list ordering. On the other hand, I don't think
> we need language discouraging devices from asking multiple databases, since
> they should have an understanding of the rules as well.
>
>  See proposed text above that contains:
>
>     Note that the
>     ordering of databases in the list does not imply any preference and
>    does not need to remain the same for every request.
>
>
>>
>> - 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.
>>
>
>  Thanks. Added.
>
>
>>
>> - Please check the description of 'timeRange' in section 5.9
>> (SpectrumSpec). I think you meant to say "in which there is _NO_ available
>> spectrum".
>>
>
>  Thanks for the catch!
>
>
>>
>> - 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?
>>
>
>  This is explicitly allowed. We changed the encoding to allow this.
> Propose modifying the first paragraph of  5.12 to the following:
>
>     A spectrum profile is characterized by an ordered list of (frequency,
>    power) points that represents the shape of maximum permissible power
>    levels over a range of frequencies as a piecewise linear curve.
>
>  Also add after the list of constraints:
>
>     NOTE: This encoding allows presentation of "ramps" where the slope of
>    a line segment may be finite and non-zero.
>
>
>>
>> - 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?
>>
>
>  Yikes. The intent is not to define a strict, formal schema, but just to
> have a way of defining the messages in a concise fashion.
> Do you have a recommendation of what to do here? Are the descriptions
> self-explanatory enough? or do I have to define
> the "schema language".
>
> Check with your AD on the best way to handle this.
>

Acknowledged

>
>
>
>>
>> - 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.
>>
>
>  You're right. See above proposed text defining the primitive types.
>
>
>>
>> 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?)
>>
>
>  Good point. Propose adding a new section:
>
>  4.2.  PAWS Version
>
>     PAWS version uses a "<major>.<minor>" numbering scheme to indicate
>    versions of the protocol.  The protocol versioning policy is intended
>    to allow the Device or Database to indicate the format of a message
>    and its understanding of PAWS functionality defined by that version.
>    No change is made to the version string for the addition of message
>    components which only add to extensible field values.  The <minor>
>    number is incremented when the changes made to the protocol add
>    functionalities (methods), but do not change the existing
>    functionalities.  The <major> number is incremented when incompatible
>    changes are made to existing functionality.
>
>     The current PAWS version is "1.0".
>
>
>>
>> - 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?
>>
>
>  OK. Propose update Terminology section to distinguish between "ruleset"
> and "ruleset identifier":
>
>     Ruleset:  A ruleset represents a set of rules that governs the
>       operation of white space devices and Spectrum Databases.  A
>       regulatory authority can define its own set of rules or adopt an
>       existing ruleset.  When a Database or Device is said to "support a
>       ruleset", it means that it contains out-of-band knowledge of the
>       rules and that its hardware and software implementations conform
>       to those rules.
>
>     Ruleset Identifier:  A ruleset can be identified by an IANA-
>       registered identifier (see PAWS Ruleset ID Registry
>       (Section 9.1)).  When a Database or Device indicates it supports a
>       ruleset identifier, it means that it conforms to the rules
>       associated with that identifier.  A regulatory authority can
>       define and register its own ruleset identifiers, or it can use a
>        previously registered identifier if it adopts an existing ruleset.
>
>
>>
>> - 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.
>>
>
>  Proposed change:
>
>     If the Device had previously contacted a database to get available
>    spectrum, but subsequently fails to contact a suitable database, the
>    spectrum the Device is currently using can be used for as long as the
>    spectrum data is valid; ...
>
>
>>
>> - 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.
>>
>
>  Done. Although regulatory authorities may prescribe their own
> definitions.
>
>
>>
>> - 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.
>>
>
>  Re: Available spectrum.
>   The available spectrum depends on device type and location, not on
> serial number. Consequently, there is no advantage to spoofing, and there
> would be no additional information to be gained on spoofed devices.
>
> So, you can't gain information about someone else by claiming to be their
> device type either?
>

Correct. There's no device-specific information.

>
>
>    If, in the future, there is some regulatory realm that would set up
> rules differently, then I think security considerations would be extended
> to handle those cases.
>
>  Re: SPECTRUM_USE_NOTIFY
>   I suppose this depends on the specific regulatory domains (or database
> implementations) that require it. Currently there is no harm, since
> notifications do not change the available spectrum answers that the
> Database returns to devices.
>
>  So should I add these statements to the Security Considerations section?
>
> Consider calling out the possibility of SPECTRUM_USE_NOTIFY messages that
> are fraudulent (and perhaps how client authentication might protect against
> them)?
>

Acknowledged.

>
>
>
>>
>> - 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).
>>
>
>  Purely as a practical matter, handling a known type is easier than
> multi-type. It should improve interoperability. Otherwise, its value
> remains opaque to the Database.
>
>  What is your recommendation here?
>
> Just adding a short description of the properties that you require of id.
>

Ack.

>
>
>
>>
>> - 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?
>>
>
>  Yes, it's supposed to be 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?
>>
>
>  I do not believe there is an existing list, unless it's standard
> practice to re-use this discussion group (paws@ietf.org).
>
>
>>
>> Nits
>>
>> - RFC 2616 has been obsoleted - the references should be updated.
>>
>
>  Updating to RFC 7231
>
>
>>
>> - 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.
>>
>
>  See proposed text of Terminology above.
>
>
>>
>> - 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.
>>
>
>  See proposed text of primitive types above. Do I need a reference to UML?
>
>
>>
>> - "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?
>>
>
>  Thanks. Changing to "One approach to managing spectrum sharing"
>
>
>>
>> - 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?
>>
>
>  These were changed based on comments from our AD (Pete), since they are
> not a protocol requirement.
>
>
>> - "The vertices MUST be defined in a counter-clockwise direction" assumes
>> you are looking at them from above - please be explicit.
>>
>
>  Thanks. Adding clarification.
>
>
>>
>> - 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".
>>
>
>  Thanks for the suggestion. Changing both to "any particular set of
> authorities".
>
>
>>
>> _______________________________________________
>> paws mailing list
>> paws@ietf.org
>> https://www.ietf.org/mailman/listinfo/paws
>>
>
>
>
>  --
> -vince
>
>
>

-- 
-vince