Re: Last Call: <draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt> (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> The IESG has received a request from the Protocol to Access WS database
> WG (paws) to consider the following document:
> - 'Protocol to Access White Space (PAWS) Database: Use Cases and
>    Requirements'
>   <draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt> as Informational
> RFC

Some Last Call comments, in advance of IESG Evaluation:

-- General --

It's completely a non-starter that there's no email address for
Anthony Mancuso; this has to be added.  He won't get any of the IESG
Evaluation messages this way, and the RFC Editor won't be able to
contact him during the publication process.

Abstracts should not contain citations, so the "[1]" citation should
be removed.  But perhaps more to the point, the Abstract is too long;
the first paragraph can be trimmed after the second sentence (clipping
everything beginning with "An obvious requirement", which doesn't need
to be in the abstract (but should be and is in the Introduction)).

The first and third references need to be in RFC reference form, and
not simply as URIs.  They should look something like this:

[1] V. Chen, S. Das, Z. Lei, J. Malyar, P. McCann, "Protocol to
Access Spectrum Database", draft-ietf-paws-protocol-01 (work in
progress), December 2012

[3] National Imagery and Mapping Agency, "Department of Defense
World Geodetic System 1984, Its Definition and Relationships with
Local Geodetic Systems", NIMA TR8350.2 Third Edition Amendment 1,
January 2000,
<http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html>

For the second reference: the RFC Editor will not generally accept
Wikipedia as a reference, because its contents are unstable.  Perhaps
you could use something like <http://fcc.gov/oet/cognitiveradio/>
instead?

Just an alert: the RFC Editor will probably add hyphens when "white
space" is used as an adjective, as in "white-space spectrum".  This is
particularly notable when you have "non-white space spectrum", which
looks like space that is non-white (as opposed to "non-white-space
spectrum").  You may feel free to wait for them to do that.  Or you
can do it.

-- Section 1.1 --

The first paragraph seems overlong, and could do with splitting.
Perhaps start a new paragraph with "An obvious requirement", and then
another with "Academia and industry".

-- Section 3.1 --

It looks like a lot of stuff in these earlier sections used to have
2119 language, and got Peted.  You missed one: the "MUST" in the
second sentence should be "must".

-- Section 3.2 --

Does Figure 1 actually show anything useful or interesting?  It says
it illustrates a registration requirement, but I don't see it.

I'd say that "most current and up-to-date information" is redundant
(this also shows up in 6.3).  And anyway, step 1 isn't a step -- you
don't *do* anything there.

-- Section 4.1 --

   Figure 2 (Figure 2) depicts the general architecture such a simple
   master-slave network

You're missing an "of".  And is there a reason for "Figure 2 (Figure
2)" (and with other figures) that I don't understand?

Bullet 3: There is no Section 4.1.1 to see.

Bullet 4: It's not really optional (which implies that it's at the
option of the master).  It's required if the database requires it, but
not all databases require it.  Can you re-word?  (And there is no
Section 4.1.2, either.)

Bullet 5: The part beginning "Note that" is out of place here, but
that's OK, because it's repeated where it belongs, in bullet 6.  I
suggest you just remove it from here.

-- Section 5 --

   The databases may be regulatory specific
   since the available spectrum and regulations may vary, but the
   fundamental operation of the protocol should be regulatory
   independent.

Is "should be" appropriate?  I should think "has to be".

   In Figure 11, note that there could be multiple databases serving
   white space devices.

There is no Figure 11.  You mean 7?

   The databases are locale specific since the
   regulations and available spectrum may vary.

I think you mean "location-specific"; in the App world "locale" has a
particular meaning that I don't think you mean (in other words, this
is not an issue of local language).  This applies to the use of
"locale" elsewhere in the document as well.

-- Section 5.1 --

Bullet 3 confuses me.  First it says that it's possible for the device
to know what rules are applicable, because it knows its location.
Then it says to note that even though it knows its location, it may
not be able to know what rule set to use.  Is that not contradictory,
or am I misunderstanding?  Then it gives an important requirement
that's buried at the end.

I suggest putting the requirement earlier, and then following it with
the extended explanation of the need for it.

-- Section 5.2 --

   The device needs to
   determine the location of the specific database to which it can send
   queries in addition to registering itself for operation and using the
   available spectrum.

I'm having a lot of trouble parsing this sentence, and I'm still not
sure I understand what it means.  Can you try rephrasing it?

-- Section 6.1 --

         The Data Model MUST support WGS84 (see NGA: DoD World Geodetic
         System 1984 [3]).

I think this statement makes that reference normative.

      D.3  The Data Model MUST support device description data that
         identifies a device (serial number, certification IDs, etc.)
         and describes device characteristics, such as or device class
         (fixed, mobile, portable, indoor, outdoor, etc.), Radio Access
         Technology (RAT), etc.

Is the "or" in there a stray, or is there something else wrong?

-- Section 6.2 --

   P.9  The protocol MUST support an available spectrum request from the
      master device to the database.  These parameters MAY include any
      of the parameters and attributes required to be supported in the
      Data Model Requirements.

"These parameters" implies that you've mentioned parameters before,
but you haven't.  What parameters?  (Same comment for P.10 and P.11.)

-- Section 6.3 --

   O.5  The master device MAY register with the database according to
      local regulatory policy.

As above: this is not a correct use of MAY, because it's not at the
option of the master device.  In fact, as you say later in this
requirement, it MUST register when it's required to.  Please re-word
this.

  (O.6)
      Parameters provided to the database
      MAY include device location, accuracy of the location

Again... are these parameters provided purely at the option of the
requestor (in which case "MAY" is fine), or are they provided because
they're required by the database (in which case "MAY" is not right)?

   O.8  According to local regulator policy, a master device MAY inform
      the database of the actual frequency usage

   O.10  According to local regulatory policy, the master device MAY
      query the database with parameters received from the slave device.

More of the same about the "MAY".

-- Section 8 --

         It is assumed that both the master device and the white space
         database have NOT been compromised from a security standpoint.

      Threat 1: User modifies a device to masquerade as another valid
      certified device

Here's how I read these two adjacent paragraphs: (1) It is assumed
that the device is not compromised; (2) Threat 1: A user compromises
the device.

Am I completely misunderstanding?  (I also find the explanation below
that to be convoluted.  Can you work on it, and try to un-convolute
it?)

         A master device MAY
         need to identify itself to the database and be authorized to
         obtain information about available spectrum.

Totally wrong "MAY"; make it "might".  Remember that "MAY" means that
something is entirely optional.  "MAY need to" is pretty much always
wrong.

Threat 4:
         The available spectrum
         information or transmit power allowed type of parameters
         carried in the response could be modified by the attacker
         resulting in the master device using spectrum that is not
         available at a location or transmitting at a greater power
         level than allowed resulting in interference to the primary
         user of that spectrum.

That's quite a sentence.  Please unravel it and re-word.

Threat 6: Expand "MiM".

   The security requirements arising from the above threats are captured
   in the requirements of Section 6.1 (Section 6.1).

There's that duplication again: "Section 6.1 (Section 6.1)"

-- Section 9 --

This section is entirely unnecessary, and you should remove it.
There's no need to repeat what you've already said.

Barry


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]