[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.
- [paws] Adrian Farrel's No Objection on draft-ietf… Adrian Farrel
- Re: [paws] Adrian Farrel's No Objection on draft-… Vincent Chen