Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)

[Ted Lemon <[e-mail]>]

Pete pinged me on this last Thursday, and I finally had time to go through and check each of the points I raised to see if they had been addressed.   Most of them have been, but there are a few that remain (highlighted in alternating colors; I'm keeping all the points here for my convenience, so don't feel you need to look at anything but the colorful stuff.)

--Ted--
4.1 says "Some regulatory domains may have specific rules regarding
how long the spectrum data remains valid in these cases."  It might be
worth adding that in such cases the initialization procedure is
required.  This is addressed to some extent in section 4.3, but I'm
not sure it's completely addressed.  The potential problem I see is
that a device might be used in a regulatory regime where this is
required, but might have pre-configured values for some other
regulatory regime.  If these values are not valid in the regime that
applies for its current location, it might have a too-long refresh
interval configured, fail to detect that this is the case, and as a
result accidentally break the law.  Can a scenario like this occur in
practice?

--Vincent--
It should not occur in practice for well-behaved devices.

When it is preconfigured, there must be a preconfigured value for each
ruleset.  Of course, a device may choose to use preconfigured values
for only a subset of the rulesets it supports.

Note that, in practice, a device needs to be certified for each
"ruleset" by whatever process is defined by each applicable regulatory
body, so that any preconfigured values will be certified to be
compliant.

--Ted--

If this is how it works, shouldn't the document say so?  Or was that
in the requirements document?  I admit it's been a while since I read
it. :)

--Vincent--

I'll clarify the text some. Note, however, that INIT_RESP return these
values as part of a RulesetInfo structure, so that it is implied that
preconfiguration also must be on a per-ruleset basis.

--Ted--
To be clear, what I was suggesting ought to be documented is that the
information has to be preconfigured and certified by the regulatory
authority.  If this is already mentioned in the requirements document,
there's no need to mention it here, although a reference to the
previous document might be helpful for neophytes like me.  I don't
really know what the mental context of a reader of this document would
be, so please forgive me if I'm being ridiculous here.

--STATUS--

Addressed in -14.

--Ted--
Section 5.2 says that the manufacturer ID and model ID are optional,
but may be required by some rulesets.  Section 4.3.1 does not say what
error is returned when a deviceDesc that does not contain one or both
of these parameters is sent to the server, but the matching ruleset
requires either parameter.  I suspect the answer is straightforward,
but I think it needs to be stated explicitly in 4.3.1.  E.g., if the
optional but required parameters are accepted in the initialization
but rejected in the registration, it would be good to say so
explicitly.

--Vincent--
OK. In these cases, the Database should return the MISSING error, with
additional data specifying the missing fields.

--STATUS--

There has been no change to the document that I can find that
addresses this point.

--Ted--
In 4.4.2, I think that if none of the rulesets are accepted, the intent
is that the database should return a REGISTRATION_RESP with the error
element, and will not return a rulesetInfos list.   However, the
specification does not make an exception for this case when it says "A
RulesetInfo list MUST be included" and  "The list MUST contain at least
one entry".   I can't think of another valid interpretation, but you've
stated a MUST, so you need to say that it doesn't apply in the case of
the error.

--Vincent--
Ah, right. There is language from INIT_RESP that needs to be repeated here.

--Ted--
The problem I have with this text actually stems from the first
paragraph of the section:

  The registration response message acknowledges successful
  registration by including a RulesetInfo message for each ruleset in
  which the registration is accepted.  If the Database does not accept
  the registration for any of the rulesets it supports, the Database
  MUST return the NOT_REGISTERED error (See Error Codes
  (Section 5.17)).

In reviewing this just now, I realized that I may have completely
misinterpreted the second sentence.  It probably means either:

 If the database does not accept the registration for any single
 ruleset it supports, the database MUST return the NOT_REGISTERED
 error.

Or:

 If none of the rulesets being registered are accepted by the
 database, the database MUST return the NOT_REGISTERED error.

Right now, your use of "any" could be interpreted either way.

And then, what I was asking you to change in this DISCUSS item was this:

  rulesetInfos:  A RulesetInfo (Section 5.6) list MUST be included in
     the response.  Each entry corresponds to a ruleset for which the
     registration was accepted.  The list MUST contain at least one
     entry.   [If an error is being returned, this list MUST be
     omitted.]

The text in brackets is what I am proposing that you should add.
Otherwise you are giving the implementor conflicting instructions--a
MUST is a MUST, and has to be followed, but of course it can't be
followed if no rulesets match.  I'm just asking you to make that
explicit so that nobody gets confused.

Anyway, it sounds like we're converging.  Let me know if what I'm
saying still doesn't make sense.

--STATUS--

It looks like Vincent made the change he suggested, but did not follow
up on what I said in my last response, above (nobody replied to that
message).

I think this is an open issue that should be addressed.

