Subject: [paws] Adrian Farrel's No Objection on draft-ietf-paws-protocol-14: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Aug 2014 12:40:33 -0700

Adrian Farrel has entered the following ballot position for
draft-ietf-paws-protocol-14: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Stephen asked a geolocation question about RFC 6953 as it was being
processed to try to establish whether the location information supplied
for a query needed to be the location of the querrier or the location
about which the querry is being made. Going back to the text in 1.2 of
6953, it is pretty clear that the intent is to issue a queery that
relates to the whitespace at a location.

Given this, I agree with Stephen that including location info in the
INIT_REQ and REGISTRATION_REQ seems unnecessary. It seems to be being
used as some form of authorisation check, and I don't see how that is
safe or valid. But also I don't see what stops the sender from lying.
Surely the important thing is about where the whitespace is available,
not from where the requester operates?

But even in 4.5.1 there is some confusion...

   location:  The GeoLocation (Section 5.1) for the device requesting
      available spectrum.  The location SHOULD be the current location
      of the device, but more precisely, the location of the radiation
      center of the device's antenna.  When the request is made by the
      Master Device on its own behalf, the location is that of the
      Master Device and it is REQUIRED.  When the request is made by the
      Master Device on behalf of a Slave Device, the location is that of
      the Slave Device and it is OPTIONAL (see also
      masterDeviceLocation).  The location may be an anticipated
      position of the device to support mobile devices, but its use
      depends on the ruleset.  If the location specifies a region,
      rather than a point, the Database MAY return an error with the
      UNIMPLEMENTED (Table 1) code, if it does not implement query by
      region.

I don't see why you have SHOULD given the subsequent lowercase may.
Surely you need "the location it the location about which the enquiry
is being made."

Reading all this and going back to 6953 I am not sure I understand the
difference between having permission to operate on a frequency at a 
location (which seems to be granted by registration) and discovering
which frequencies are available (which seems to be determined by
AVAIL_SPECTRUM_RESP).

Clearly I am missing something in my read through. If you think it is
already covered, that's fine. But if not, perhaps you could add some
text to explain things.

---

From: Vincent Chen <[email-masked]>
Date: Thu, 21 Aug 2014 00:10:42 -0700

Adrian,

> not from where the requester operates?

Please see my response to Stephen regarding registration.

 Location is required for both INIT_REQ and REGISTRATION_REQ, because the
 DB must determine which ruleset is applicable (based on location) before
it can
 return the proper set of information.

 Especially for INIT_REQ, the DB should respond with only the ruleset IDs
that are applicable
 for the location.

Also, registration, at least for FCC, is for fixed devices and is for "a
device at a location", not
the registration of a device.

> Surely you need "the location it the location about which the enquiry

Thanks for pointing that out. SHOULD should be relaxed to "is typically".

> which frequencies are available (which seems to be determined by

As mentioned in my reply to Stephen, registration is simply to tell FCC
where high-power devices are operating so that it can contact the operator
to shut down if there are problems. The spectrum it's allowed to use still
needs to be retrieved via AVAIL_SPECTRUM_RESP, since that can change
on a daily basis.

Registration does not include what spectrum the device intends to use.

> already covered, that's fine. But if not, perhaps you could add some
Let me see if I can add some text to the "registration".

-vince

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

-- 
-vince