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

From: "Ted Lemon" <[email-masked]>
Date: Thu, 21 Aug 2014 06:30:25 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-paws-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a cool document—I'm glad the IETF is working on this.   Please
don't take the following comments as anything other than an attempt to
address what I think are some relatively minor issues with the document,
hopefully easily addressed.

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?

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.

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.

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.

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

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.

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.

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.

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.

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?

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.

---

From: Vincent Chen <[email-masked]>
Date: Thu, 21 Aug 2014 17:30:39 -0700

Ted,

Thanks for the review.

> http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

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.

> the registration, it would be good to say so explicitly.

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

> stated a MUST, so you need to say that it doesn't apply in the case of

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.

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

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

> question, so I imagine you could address both questions together.

Yes, specifying a time is reasonable.

> would be helpful to try to make this more explicit.

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.

> never really stated explicitly; it might be helpful if it were.

Yes. I'll try to clean that up.

> whether you address it is entirely up to you.

This results from the terminology established in RFC6953.

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

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

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

>
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

-- 
-vince

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Aug 2014 21:06:09 -0400

On Aug 21, 2014, at 8:30 PM, Vincent Chen <[email-masked]> wrote:
> When it is preconfigured, there must be a preconfigured value for each ruleset.

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

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

> If it does not follow MAY, the assumption is that it would return OUTSIDE_COVERAGE error.

That would certainly satisfy my concern!   :)

> spectrum it intends to use and is not a request to the Database to get permission

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

> This results from the terminology established in RFC6953.

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

>    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.
 
> This is for future extension, rather than defining a whole set of things that

Right, just checking.

> I believe this was left intentionally ambiguous, since each regulator may choose to define
> 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!

---

From: Vincent Chen <[email-masked]>
Date: Fri, 22 Aug 2014 00:03:58 -0700

On Thu, Aug 21, 2014 at 6:06 PM, Ted Lemon <[email-masked]> wrote:

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

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.

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

Actually, REGISTRATION_RESP is returned only when there is not error,
so if it is returned, it must have one or more entries.

The "it MUST instead return an error" should suffice to clarify this?

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

Will do.

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

Will do.

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

I'll add it to the doc.

-- 
-vince

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2014 09:20:26 -0400

[Resent because I forgot to Cc everyone.]

On Aug 22, 2014, at 3:03 AM, Vincent Chen <[email-masked]> wrote:
> 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

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.

> The "it MUST instead return an error" should suffice to clarify this?

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.