--Ted--
In 4.5:

      If some
      locations within a batch request are outside the regulatory
      domain supported by the Database, the Database MAY return an OK
      response with available spectrum for only the valid locations;
      otherwise, if all locations within a batch request are outside
      the regulatory domain, the Database MUST respond with an
      OUTSIDE_COVERAGE error.

What should the database do if it doesn't follow the MAY?   Should it
return an OUTSIDE_COVERAGE error?   It seems to me that this MAY is going
to require some unclear heuristics on the side of the master device.  
Why isn't this a MUST?   I think if this were a MUST, it would be clear
how implementations should behave; by making it a MAY, there's a big gap
that I think will lead to interoperability problems as different
implementors make different choices about how to treat this situation.

--Vincent--
If it does not follow MAY, the assumption is that it would return
OUTSIDE_COVERAGE error.  I take your point about it being harder to
use for the device.

I don't think there would be objections to changing this to a MUST.

--Ted--

That would certainly satisfy my concern!   :)

--STATUS--

The proposed change has not been made to the document.

--Ted--
Section 3 describes spectrum-usage messages as purely informational.  
Section 4.5 says that the database can require that such messages be
sent.   Which is it: is it sometimes required, or always purely
informational?   Or does "purely informational" just mean that the
protocol provides no mechanism for tracking such notifications?  It would
be helpful if this were clearer.

--Vincent--
"purely informational" means that the it's just notifying the Database
what spectrum it intends to use and is not a request to the Database
to get permission to use that spectrum. Some regulators require this
notification.

I'll try to clarify the text.

--Ted--
Ah, that explains it.  Thanks.  Adding some text pretty much like what
you just wrote would address this comment nicely.

--Vincent--
Will do.

--STATUS--

Addressed in -15.

--Ted--
In 4.1, the database URI change spec seems incomplete.   Is there a time
when a database starts announcing its URI change after which it need no
longer provide service on the old URI?   I see Alissa asked a similar
question, so I imagine you could address both questions together.

--Vincent--
Yes, specifying a time is reasonable.

--STATUS--

Addressed in -15.

--Ted--
In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be
somewhat fluid.   I think you intend for it to mean one specific thing,
which might imply one of several other things.   But you don't say the
one thing that it means: instead you mention possible implications.   It
would be helpful to try to make this more explicit.

I think Stephen noticed this same problem, but to be clear, it appears
that section 4.5 says that when the master is sending a request on behalf
of a slave, it sends its own location.   But section 4.5.1 says that the
master sends the slave's location.   It appears that there are two
parameters, one being the master location, which is required, and the
other being the slave location, which is optional.   However, this is
never really stated explicitly; it might be helpful if it were.

--Vincent--
OK. UNSUPPORTED means that the Database does not support the device
(based on it type, model, etc.) or any rulesets indicated by the
Device. I'll update both.

--STATUS--

Addressed in -15.

--Ted--
In 4.6.1, it would help to have text that explains what it means to
validate a device.   It's certainly not required for interoperability,
but might be helpful for implementors of database servers.

--Vincent--
This is explained in the first paragraph of 4.6, I think.

   A Slave Device needs a Master Device to ask the Database on its
   behalf for available spectrum.  Depending on the ruleset, the Master
   Device also must validate with the Database that the Slave Device is
   permitted to operate. ...

--Ted--
Ah, okay.  The problem is that "validate the device" isn't obviously
connected to "validate with the database that the ..."  I see the
connection now, but it would help to make it clearer.

--Vincent--

Will do.

--STATUS--

Addressed in -15.

--Ted--
In 5.3, it's a little puzzling that antenna direction, radiation pattern,
gain and polarization aren't defined, because they seem like properties
that should have universal applicability, even if they are not required
in all cases.   Is this being left as future work, or is there some more
subtle reason why these haven't been defined explicitly?

--Vincent--
This is for future extension, rather than defining a whole set of things that
won't get used. Note that for mobile devices, direction/pattern/polarization
changes all the time and would be "crazy" to define rules based on these
characteristics. 

--Ted--
Right, just checking.

--STATUS--

addressed

--Ted--

In 5.11, power is expressed in dbm, which leads me to wonder if this is
the product of the antenna gain and the input power to the output
amplifier, or whether it's just the input power to the amplifier, or
whether it's being left intentionally ambiguous.

--Vincent--
Great question.

I believe this was left intentionally ambiguous, since each regulator
may choose to define the power in a different way. Typically, it's the
radiated power at the antenna, over some bandwidth, averaged over some
period of time (defined by the regulator).

Perhaps I should add the "Typically" statement to Section 5.11 that
describes Spectrum.

--Ted--

The problem with this is that if the meaning of the unit is different
depending on the regulatory regime, it might make life really
difficult for the maker of a device that has to operate in different
regimes.  I suppose makers of devices like this are used to this
problem, so maybe it's not really a problem in practice, but it would
certainly be nice to talk a bit about this in the document.

--Vincent--
I'll add it to the doc.

--STATUS--

I don't see a change to the document to address this point.