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

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Sep 2014 22:26:27 -0400

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.

---

From: Vincent Chen <[email-masked]>
Date: Tue, 2 Sep 2014 22:27:15 -0700

Ted,

Sorry, I did let one go unaddressed. Please see answers to the other
discuss points (in blue).

-vince

On Tue, Sep 2, 2014 at 7:26 PM, Ted Lemon <[email-masked]> wrote:

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

--Vincent--
I added clarification to section 4.3 that preconfiguration is on a
per-ruleset
basis and a value for one cannot be used for another. I believe that
addressed
your original concern.

I did not add text about certification, since that's not PAWS, that's up to
the
regulatory domain to decide whether it needs to certify.

> There has been no change to the document that I can find that

--Vincent--
End of Section 4 (before 4.1) has the following asa global statement:

   In some cases, specific rulesets may place additional requirements on
   message parameters.  These additional requirements will be documented
   in the IANA PAWS Ruleset ID Registry.  (Section 9.1).  When a request
   message sent to the Database has missing parameters, whether they are
   required by PAWS or the applicable ruleset, the Database returns the
   MISSING (Section 5.17.3) error, along with data indicating the
   missing parameters.

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

--Vincent--
This was a change recently, because my original wording using "none" was
deemed
confusing. I'll try your wording.

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

--Vincent--
The issue is that this message is not used when there is an error. This
message
is returned only when there is no error, so, by definition, there must be
at least
one entry in the message.

I've added the following, where "instead" is supposed to indicate that
it's a different message that is returned when there is an error:

      If the Database does not support the device or any of the rulesets
      specified in the DeviceDescriptor, it MUST instead return an error
      with the UNSUPPORTED (Table 1) code in the error response.

> The proposed change has not been made to the document.

--Vincent--
Sorry. I let this slip. Modifying to:

       ...If some*, but not all,*
       locations within a batch request are outside the regulatory
       domain supported by the Database, the Database *MUST* return an OK
       response with available spectrum for only the valid locations;

> I don't see a change to the document to address this point.
Added the following text to Section 4.5.2 as a "global" statement:

   o  Each spectrum schedule specifies permissible power level for a
      duration defined by a pair of start and stop times.  The power
      levels typically refer to permissible EIRP over a resolution
      bandwidth.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Sep 2014 12:23:32 -0400

>       with the UNSUPPORTED (Table 1) code in the error response.

Okay, thanks.   Unfortunately "any" here is ambiguous as with the previous use.   You should either say "supports none of the rulesets" or "does not support one or more of the rulesets" depending on which you mean.

The other points appear either to have been addressed, or else you've proposed to address them in the next version, so please go ahead and spin that when the time is right and I will re-check.

Thanks!

---

From: Vincent Chen <[email-masked]>
Date: Fri, 5 Sep 2014 09:25:45 -0700

Ted,

Agreed. I'll upload new version shortly.

-vince

On Thu, Sep 4, 2014 at 9:23 AM, Ted Lemon <[email-masked]> wrote:

> Okay, thanks.   Unfortunately "any" here is ambiguous as with the previous
> use.   You should either say "supports none of the rulesets" or "does not
> support one or more of the rulesets" depending on which you mean.
>
> The other points appear either to have been addressed, or else you've
> proposed to address them in the next version, so please go ahead and spin
> that when the time is right and I will re-check.
>
> Thanks!
>
>

-- 
-vince

---

From: Ted Lemon <[email-masked]>
Date: Sat, 6 Sep 2014 11:10:06 -0400

Hm, so the new text in 4.4.2 is actually a bit broken:

   If the Database accepts none the
   registration for its supported rulesets, the Database MUST return the
   NOT_REGISTERED error (See Error Codes (Section 5.17)).

I think what you mean to say is this:

   If the Database accepts the registration for none of the
   specified rulesets, the Database MUST return the
   NOT_REGISTERED error (See Error Codes (Section 5.17)).

Aside from this one nit (sorry!) I think you have addressed all the points I raised.   I'm going to clear my DISCUSS, but please do address this one last nit!

---

From: Vincent Chen <[email-masked]>
Date: Sun, 7 Sep 2014 22:37:52 -0700

Ted,

>    NOT_REGISTERED error (See Error Codes (Section 5.17)).

LOL. That was the exact wording in Draft 12, but one of the ADs found it
confusing and suggested rewording.

>
> Aside from this one nit (sorry!) I think you have addressed all the points
> I raised.   I'm going to clear my DISCUSS, but please do address this one
> last nit!
>
>

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Sun, 7 Sep 2014 22:51:52 -0700

Ted,

Uploaded with your suggested text. Thanks!

-vince

On Sun, Sep 7, 2014 at 10:37 PM, Vincent Chen <[email-masked]> wrote:

>> Aside from this one nit (sorry!) I think you have addressed all the
>> points I raised.   I'm going to clear my DISCUSS, but please do address
>> this one last nit!
>>
>>
>
>
> --
> -vince
>

-- 
-vince

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Sep 2014 09:44:38 -0400

On Sep 8, 2014, at 1:37 AM, Vincent Chen <[email-masked]> wrote:
> LOL. That was the exact wording in Draft 12, but one of the ADs found it confusing and suggested rewording.

I agree that it's not ideal, but the new wording was actually ambiguous, whereas the wording I offered is merely confusing. :)

How about:

   If the Database examines the registration for each
   ruleset and can find no ruleset for which it can
   accept registration, the Database MUST return the
   NOT_REGISTERED error (See Error Codes (Section 5.17)).

I think this is less confusing, but lacks the ambiguity of the new text that the other AD proposed. :)

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Sep 2014 19:51:22 +0300

> text that the other AD proposed. :)

The other AD had actually proposed "If the database fails to accept
the registration for all rulesets..."

--
Other AD

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Sep 2014 13:02:27 -0400

> the registration for all rulesets..."

Ah, which isn't what the authors appear to have intended, hence the change to "any".   Sigh.   Math is hard.   :)

---

From: Vincent Chen <[email-masked]>
Date: Mon, 8 Sep 2014 10:09:57 -0700

Barry, Ted,

Ouch....I must have remembered wrong.
I do mean that if registration fails for all....

Please take a look at draft 17 wording and see if I should adjust again.

Thanks.

-vince

-- 
-vince

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Sep 2014 13:34:02 -0400

The new text seems good to me, and better than what I proposed.   Thanks!