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

From: Robert Sparks <[email-masked]>
Date: Thu, 03 Jul 2014 12:28:02 -0500

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".

---

From: Vincent Chen <[email-masked]>
Date: Tue, 8 Jul 2014 02:33:22 -0700

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 <[email-masked]> wrote:

> 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
>
> for the protocol. Was it the intent to allow others? If not, the language
> should be firmed up.
>
> 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.
>
> responses. There should be some discussion about what the Device should do
> when the databaseChange mechanism results in a redirect loop.
>
> 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 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.
>
> 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?
>
> 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.
>
> (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" : [
> Similarly, does this specify a ramp up and then back down? (shaped like a
> ^)?
>   [
> define your message format. That makes it a normative reference. The draft
> is expired - are there plans to progress it?
>
> 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
>
> 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?)
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> up), but is there not an existing list that would serve the purpose just as
> well?
>
> Nits
>
> 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.
>
> 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.
>
> 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.
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Tue, 8 Jul 2014 19:21:51 -0700

Robert,

Thanks again for the review. I have place comments, questions, suggested
text inline for each of your comments.
Please take a look.

-vince

> for the protocol. Was it the intent to allow others? If not, the language

The protocol messages are meaningful independent of the transport, so we
did not want to prohibit others. It that frowned on?

> document can be reviewed for completeness.

Noted. Will ask again on the list.

> 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.

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.

> where you say things like "The length of the string MUST NOT exceed 64

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.

> 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.

> 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).

> (4.2 and 4.3) don't have this discussion. Should they?

Yes. Added to those requests. Thanks.

> discouraging devices from asking all the databases it knows about to find

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.

> ceasing their use of any whitespace.

Thanks. Added.

> (SpectrumSpec). I think you meant to say "in which there is _NO_ available

Thanks for the catch!

> 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.

> 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".

> thing, and that the second would not be a recognized property of a

You're right. See above proposed text defining the primitive types.

> 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".

> 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.

> 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; ...

> have to go through the same arguments.

Done. Although regulatory authorities may prescribe their own definitions.

> 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.

  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?

> enough to associate the request and response and the id might as well be

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?

> consequences for a later POST? Why wouldn't it use a 405?

Yes, it's supposed to be 405.

> up), but is there not an existing list that would serve the purpose just as

I do not believe there is an existing list, unless it's standard practice
to re-use this discussion group ([email-masked]).

> - RFC 2616 has been obsoleted - the references should be updated.

Updating to RFC 7231

> section 9 early would help.

See proposed text of Terminology above.

> 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?

> of spectrum sharing" work?

Thanks. Changing to "One approach to managing spectrum sharing"

> to update its list". Consider clarifying 'needs to'. Should this have been

These were changed based on comments from our AD (Pete), since they are not
a protocol requirement.

> you are looking at them from above - please be explicit.

Thanks. Adding clarification.

> 9.2.2 does. You could generalize that to "any particular set of

Thanks for the suggestion. Changing both to "any particular set of
authorities".

-- 
-vince

---

From: Robert Sparks <[email-masked]>
Date: Tue, 15 Jul 2014 16:42:37 -0500

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.

Some small comments inline:
>
> -vince
>
>
> On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>
>     - 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.
>
>
> 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.
>     - 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
>     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.
>
>
> This was indicated in the prior section for INIT_REQ, but propose 
> adding the following as first paragraph:
>
>     - 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?
>
>
> 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.
>
>     - 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.
>
>
>     - The definition of SpectrumProfile (section 5.12) needs
>     clarification. Is this allowed?
>       "profiles" : [
>     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 ^)?
>       [
> This is explicitly allowed. We changed the encoding to allow this. 
> Propose modifying the first paragraph of  5.12 to the following:
>
>     - 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.
Check with your AD on the best way to handle this.
>
>
>     - 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.
>
>
>     - 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?
>
>
> OK. Propose update Terminology section to distinguish between 
> "ruleset" and "ruleset identifier":
>
>     - 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:
>
>     - 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
>     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
>     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?
>
>   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.
>
Consider calling out the possibility of SPECTRUM_USE_NOTIFY messages 
that are fraudulent (and perhaps how client authentication might protect 
against them)?
>
>
>     - 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).
>
>
Just adding a short description of the properties that you require of id.
>
>
>     - 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?
>
>
> I do not believe there is an existing list, unless it's standard 
> practice to re-use this discussion group ([email-masked] 
> <mailto:[email-masked]>).
>
>
>     Nits
>
>     - 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.
>
>
>     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.
>
>
>     - 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".
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Vincent Chen <[email-masked]>
Date: Wed, 16 Jul 2014 09:06:04 -0700

Robert,

Thanks again.

> I'll be in Toronto if you want to talk about any of these.

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

> TLS for things like server authentication for example.

Acknowledged.

> 3xx responses, and you still want well defined application behavior when

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

>> What is a database supposed to do if it has no rulesets to return (possibly
> 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.
>

Acknowledged

>  OK. Propose update Terminology section to distinguish between "ruleset"
> and "ruleset identifier":
>
> 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.

> rules differently, then I think security considerations would be extended
> to handle those cases.
>
>  Re: SPECTRUM_USE_NOTIFY
> Consider calling out the possibility of SPECTRUM_USE_NOTIFY messages that
> are fraudulent (and perhaps how client authentication might protect against
> them)?
>

Acknowledged.

> Just adding a short description of the properties that you require of id.

Ack.

> practice to re-use this discussion group ([email-masked]).
>
>
>>
>> Nits
>>
>  These were changed based on comments from our AD (Pete), since they are
> not a protocol requirement.
>
>

-- 
-vince