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

[Ted Lemon <[e-mail]>]

On Aug 21, 2014, at 8:30 PM, Vincent Chen <[e-mail]> wrote:
>> 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?
> 
> 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.

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

> 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.
> 
> Ah, right. There is language from INIT_RESP that needs to be repeated here.
> 
>        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.

That doesn't fix it, though—you need to fix the other MUST to say "unless there's an error" or words to that effect.

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

That would certainly satisfy my concern!   :)

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

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

> I have to confess that the use of "master" and "slave" throughout this
> document makes me quite uncomfortable in reading it.   It would really be
> preferable to use terms that have less painful history associated with
> them, like "core" and "leaf" or "coordinator" and "supplicant."   I
> realize this is a matter of taste, and I do not at all mean to suggest
> that there's anything wrong with the use of these terms, which are
> certainly common in the computing industry.   This is just a comment, and
> whether you address it is entirely up to you.
> 
> This results from the terminology established in RFC6953.

I guess I should have complained sooner... :}

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

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

Right, just checking.

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

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.

Thanks for the quick response!