Adrian,
On Wed, Aug 20, 2014 at 12:40 PM, Adrian Farrel <[email protected]> wrote: > 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? > 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. > > 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." > Thanks for pointing that out. SHOULD should be relaxed to "is typically". > > 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). > 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. > > 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. > > Let me see if I can add some text to the "registration". -vince > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
