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

[Vincent Chen <[e-mail]>]

Ted,

Thanks for the review.


On Thu, Aug 21, 2014 at 6:30 AM, Ted Lemon <[e-mail]> wrote:

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

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.



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

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


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


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



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


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

Yes, specifying a time is reasonable.


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

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.


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

Yes. I'll try to clean that up.


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


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


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


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


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



-- 
-vince