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

[Vincent Chen <[e-mail]>]

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 <[e-mail]> 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--
> 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.
>

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


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

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



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

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


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

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



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

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


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