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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 20 August 2014 19:40 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: paws@ietfa.amsl.com
Delivered-To: paws@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7091A06C5; Wed, 20 Aug 2014 12:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQRNg9c1Hv9I; Wed, 20 Aug 2014 12:40:33 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5709D1A06B0; Wed, 20 Aug 2014 12:40:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adrian Farrel <adrian@olddog.co.uk>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140820194033.9083.72875.idtracker@ietfa.amsl.com>
Date: Wed, 20 Aug 2014 12:40:33 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/UhitQZzsEJaQ0KVsR4xEo_89Row
Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org
Subject: [paws] Adrian Farrel's No Objection on draft-ietf-paws-protocol-14: (with COMMENT)
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws/>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 19:40:35 -0000

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.