From Internet-Drafts@ietf.org Mon Mar 4 12:29:44 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EB821F9063; Mon, 4 Mar 2013 12:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEKw1dmqQTEI; Mon, 4 Mar 2013 12:29:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFE321F9061; Mon, 4 Mar 2013 12:29:43 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.41 Message-ID: <20130304202943.17510.25297.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2013 12:29:43 -0800 Cc: paws@ietf.org Subject: [paws] I-D ACTION:draft-ietf-paws-problem-stmt-usecases-rqmts-14.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:29:44 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol to Access WS database Working Group of the IETF. Title : Protocol to Access White Space (PAWS) Database: Use Cases and Requirements Author(s) : A. Mancuso, et al Filename : draft-ietf-paws-problem-stmt-usecases-rqmts Pages : 23 Date : March 4, 2013 Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space." The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of whitespace information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-paws-problem-stmt-usecases-rqmts"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-03-04122943.I-D@ietf.org> --NextPart-- From stpeter@stpeter.im Wed Mar 6 10:06:17 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1E21F88BE for ; Wed, 6 Mar 2013 10:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.353 X-Spam-Level: X-Spam-Status: No, score=-101.353 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDDsVn88GcYT for ; Wed, 6 Mar 2013 10:06:12 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8187421F87F3 for ; Wed, 6 Mar 2013 10:06:09 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 221E94004E for ; Wed, 6 Mar 2013 11:14:23 -0700 (MST) Message-ID: <51378592.2040408@stpeter.im> Date: Wed, 06 Mar 2013 11:06:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: paws@ietf.org X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [paws] JCARDCAL WG X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:06:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, in case you missed it, we've formed a JCARDCAL Working Group to define JSON representations of both vCard and iCalendar information: https://datatracker.ietf.org/wg/jcardcal/charter/ Given past discussions in the PAWS WG, I figure that some people here might be interested in this initiative. If so, please join the jcardcal@ietf.org mailing list: https://www.ietf.org/mailman/listinfo/jcardcal The working group aims to complete its work in the next few months, so your timely participation would be very much appreciated. :-) Thanks! Peter, co-chair - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRN4WSAAoJEOoGpJErxa2pRP0QAIBMAD6kY39t0cnMtONvhODN a5Zvr3ZphSktrHSyM800Fuo9MblFKGCY15hhy2A8gZYRi7tOj7RD12v0rf2QSXEZ LMm7aGow7LLsNSpI4JbPRFnYVLbEQk8Id89n1AwvKMAOTqX7OT71pvvXQiroNO3T rUUi6JDNXXwL/BkFUHFscjLLQiZTMBe8Exri33Y/SIPH1fmh468K6j5enCDjfz+9 ljoZEtgNWnZ69CXccx+94XWPZwNkENcYSh8RsilgVIkhlVh4KVWDeGr487rwxcgU uXW7xZuCOFzKXJy5aXtVOagMBMKM94HNiJP7OpMRUwn9Z3O6dcy4s7iIEsJve4qC CtCDLcPDpo2/DjJYO5io/W2cc5xdfda8gg+w7wCWiVkwcSecMb3w7eGekg6OO8kP Svi142X7rlv2BnGF+uOA3/bZwsW58ZQmu6D//UsR0mibr+KE/HiayRkx9zsUiG+V 3xZG+NU5nEngREAVt3Cg9HuXoMTXyrprxStLYuUCZzC2aRKM3cNNjyEb2yevE9JI NiFrfKpuHI4Ser4xZ9XHVOGQQ8DhxMN1Df/oGmlRnq9vj5sCcZwMO1RAZxDd84XX /wr1tZPXkHMsoL9+iugwq0IGTVZSAKvIe7JwlBH8moTD4zMkGTBA84ivnJBZ5E38 OCKaLXuyvQBCH9KMKhvi =xj0e -----END PGP SIGNATURE----- From Gabor.Bajko@nokia.com Wed Mar 6 19:57:25 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E3111E80A3 for ; Wed, 6 Mar 2013 19:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j383NIfCSd84 for ; Wed, 6 Mar 2013 19:57:25 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id ADE3E21F882F for ; Wed, 6 Mar 2013 19:57:24 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r273vLpp004776 for ; Thu, 7 Mar 2013 05:57:21 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Mar 2013 05:57:21 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.108]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0318.003; Thu, 7 Mar 2013 03:57:19 +0000 From: To: Thread-Topic: agenda for the Orlando meeting uploaded Thread-Index: Ac4a58egUkdLiNR2QWyV6PkxX65NIQ== Date: Thu, 7 Mar 2013 03:57:18 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476021AA75E@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.32.162] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AA75E008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Mar 2013 03:57:21.0164 (UTC) FILETIME=[DE6AECC0:01CE1AE7] X-Nokia-AV: Clean Subject: [paws] agenda for the Orlando meeting uploaded X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 03:57:25 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AA75E008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/86/agenda/agenda-86-paws - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AA75E008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/86/agenda/agenda-86-paws

 

-     &= nbsp;    Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AA75E008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Mon Mar 11 11:55:44 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D221F8CD6 for ; Mon, 11 Mar 2013 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NIgJYR+pHkY for ; Mon, 11 Mar 2013 11:55:43 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4123321F8CD4 for ; Mon, 11 Mar 2013 11:55:43 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2BItcPC005989 for ; Mon, 11 Mar 2013 20:55:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Mar 2013 20:55:39 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.108]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0328.011; Mon, 11 Mar 2013 18:55:39 +0000 From: To: Thread-Topic: solution document status Thread-Index: Ac4eib6Ttl/V4gXQRrCamGbGrj+LTA== Date: Mon, 11 Mar 2013 18:55:38 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476021AD2A9@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.33.202] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AD2A9008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2013 18:55:39.0416 (UTC) FILETIME=[05EE8180:01CE1E8A] X-Nokia-AV: Clean Subject: [paws] solution document status X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:55:44 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AD2A9008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Vince, the editor, will present tomorrow the solution document. He is not a= ware of any remaining open issues. I would like to ask everybody on this list to take a look at the solution d= ocument (http://www.ietf.org/id/draft-ietf-paws-protocol-03.txt) and send t= o the list asap, or be prepared to go to the mike if you are aware of any o= utstanding open issues in the doc. Thanks, Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AD2A9008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Vince, the editor, will present tomorrow the solutio= n document. He is not aware of any remaining open issues.

I would like to ask everybody on this list to take a= look at the solution document (http://www.ietf.org/id/draft-ietf-paws-protocol-03.= txt) and send to the list asap, or be prepared to go to the mike if you are aware of any outstanding open = issues in the doc.

 

Thanks, Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AD2A9008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Mon Mar 11 12:06:07 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4735521F8EDA for ; Mon, 11 Mar 2013 12:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0WkKaeSGLDH for ; Mon, 11 Mar 2013 12:06:06 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 425E121F8ECB for ; Mon, 11 Mar 2013 12:06:06 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2BJ65LL012967 for ; Mon, 11 Mar 2013 21:06:05 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.49]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Mar 2013 21:06:04 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.108]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.02.0328.011; Mon, 11 Mar 2013 19:06:03 +0000 From: To: Thread-Topic: remote participation Thread-Index: Ac4eil/AyFqfwVnEQuKfUkHTF4/tTg== Date: Mon, 11 Mar 2013 19:06:03 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476021AD2CA@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.33.202] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AD2CA008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2013 19:06:04.0389 (UTC) FILETIME=[7A71D150:01CE1E8B] X-Nokia-AV: Clean Subject: [paws] remote participation X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 19:06:07 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AD2CA008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PAWS session @Orlando will be on Tuesday, March 12th, 1pm Eastern time. Once again, remote participation to the PAWS session will be provided by us= ing Meetecho for slide sharing and video (find the paws on http://ietf86.co= nf.meetecho.com/ and click join), For interactive audio, we'll use Skype. Please connect to the ietf.paws sky= pe id 5 min before the session starts. Thanks, Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AD2CA008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PAWS session @Orlando will be on Tuesday, March 12th, 1pm Eastern time.

 

Once again, remote participation to the PAWS session= will be provided by using Meetecho for slide sharing and video (find the p= aws on http://ietf86.conf.meetecho.co= m/ and click join),

 

For interactive audio, we’ll use Skype. Please= connect to the ietf.paws skype id  5 min before the session starts.

 

Thanks, Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AD2CA008AM1MPN1006mg_-- From ietf@meetecho.com Mon Mar 11 16:04:24 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B3D21F8F3C for ; Mon, 11 Mar 2013 16:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E91NGHRQbufX for ; Mon, 11 Mar 2013 16:04:24 -0700 (PDT) Received: from smtpdg5.aruba.it (smtpdg223.aruba.it [62.149.158.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4101021F8F0A for ; Mon, 11 Mar 2013 16:04:22 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd02.ad.aruba.it with bizsmtp id AP4K1l00K0wzZHu01P4M6m; Tue, 12 Mar 2013 00:04:21 +0100 Date: Mon, 11 Mar 2013 19:03:46 -0700 (PDT) From: Meetecho Team To: paws@ietf.org Message-ID: <16337204.9.1363053826569.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8_14884549.1363053826568" Subject: [paws] Meetecho support for PAWS session X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:04:24 -0000 ------=_Part_8_14884549.1363053826568 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the PAWS WG meeting session. Access to the on-line session (including audio and video streams) will be available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/paws The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_8_14884549.1363053826568-- From ietf@meetecho.com Tue Mar 12 12:41:33 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A247011E8111 for ; Tue, 12 Mar 2013 12:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjBH73CRrMDZ for ; Tue, 12 Mar 2013 12:41:33 -0700 (PDT) Received: from smtpdg2.aruba.it (smtpdg220.aruba.it [62.149.158.220]) by ietfa.amsl.com (Postfix) with ESMTP id 921BE11E80F0 for ; Tue, 12 Mar 2013 12:41:32 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd01.ad.aruba.it with bizsmtp id AjhT1l00C2w8SR601jhVtH; Tue, 12 Mar 2013 20:41:30 +0100 Date: Tue, 12 Mar 2013 15:41:26 -0400 (EDT) From: Meetecho Team To: paws@ietf.org Message-ID: <13238549.1.1363117286124.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_2614099.1363117286079" Subject: [paws] PAWS session recording available X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:41:33 -0000 ------=_Part_0_2614099.1363117286079 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the PAWS WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#PAWS In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_2614099.1363117286079-- From teco@inf-net.nl Tue Mar 12 13:39:19 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BEF21F85EB for ; Tue, 12 Mar 2013 13:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYcCcBxKwhlo for ; Tue, 12 Mar 2013 13:39:19 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4007121F85AC for ; Tue, 12 Mar 2013 13:39:18 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id rr4so247855pbb.41 for ; Tue, 12 Mar 2013 13:39:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer:x-gm-message-state; bh=eADGIu3lX3zZF6bn5PR+dzL/D+4BKUKbLGYEWwenT0I=; b=Scr66gszBb+sWMhnMIPSpBwP4Kk7nbZhpyw1LWUHaLDv0jY+HC9fsDd74ddF0erLSZ m7EtV1ahRB7vkk3sBaqWGshCtgkzC4z4kCOa66wKpOHH6kQmOEzZrjUMFGQKKv/XVN6u bnalbv9uzt/yOEY7tqNcigIrypuZQcS5xUmTMrxeq16RkQOwQDjUxDO2LNZd91nPVThM edHYtw35sIOHutPzZu/I6EAzPKq3j8JenomPZEhjEpniIvphr7fI0x+S0BHZVVyGYoAb OrXKLy0xg2xqCq/XugNjeaPFU/qLXQvg3LGOhPyICO8BmuhF2Eh26Kf7ICcj9CYHLkz3 TBOw== X-Received: by 10.68.194.8 with SMTP id hs8mr17636766pbc.44.1363120756936; Tue, 12 Mar 2013 13:39:16 -0700 (PDT) Received: from ?IPv6:2001:df8::16:195e:cad2:1278:8e3f? ([2001:df8:0:16:195e:cad2:1278:8e3f]) by mx.google.com with ESMTPS id kb3sm26426192pbc.21.2013.03.12.13.39.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 13:39:16 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <888FE0E2-AE2B-426F-B580-45893E60490B@inf-net.nl> Date: Tue, 12 Mar 2013 16:39:12 -0400 To: paws@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnzJmcLCYoJ2L+A1jXGV66Vqi0PN9kkeLrdYtlX6m8ixDcdkCULxcQmGZNQvEhj5qL4E+n7 Subject: [paws] draft-wei-paws-database-discovery-00.txt - Bootstrapping LoST X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:39:19 -0000 More on the comment I made on the mic, on LoST dependency on for example = DHCP options on access networks. The draft suggests configured or hard-coded LoST bootstrapping, also for = setting up some trust. This takes away some of my concerns.=20 Still the question who sets up the WSDB Discovery Server infrastructure. = I think the draft suggests the vendor of the radio equipment offers = such, or at least the first queried Discovery Server. Looks fine to me. Teco= From hannes.tschofenig@gmx.net Tue Mar 12 14:29:59 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C4911E80AE for ; Tue, 12 Mar 2013 14:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.894 X-Spam-Level: X-Spam-Status: No, score=-101.894 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh-o3kLGR40h for ; Tue, 12 Mar 2013 14:29:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 70F0511E80A6 for ; Tue, 12 Mar 2013 14:29:55 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lzmgv-1UsFQA1VZ5-0151mH for ; Tue, 12 Mar 2013 22:29:53 +0100 Received: (qmail invoked by alias); 12 Mar 2013 21:29:52 -0000 Received: from dhcp-1372.meeting.ietf.org (EHLO dhcp-1372.meeting.ietf.org) [130.129.19.114] by mail.gmx.net (mp010) with SMTP; 12 Mar 2013 22:29:52 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19RQitDb9ZRHnHDj6kaWK/wC6Zz67vNjP5C3cH3Vk 10uVoM9d4y9qmY User-Agent: K-9 Mail for Android In-Reply-To: <888FE0E2-AE2B-426F-B580-45893E60490B@inf-net.nl> References: <888FE0E2-AE2B-426F-B580-45893E60490B@inf-net.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----OBLLF94BRX7N7Z7V4C7EQ4R1J5SW54" From: hannes.tschofenig@gmx.net Date: Tue, 12 Mar 2013 23:29:50 +0200 To: Teco Boot ,paws@ietf.org Message-ID: <5cf8ee0c-75b4-4c12-9481-b42dc85fce3a@email.android.com> X-Y-GMX-Trusted: 0 Subject: Re: [paws] draft-wei-paws-database-discovery-00.txt - Bootstrapping LoST X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 21:29:59 -0000 ------OBLLF94BRX7N7Z7V4C7EQ4R1J5SW54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Teco, I just wanted to confirm an observation that you had already noticed. The LoST specification does not rely on DHCP-based discovery. The story for who operates the discovery servers as well as the databases is likely going to be different in different countries based on regulation. Ciao Hannes Teco Boot wrote: >More on the comment I made on the mic, on LoST dependency on for >example DHCP options on access networks. >The draft suggests configured or hard-coded LoST bootstrapping, also >for setting up some trust. This takes away some of my concerns. >Still the question who sets up the WSDB Discovery Server >infrastructure. I think the draft suggests the vendor of the radio >equipment offers such, or at least the first queried Discovery Server. >Looks fine to me. > >Teco >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------OBLLF94BRX7N7Z7V4C7EQ4R1J5SW54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Teco, I just wanted to confirm an observation that you had already noticed. The LoST specification does not rely on DHCP-based discovery.
The story for who operates the discovery servers as well as the databases is likely going to be different in different countries based on regulation.

Ciao
Hannes

Teco Boot <teco@inf-net.nl> wrote:
More on the comment I made on the mic, on LoST dependency on for example DHCP options on access networks.
The draft suggests configured or hard-coded LoST bootstrapping, also for setting up some trust. This takes away some of my concerns. 
Still the question who sets up the WSDB Discovery Server infrastructure. I think the draft suggests the vendor of the radio equipment offers such, or at least the first queried Discovery Server. Looks fine to me.

Teco

paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------OBLLF94BRX7N7Z7V4C7EQ4R1J5SW54-- From kalle.kuismanen@fairspectrum.com Tue Mar 12 19:22:11 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FE011E812E for ; Tue, 12 Mar 2013 19:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4dlTwFoY3W2 for ; Tue, 12 Mar 2013 19:22:10 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 342D411E8113 for ; Tue, 12 Mar 2013 19:22:09 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h1so587530oag.31 for ; Tue, 12 Mar 2013 19:22:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=aRFCbOUA6/Nl13CrXEnbsj8I2MgH087F6Z0jpt2oRYY=; b=aEm/LCsEmwKOo/sTf/kBrDh2Fxm1YRERBBQf499oJI5Oiul2KVOHfQx0p56xhcuoag EtOlOM9yk5am/snNn7DUbDSrnMExVFDB00i6yLBcYhFIvEq1g7jwTa0H/p2rSz9zrNG7 VRlMTfgwr+HL+qR0VljRjueX+Frj/FdYyHNbugHInxlktLLRicVZlRXVtyr7tyVPhzyO ERst648hp00KW0SVyocIDj6cPFP4ZEwotgCVHwL+hjrclhdQzpw8/3b9QF0rcA0FdwWG S6YhK20Qm4+Q8kAOhCZkXvMsFmVoBCzj+qT/1lEoeWB0Zkj+UlRGi/jnP28nMjq7hR14 QvnA== MIME-Version: 1.0 X-Received: by 10.60.10.102 with SMTP id h6mr14030393oeb.14.1363141329217; Tue, 12 Mar 2013 19:22:09 -0700 (PDT) Received: by 10.60.135.2 with HTTP; Tue, 12 Mar 2013 19:22:09 -0700 (PDT) Date: Wed, 13 Mar 2013 04:22:09 +0200 Message-ID: From: Kalle Kuismanen To: paws@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1f4aeb50ebd04d7c5126f X-Gm-Message-State: ALoCoQmOhCCI4c+37OfpNYlbppcFJq98S6PnwINOmpnPGa8ECscZe4bZwxFF4JjxQ3ExNpLAVw25 Subject: [paws] PAWS Location info using RFC5491 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 02:22:11 -0000 --e89a8fb1f4aeb50ebd04d7c5126f Content-Type: text/plain; charset=ISO-8859-1 Hello everybody, First of all, thank you for interesting presentations in Orlando, I hope weather was bit warmer than here in Finland where I was doomed to watch them. I'm not sure how much discussion you've had on the method used to describe location in this draft. So I apologize in advance if this issue is closed. This draft of PAWS protocol uses JSON syntax, but RFC5491, which is used to describe location is XML based protocol. This causes a problem for us implementers, because this hybrid loses unambiguity i.e. I cannot verify the location entries against json-schema because it doesn't exist. As an alternative I think something like following would be useful as a replacement or an alternative. Most implementations of geospatial databases understand ISO/IEC 13249-3:2011 WKT and BKT format for geometric representations and there are a lot of ready made code to handle it. http://en.wikipedia.org/wiki/Well-known_text#Well-known_binary so instead of "location": { "point": { "center": {"latitude": 37.0005, "longitude": -101.3005} } } one could enter "location": { "wkt": "POINT (101.3005 37.0005)", "srid":4326 } or WKB equivalent. Just a note: (srid 4326 is the id for WGS84) Advantage of this is that since WKT and WKB are understood by most geospatial databases there is very little parsing to do, validation is trivial and as a bonus it can be directly entered as a part of a query. Protocol covers other geometric shapes. It doesn't cover ellipse though, but then again it's not very common feature in geospatial databases and ellipses need to be converted into polygons anyway to make geospatial queries. Cheers, Kalle Kuismanen Fairspectrum --e89a8fb1f4aeb50ebd04d7c5126f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello everybody,

First of all, thank you for interesting= presentations in Orlando, I hope weather was bit warmer than here in Finla= nd where I was doomed to watch them.

I'm not s= ure how much discussion you've had on the method used to describe locat= ion in this draft. So I apologize in advance if this issue is closed.

This draft of PAWS protocol uses JSON syntax, but RFC54= 91, which is used to describe location is XML based protocol.=A0
= This causes a problem for us implementers, because this hybrid loses=A0
unambiguity i.e. I cannot verify the location entries against json-sch= ema because it doesn't exist.

As an alternativ= e I think something like following would be useful as a replacement or an a= lternative.

Most implementations of geospatial databases understand= =A0ISO/IEC 13249-3:2011=A0WKT and= BKT format for geometric representations and there are a lot of ready made= code to handle it.


so instead of=A0
"= location": {
=A0"point": {
=A0"center": {"latitu= de": 37.0005, "longitude": -101.3005}
=A0} }
=

one could enter

&qu= ot;location": {
=A0"wkt": "PO= INT (101.3005=A037.0005)",
=A0"srid":4326=A0}

or WKB equivalent. Just a note: (sri= d 4326 is the id for WGS84)

Advantage of this is that since WKT and WKB are underst= ood by most geospatial databases there is very little parsing to do, valida= tion is trivial and as a bonus it can be directly entered as a part of a qu= ery. Protocol covers other geometric shapes.

It doesn't cover ellipse though, but then again it&= #39;s not very common feature in geospatial databases and ellipses need to = be converted into polygons anyway to make geospatial queries.

Cheers,
Kalle Kuismanen
Fairspectrum

--e89a8fb1f4aeb50ebd04d7c5126f-- From internet-drafts@ietf.org Wed Mar 13 09:49:12 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC63A21F8D9A; Wed, 13 Mar 2013 09:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe6IceL--48D; Wed, 13 Mar 2013 09:49:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 224CD21F8D9C; Wed, 13 Mar 2013 09:49:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130313164912.29610.2065.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2013 09:49:12 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:49:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access White Space (PAWS) Database: Use Case= s and Requirements Author(s) : Anthony Mancuso Scott Probasco Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt Pages : 23 Date : 2013-03-13 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space." The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of whitespace information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-rq= mts-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Gabor.Bajko@nokia.com Wed Mar 13 12:54:41 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ADB21F8653 for ; Wed, 13 Mar 2013 12:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S200CIefWHnc for ; Wed, 13 Mar 2013 12:54:40 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id DA4F121F874D for ; Wed, 13 Mar 2013 12:54:39 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2DJsVM8001470; Wed, 13 Mar 2013 21:54:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Mar 2013 21:54:31 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.108]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0328.011; Wed, 13 Mar 2013 19:54:30 +0000 From: To: , Thread-Topic: [paws] PAWS Location info using RFC5491 Thread-Index: AQHOH5GXEaJQqVUWkUqvAGdzJbzHc5ikCVXg Date: Wed, 13 Mar 2013 19:54:29 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476021AE4A5@008-AM1MPN1-006.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.18.222] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AE4A5008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Mar 2013 19:54:31.0250 (UTC) FILETIME=[93E51B20:01CE2024] X-Nokia-AV: Clean Subject: Re: [paws] PAWS Location info using RFC5491 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:54:41 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AE4A5008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One of the authors of the cited RFC was kind enough to respond to this emai= l, and I am forwarding his mail: From: ext Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Wednesday, March 13, 2013 6:43 AM Suggestions of this nature are extremely common. After all, there are very= many standardized representations of location. I'd be surprised if you ha= ven't already had suggestions for GeoJSON, KML, 3GPP TS 23.032, or one of t= he many other commonly used serializations of location. WKT is very much u= nsurprising. The problem with WKT is that it was developed with SQL in mind. It's a str= uctured textual format. That means that processors are required to underst= and the parsing rules in order to extract the information they need. Use o= f WKT in paws would require considerable effort to properly profile the for= mat. Any advantage gained by those who are implementing with GIS databases= is far outweighed by the cost to those implementations that consume the in= formation. I haven't been tracking paws, so I was encouraged to see that the handling = of location was largely sensible and pragmatic. In the complexity/value tr= ade-off, I might have chosen circle over ellipse, though ellipse is clearly= valuable to the extent that it is the natural product of a GPS trilaterato= r and a good fit for a cell sector coverage area. Reading through the paws protocol draft, the following jumped out at me: confidence: The location confidence level, as an integer percentage, MAY be required, depending on the regulatory domain. When the parameter is optional, its default value is 100. This values is only meaningful when GeoLocation refers to a point. 100 is an invalid value for confidence. Confidence is an estimate of the p= robability that the provided uncertainty region includes the measurand. Cl= aiming a probability of 1 for confidence is never possible in practice. Setting the value to 100 by default is actually nonsensical. 95 might be a= better default if you care about RFC 4119/5985 interactions. 67 would be = a better fit for what most GPS trilaterators produce. That last sentence is directly wrong. Assuming point positioning, it's nev= er possible to have any more than zero confidence in an estimate that does = not have uncertainty. I was somewhat surprised to see confidence in the draft. We didn't add it = to RFC 5491 because it isn't well understood and it makes things like compa= risons difficult. It's not actually possible, without making assumptions, = to compare locations that have different confidence values. From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Kalle Kuismanen Sent: Tuesday, March 12, 2013 7:22 PM To: paws@ietf.org Subject: [paws] PAWS Location info using RFC5491 Hello everybody, First of all, thank you for interesting presentations in Orlando, I hope we= ather was bit warmer than here in Finland where I was doomed to watch them. I'm not sure how much discussion you've had on the method used to describe = location in this draft. So I apologize in advance if this issue is closed. This draft of PAWS protocol uses JSON syntax, but RFC5491, which is used to= describe location is XML based protocol. This causes a problem for us implementers, because this hybrid loses unambiguity i.e. I cannot verify the location entries against json-schema b= ecause it doesn't exist. As an alternative I think something like following would be useful as a rep= lacement or an alternative. Most implementations of geospatial databases understand ISO/IEC 13249-3:201= 1 WKT and BKT format for geometric representations and there are a lot of r= eady made code to handle it. http://en.wikipedia.org/wiki/Well-known_text#Well-known_binary so instead of "location": { "point": { "center": {"latitude": 37.0005, "longitude": -101.3005} } } one could enter "location": { "wkt": "POINT (101.3005 37.0005)", "srid":4326 } or WKB equivalent. Just a note: (srid 4326 is the id for WGS84) Advantage of this is that since WKT and WKB are understood by most geospati= al databases there is very little parsing to do, validation is trivial and = as a bonus it can be directly entered as a part of a query. Protocol covers= other geometric shapes. It doesn't cover ellipse though, but then again it's not very common featur= e in geospatial databases and ellipses need to be converted into polygons a= nyway to make geospatial queries. Cheers, Kalle Kuismanen Fairspectrum --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AE4A5008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One of the authors of the cited RFC was= kind enough to respond to this email, and I am forwarding his mail:

 

 

From: ext Martin Thomson [mailto:martin.thomson@gmai= l.com]
Sent: Wednesday, March 13, 2013 6:43 AM

Suggestions of this nature are extremely common.&= nbsp; After all, there are very many standardized representations of locati= on.  I'd be surprised if you haven't already had suggestions for GeoJS= ON, KML, 3GPP TS 23.032, or one of the many other commonly used serializations of location.  WKT is very much uns= urprising.

 

The problem with WKT is that it was developed wit= h SQL in mind.  It's a structured textual format.  That means tha= t processors are required to understand the parsing rules in order to extra= ct the information they need.  Use of WKT in paws would require considerable effort to properly profile the format.&nbs= p; Any advantage gained by those who are implementing with GIS databases is= far outweighed by the cost to those implementations that consume the infor= mation.

 

I haven't been tracking paws, so I was encouraged= to see that the handling of location was largely sensible and pragmatic.&n= bsp; In the complexity/value trade-off, I might have chosen circle over ell= ipse, though ellipse is clearly valuable to the extent that it is the natural product of a GPS trilaterator and a g= ood fit for a cell sector coverage area.

 

Reading through the paws protocol draft, the foll= owing jumped out at me:

 

   confidence:  The location confi= dence level, as an integer percentage,

      MAY be required, d= epending on the regulatory domain.  When the

      parameter is optio= nal, its default value is 100.  This values is

      only meaningful wh= en GeoLocation refers to a point.

 

100 is an invalid value for confidence.  Con= fidence is an estimate of the probability that the provided uncertainty reg= ion includes the measurand.  Claiming a probability of 1 for confidenc= e is never possible in practice.

 

Setting the value to 100 by default is actually n= onsensical.  95 might be a better default if you care about RFC 4119/5= 985 interactions.  67 would be a better fit for what most GPS trilater= ators produce.

 

That last sentence is directly wrong.  Assum= ing point positioning, it's never possible to have any more than zero confi= dence in an estimate that does not have uncertainty.

 

I was somewhat surprised to see confidence in the= draft.  We didn't add it to RFC 5491 because it isn't well understood= and it makes things like comparisons difficult.  It's not actually po= ssible, without making assumptions, to compare locations that have different confidence values.

 

 <= /p>

 <= /p>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Kalle Kuismanen
Sent: Tuesday, March 12, 2013 7:22 PM
To: paws@ietf.org
Subject: [paws] PAWS Location info using RFC5491

 

Hello everybody,

 

First of all, thank you for interesting presentation= s in Orlando, I hope weather was bit warmer than here in Finland where I wa= s doomed to watch them.

 

I'm not sure how much discussion you've had on the m= ethod used to describe location in this draft. So I apologize in advance if= this issue is closed.

 

This draft of PAWS protocol uses JSON syntax, but RF= C5491, which is used to describe location is XML based protocol. =

This causes a problem for us implementers, because t= his hybrid loses 

unambiguity i.e. I cannot verify the location entrie= s against json-schema because it doesn't exist.

 

As an alternative I think something like following w= ould be useful as a replacement or an alternative.

 

Most implementations of geospatial databases underst= and ISO/IEC 13249-3:2011 WKT a= nd BKT format for geometric representations and there are a lot of ready made code to handle it.

 

 

so instead of 

"location": {

 "point": {

 "center": {"latitude": 37.= 0005, "longitude": -101.3005}

 } }

 

one could enter

 

"location": {

 "wkt": "POINT (101= .3005 37.0005)",

 "srid":4326 = ;}

 

or WKB equivalent. Just a note: (srid 4326 is the id= for WGS84)

 

Advantage of this is that since WKT and WKB are unde= rstood by most geospatial databases there is very little parsing to do, val= idation is trivial and as a bonus it can be directly entered as a part of a= query. Protocol covers other geometric shapes.

 

It doesn't cover ellipse though, but then again it's= not very common feature in geospatial databases and ellipses need to be co= nverted into polygons anyway to make geospatial queries.

 

Cheers,

Kalle Kuismanen

Fairspectrum

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476021AE4A5008AM1MPN1006mg_-- From vchen@google.com Wed Mar 13 13:35:54 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2221F8ABC for ; Wed, 13 Mar 2013 13:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw1erx2GsGZ0 for ; Wed, 13 Mar 2013 13:35:50 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id B55AC21F8A41 for ; Wed, 13 Mar 2013 13:35:49 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi8so1176997wib.13 for ; Wed, 13 Mar 2013 13:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DdB2gjMlxhNt7/zFAb/qM1qOR0UiKK5jiGk5YVX65RY=; b=EVKWNkkP6jP0JzSCBLoC+7CJoheyaPbafY4NENE9rXyYNRFb+mQTchrEj2z/NusDxK 0JSrp3pD+IFPC+Eq2cWn1eL7niEponQzRIrmYEdk8qGJqVI6UKHUeniItHVt7JSD2In7 ymSA9ZU6B9ZvhzUfHuOqh6Yl7ZrUsLs/eEJ+99iGe7QktNjb0Ffm3JHV2JTwsdXUP7Pb rdfyeDN7xCqDeQ6i9p9TSPFJ6e+nL/LAmP/D2PJsLedIWchHB49V6ZaiuB5AaHgTMqdg KXxZg236r5N3uKngv/3ojUNkEMLB4LwkGE7s4FsiSv/VzJdCjK+sjaSOrdlJo2ExBzuE xemw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=DdB2gjMlxhNt7/zFAb/qM1qOR0UiKK5jiGk5YVX65RY=; b=V1Fn6zwNta226hBLT3HRvMIzWNpVeyrAtgJW0grdkLrXinXIWxrqC/zqYkPcxOFPyI rVsPXl3aJ3AuUrVcS7gCcKvj2BMi0X7ZDaxQS4za2g1uUY4InwSgKkwCS8uzGaoDD90y qKM7zty1p1ogCFYieUi3XrkEokUoW3TMZN4xXRm9POq4nbvCGTLI+X7nq5cQmEBAEll5 Y90y6XEJavS7r2mecs9n/9v5cXLd6dIdCnS+I0vPE6o0L0Ih+QkNJwo/YgF43eoWwiSU yCmZ6gWAZYd/Vt6K06hzwufx9YzvcPisuY3lQPUex4lWxDbie8rSTFzPHch/8FhkWEbP Y3Zw== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr29606698wiv.23.1363206948814; Wed, 13 Mar 2013 13:35:48 -0700 (PDT) Received: by 10.194.89.202 with HTTP; Wed, 13 Mar 2013 13:35:48 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476021AE4A5@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476021AE4A5@008-AM1MPN1-006.mgdnok.nokia.com> Date: Wed, 13 Mar 2013 13:35:48 -0700 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/alternative; boundary=f46d043be130f0969104d7d459a4 X-Gm-Message-State: ALoCoQmHCOBAWpld3rLTPkHCTpTp/c7wDVaCiIab1pVlyZdPHeqzywMeZeGxGEWQ8TcByRmjWhfVvXcDjtLroASY9dZZtHSl7GuXv6/CKZKQ7U442F3KQMtyGLntvQ1TEfIkftCeiNHOsLGt1irGlJDDoqZFEF1Ivopdaxl0QdC93ks8xnUBif0+9gwvQph0B7gDL76Eiceg Cc: "paws@ietf.org" Subject: Re: [paws] PAWS Location info using RFC5491 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:35:54 -0000 --f46d043be130f0969104d7d459a4 Content-Type: text/plain; charset=ISO-8859-1 Thanks to Martin for the clarifications. RE: confidence - It is included, because some regulators have defined the confidence level to use for specifying location uncertainty. This parameter was included to allow for possible variations amongst different regulators. - As for the default value for confidence, 95 may indeed be a better default, if there are no objections on the list. - For the PAWS protocol, we are allowing a location to be specified as a "point" (with uncertainty) or "region", so the last sentence is only distinguishing between these two options, rather than a physical "point". I can clarify the language. On Wed, Mar 13, 2013 at 12:54 PM, wrote: > One of the authors of the cited RFC was kind enough to respond to this > email, and I am forwarding his mail:**** > > ** ** > > ** ** > > From: ext Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Wednesday, March 13, 2013 6:43 AM > > **** > > Suggestions of this nature are extremely common. After all, there are > very many standardized representations of location. I'd be surprised if > you haven't already had suggestions for GeoJSON, KML, 3GPP TS 23.032, or > one of the many other commonly used serializations of location. WKT is > very much unsurprising.**** > > ** ** > > The problem with WKT is that it was developed with SQL in mind. It's a > structured textual format. That means that processors are required to > understand the parsing rules in order to extract the information they > need. Use of WKT in paws would require considerable effort to properly > profile the format. Any advantage gained by those who are implementing > with GIS databases is far outweighed by the cost to those implementations > that consume the information.**** > > ** ** > > I haven't been tracking paws, so I was encouraged to see that the handling > of location was largely sensible and pragmatic. In the complexity/value > trade-off, I might have chosen circle over ellipse, though ellipse is > clearly valuable to the extent that it is the natural product of a GPS > trilaterator and a good fit for a cell sector coverage area.**** > > ** ** > > Reading through the paws protocol draft, the following jumped out at me:** > ** > > ** ** > > confidence: The location confidence level, as an integer percentage,** > ** > > MAY be required, depending on the regulatory domain. When the**** > > parameter is optional, its default value is 100. This values is**** > > only meaningful when GeoLocation refers to a point.**** > > ** ** > > 100 is an invalid value for confidence. Confidence is an estimate of the > probability that the provided uncertainty region includes the measurand. > Claiming a probability of 1 for confidence is never possible in practice.* > *** > > ** ** > > Setting the value to 100 by default is actually nonsensical. 95 might be > a better default if you care about RFC 4119/5985 interactions. 67 would be > a better fit for what most GPS trilaterators produce.**** > > ** ** > > That last sentence is directly wrong. Assuming point positioning, it's > never possible to have any more than zero confidence in an estimate that > does not have uncertainty.**** > > ** ** > > I was somewhat surprised to see confidence in the draft. We didn't add it > to RFC 5491 because it isn't well understood and it makes things like > comparisons difficult. It's not actually possible, without making > assumptions, to compare locations that have different confidence values.** > ** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Kalle Kuismanen > *Sent:* Tuesday, March 12, 2013 7:22 PM > *To:* paws@ietf.org > *Subject:* [paws] PAWS Location info using RFC5491**** > > ** ** > > Hello everybody,**** > > ** ** > > First of all, thank you for interesting presentations in Orlando, I hope > weather was bit warmer than here in Finland where I was doomed to watch > them.**** > > ** ** > > I'm not sure how much discussion you've had on the method used to describe > location in this draft. So I apologize in advance if this issue is closed. > **** > > ** ** > > This draft of PAWS protocol uses JSON syntax, but RFC5491, which is used > to describe location is XML based protocol. **** > > This causes a problem for us implementers, because this hybrid loses **** > > unambiguity i.e. I cannot verify the location entries against json-schema > because it doesn't exist.**** > > ** ** > > As an alternative I think something like following would be useful as a > replacement or an alternative.**** > > ** ** > > Most implementations of geospatial databases understand ISO/IEC > 13249-3:2011 WKT and BKT format for geometric representations and there > are a lot of ready made code to handle it.**** > > ** ** > > http://en.wikipedia.org/wiki/Well-known_text#Well-known_binary**** > > ** ** > > so instead of **** > > "location": {**** > > "point": {**** > > "center": {"latitude": 37.0005, "longitude": -101.3005}**** > > } }**** > > ** ** > > one could enter**** > > ** ** > > "location": {**** > > "wkt": "POINT (101.3005 37.0005)",**** > > "srid":4326 }**** > > ** ** > > or WKB equivalent. Just a note: (srid 4326 is the id for WGS84)**** > > ** ** > > Advantage of this is that since WKT and WKB are understood by most > geospatial databases there is very little parsing to do, validation is > trivial and as a bonus it can be directly entered as a part of a query. > Protocol covers other geometric shapes.**** > > ** ** > > It doesn't cover ellipse though, but then again it's not very common > feature in geospatial databases and ellipses need to be converted into > polygons anyway to make geospatial queries.**** > > ** ** > > Cheers,**** > > Kalle Kuismanen**** > > Fairspectrum**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- -vince --f46d043be130f0969104d7d459a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks to Martin for the clarifications.

RE: confidence

=A0- It is included, becaus= e some regulators have defined the confidence level to use for specifying l= ocation uncertainty. This parameter was included to allow for possible vari= ations amongst different regulators.

=A0- As for the default value for confidenc= e, 95 may indeed be a better default, if there are no objections on the lis= t.

=A0- For the PAWS protocol, we = are allowing a location to be specified as a "point" (with uncert= ainty) or "region", so the last sentence is only distinguishing b= etween these two options, rather than a physical "point". I can c= larify the language.

=A0=A0


On Wed, Mar 13, 2013 at 12:54 PM, = <Gabor.Bajko@nokia.com> wrote:

One of the authors of the cited RFC was= kind enough to respond to this email, and I am forwarding his mail:=

=A0

=A0

From: ext Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Wednesday, March 13, 2013 6:43 AM

Suggestions of this nature are extremely common.=A0 After all, there are= very many standardized representations of location.=A0 I'd be surprise= d if you haven't already had suggestions for GeoJSON, KML, 3GPP TS 23.0= 32, or one of the many other commonly used serializations of location.=A0 WKT is very much unsurp= rising.

=A0

The problem with WKT is that it was developed with SQL in mind.=A0 It= 9;s a structured textual format.=A0 That means that processors are required= to understand the parsing rules in order to extract the information they n= eed.=A0 Use of WKT in paws would require considerable effort to properly profile the format.=A0 = Any advantage gained by those who are implementing with GIS databases is fa= r outweighed by the cost to those implementations that consume the informat= ion.

=A0

I haven't been tracking paws, so I was encouraged to see that the ha= ndling of location was largely sensible and pragmatic.=A0 In the complexity= /value trade-off, I might have chosen circle over ellipse, though ellipse i= s clearly valuable to the extent that it is the natural product of a GPS trilaterator and a g= ood fit for a cell sector coverage area.

=A0

Reading through the paws protocol draft, the following jumped out at me:=

=A0

=A0=A0 confidence:=A0 The location confidence level, as an integer perce= ntage,

=A0=A0=A0=A0=A0 MAY be required, depending on the regulatory domain.=A0 = When the

=A0=A0=A0=A0=A0 parameter is optional, its default value is 100.=A0 This= values is

=A0=A0=A0=A0=A0 only meaningful when GeoLocation refers to a point.

=A0

100 is an invalid value for confidence.=A0 Confidence is an estimate of = the probability that the provided uncertainty region includes the measurand= .=A0 Claiming a probability of 1 for confidence is never possible in practi= ce.

=A0

Setting the value to 100 by default is actually nonsensical.=A0 95 might= be a better default if you care about RFC 4119/5985 interactions.=A0 67 wo= uld be a better fit for what most GPS trilaterators produce.<= /p>

=A0

That last sentence is directly wrong.=A0 Assuming point positioning, it&= #39;s never possible to have any more than zero confidence in an estimate t= hat does not have uncertainty.

=A0

I was somewhat surprised to see confidence in the draft.=A0 We didn'= t add it to RFC 5491 because it isn't well understood and it makes thin= gs like comparisons difficult.=A0 It's not actually possible, without m= aking assumptions, to compare locations that have different confidence values.

=A0

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Kalle Kuismanen
Sent: Tuesday, March 12, 2013 7:22 PM
To: paws@ietf.org=
Subject: [paws] PAWS Location info using RFC5491

=A0

Hello everybody,

=A0

First of all, thank you for interesting presentation= s in Orlando, I hope weather was bit warmer than here in Finland where I wa= s doomed to watch them.

=A0

I'm not sure how much discussion you've had = on the method used to describe location in this draft. So I apologize in ad= vance if this issue is closed.

=A0

This draft of PAWS protocol uses JSON syntax, but RF= C5491, which is used to describe location is XML based protocol.=A0<= u>

This causes a problem for us implementers, because t= his hybrid loses=A0

unambiguity i.e. I cannot verify the location entrie= s against json-schema because it doesn't exist.

=A0

As an alternative I think something like following w= ould be useful as a replacement or an alternative.

=A0

Most implementations of geospatial databases underst= and=A0ISO/IEC 13249-3:2011=A0WKT and BKT= format for geometric representations and there are a lot of ready made code to handle it.

=A0

=A0

so instead of=A0

"location": {

=A0"point": {

=A0"center": {"latitude": 37.000= 5, "longitude": -101.3005}

=A0} }

=A0

one could enter

=A0

"location": {

=A0"wkt": "POINT (101.30= 05=A037.0005)",

=A0"srid":4326=A0}<= /u>

=A0

or WKB equivalent. Just a note: (srid 4326 is the id= for WGS84)

=A0

Advantage of this is that since WKT and WKB are unde= rstood by most geospatial databases there is very little parsing to do, val= idation is trivial and as a bonus it can be directly entered as a part of a= query. Protocol covers other geometric shapes.

=A0

It doesn't cover ellipse though, but then again = it's not very common feature in geospatial databases and ellipses need = to be converted into polygons anyway to make geospatial queries.<= /u>

=A0

Cheers,

Kalle Kuismanen

Fairspectrum

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--f46d043be130f0969104d7d459a4-- From vchen@google.com Wed Mar 13 22:16:55 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B621F8CA3 for ; Wed, 13 Mar 2013 22:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aHWKfDx8dWj for ; Wed, 13 Mar 2013 22:16:54 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0E21F8C8F for ; Wed, 13 Mar 2013 22:16:53 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id d7so1743097wer.22 for ; Wed, 13 Mar 2013 22:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=QWn754FVzUFYdOHCGI+e0sal2MlBUx0sEiRqiPQEEwc=; b=h2Tl/vM8hmJp2F8i9XmnS+SGkmjhVwIlkjyaOxj2e3gntLvTdt76XU2KokIT8JTTgV MpEohDMSkWDzmITtdMC2ItoCpXyViPWb29zTJ3pDZAhl9s+7sWrzJnX56JQiCzK2OqZO zrXgt3VGAlHcjRDXc5QsFy6qEuBBFoQ81tl99KDOszYSz3dTHa3OZctt7EShwQeEtgdZ 0NkhHB0CclqeSgWtGs3RrC8S3jWY6XZWcc7wQxG35KXE38/+MFNnLKFm/17CZS5Oynvx uevpDdwfoz4RhKWaNCuO1qcJ9G8+HRV3CJACntOXIUvfmfgcukSSthdh7s24i2UN3BfB Z7pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=QWn754FVzUFYdOHCGI+e0sal2MlBUx0sEiRqiPQEEwc=; b=LscLJsLN/r/H3R0SRkwJ3e+B1QWQMdiWXuGjYcWsd+GsKBakFpWIwtLxPmNPBkWh67 aD9CO7O7y8S+Z+5XIWSwzAFLaxMXD9x8BmbZ8SivNgmmcgrYrTQUVSpdvqy+YOQT4whD 9X+t2fDGut2ElVy86gif6x1w7nGU1urhcIlz4ZbskFNsa04DIQ0wRIn4zId6a4gdvwe5 sA8qgQKa1PUyMEHFnVHy7R8X+rVy3ucFlkigxjGfhLtDnUTnVuXsMFUls7fnJvb8Whs5 rfo14jEN859hbD+7eBtI4OM8R3PDMMK3C3/GYf2VS/3uxybLDdTzFb0CXqHR70860cVn 7n9w== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr31322689wiv.23.1363238213054; Wed, 13 Mar 2013 22:16:53 -0700 (PDT) Received: by 10.194.89.202 with HTTP; Wed, 13 Mar 2013 22:16:52 -0700 (PDT) Date: Wed, 13 Mar 2013 22:16:52 -0700 Message-ID: From: Vincent Chen To: Cesar.Gutierrez@ofcom.org.uk, "paws@ietf.org" Content-Type: multipart/alternative; boundary=f46d043be1306f101d04d7dba18b X-Gm-Message-State: ALoCoQmoIp1qFkYzadN+vKmHgLdmOv8inlWW/U6xX/MtOUthMQXfLE5Yee2MoDp4t/OS1Y+Vasz3P98pQLFk0AC1eWAcZ8u760tTj1lzjxzvdSm1+u1da4Jvlu0ZrQaWf7TJmP0pN2BHcIQzy2v4w7tnsGhRudHD3UkAeDHYvbnP0SW8U25P2O8kg6N0fHXuVqac5ebV+Vzj Subject: [paws] Extensibility for Ofcom X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 05:16:55 -0000 --f46d043be1306f101d04d7dba18b Content-Type: text/plain; charset=ISO-8859-1 Cesar, Thanks for joining the call for the IETF/PAWS. I want to follow up with you on the parameter names and values that we should consider adding to the draft to support Ofcom White Space rules. In particular: - What is the "unique device identifier" intended to be? Is there a separate certification ID apart from the serial number? - What should be the parameter name for "device class"? What are the possible values and what do they mean? - What should be the parameter name for "technology ID"? What are the possible vales and what do they mean? Are you aware of other parameters that must be defined for Ofcom? Thanks for your help. -- -vince --f46d043be1306f101d04d7dba18b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Cesar,

Thanks for joining the call for = the IETF/PAWS.

I want to follow up with you on the= parameter names and values that we should consider adding to the draft to = support Ofcom White Space rules. In particular:

=A0- What is the "unique device identifier&q= uot; intended to be? Is there a separate certification ID apart from the se= rial number?

=A0- What should be the p= arameter name for "device class"? What are the possible values an= d what do they mean?

=A0- What should be the parameter name for = "technology ID"? What are the possible vales and what do they mea= n?

Are you aware of other parameters t= hat must be defined for Ofcom?

Thanks for your help.

<= /div>
--
-vince
--f46d043be1306f101d04d7dba18b-- From kalle.kuismanen@fairspectrum.com Thu Mar 14 01:20:10 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8DE21F8E1C for ; Thu, 14 Mar 2013 01:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rMlhg-wFG1p for ; Thu, 14 Mar 2013 01:20:04 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 53ADC21F899E for ; Thu, 14 Mar 2013 01:20:01 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so1966552oag.40 for ; Thu, 14 Mar 2013 01:20:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FHAV7cqYZViMklwJ90fWy8AJuzxVN18+7A3MbBkVeqQ=; b=Huzr0oVKWEkMDzcOW/FHmIyMRZ/9vLdEbiE7/oJRpqwJ6zL1VrD9U6+Hv1HoDpfrk0 yP6Sq57vBxf5H57yaQDTIwFDm4cAHbYZjK+3QJFryzjdDFCW/NkhwV7bwJ+OKuN27bKV libHAl1FE2hrCQshlEPtYdF2Mc2izsk+RMeVt7/DEATa3l/2DEPEvmwoNUNEtiheQKBg 69iHBcwZOFg3CE/5ChH7NR/ginRrcZuDCz3ovv03pN+FB0+mTqDaeftvrqSpLNa3MasZ 3o1bb01ZydSGnUZYwTGWnrbdFzW/zwcn5/b5R0kVbz7Vr8aQI/1u+9uHkPonaIaYx4TX H2sg== MIME-Version: 1.0 X-Received: by 10.60.12.41 with SMTP id v9mr702522oeb.75.1363249200600; Thu, 14 Mar 2013 01:20:00 -0700 (PDT) Received: by 10.60.135.2 with HTTP; Thu, 14 Mar 2013 01:20:00 -0700 (PDT) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476021AE4A5@008-AM1MPN1-006.mgdnok.nokia.com> Date: Thu, 14 Mar 2013 10:20:00 +0200 Message-ID: From: Kalle Kuismanen To: Vincent Chen Content-Type: multipart/alternative; boundary=e89a8ff255d4580d4f04d7de30cf X-Gm-Message-State: ALoCoQnAPj6c+7Gjbm55Wks2ySkZKxX1LnSCE9WPOf8q2K9LYNeED2q3R1ElaGaCnLRe4QB2UBqA Cc: "paws@ietf.org" Subject: Re: [paws] PAWS Location info using RFC5491 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 08:20:10 -0000 --e89a8ff255d4580d4f04d7de30cf Content-Type: text/plain; charset=ISO-8859-1 Hi all, Thanks for the clarification. I think it's bit far fetched to say that paws uses RFC5491. Instead basically paws draft defines the GeoLocation object in the draft and it is inspired by RFC5491. One note on Martins response: "Any advantage gained by those who are implementing with GIS databases is far outweighed by the cost to those implementations that consume the information." I don't know if there are any other implementations than the GIS databases that consume the information. Since WS database pretty much has to be a GIS database of some sort. Kalle On Wed, Mar 13, 2013 at 10:35 PM, Vincent Chen wrote: > Thanks to Martin for the clarifications. > > RE: confidence > > - It is included, because some regulators have defined the confidence > level to use for specifying location uncertainty. This parameter was > included to allow for possible variations amongst different regulators. > > - As for the default value for confidence, 95 may indeed be a better > default, if there are no objections on the list. > > - For the PAWS protocol, we are allowing a location to be specified as a > "point" (with uncertainty) or "region", so the last sentence is only > distinguishing between these two options, rather than a physical "point". I > can clarify the language. > > > > > On Wed, Mar 13, 2013 at 12:54 PM, wrote: > >> One of the authors of the cited RFC was kind enough to respond to this >> email, and I am forwarding his mail:**** >> >> ** ** >> >> ** ** >> >> From: ext Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Wednesday, March 13, 2013 6:43 AM >> >> **** >> >> Suggestions of this nature are extremely common. After all, there are >> very many standardized representations of location. I'd be surprised if >> you haven't already had suggestions for GeoJSON, KML, 3GPP TS 23.032, or >> one of the many other commonly used serializations of location. WKT is >> very much unsurprising.**** >> >> ** ** >> >> The problem with WKT is that it was developed with SQL in mind. It's a >> structured textual format. That means that processors are required to >> understand the parsing rules in order to extract the information they >> need. Use of WKT in paws would require considerable effort to properly >> profile the format. Any advantage gained by those who are implementing >> with GIS databases is far outweighed by the cost to those implementations >> that consume the information.**** >> >> ** ** >> >> I haven't been tracking paws, so I was encouraged to see that the >> handling of location was largely sensible and pragmatic. In the >> complexity/value trade-off, I might have chosen circle over ellipse, though >> ellipse is clearly valuable to the extent that it is the natural product of >> a GPS trilaterator and a good fit for a cell sector coverage area.**** >> >> ** ** >> >> Reading through the paws protocol draft, the following jumped out at me:* >> *** >> >> ** ** >> >> confidence: The location confidence level, as an integer percentage,* >> *** >> >> MAY be required, depending on the regulatory domain. When the**** >> >> parameter is optional, its default value is 100. This values is*** >> * >> >> only meaningful when GeoLocation refers to a point.**** >> >> ** ** >> >> 100 is an invalid value for confidence. Confidence is an estimate of the >> probability that the provided uncertainty region includes the measurand. >> Claiming a probability of 1 for confidence is never possible in practice. >> **** >> >> ** ** >> >> Setting the value to 100 by default is actually nonsensical. 95 might be >> a better default if you care about RFC 4119/5985 interactions. 67 would be >> a better fit for what most GPS trilaterators produce.**** >> >> ** ** >> >> That last sentence is directly wrong. Assuming point positioning, it's >> never possible to have any more than zero confidence in an estimate that >> does not have uncertainty.**** >> >> ** ** >> >> I was somewhat surprised to see confidence in the draft. We didn't add >> it to RFC 5491 because it isn't well understood and it makes things like >> comparisons difficult. It's not actually possible, without making >> assumptions, to compare locations that have different confidence values.* >> *** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >> Of *ext Kalle Kuismanen >> *Sent:* Tuesday, March 12, 2013 7:22 PM >> *To:* paws@ietf.org >> *Subject:* [paws] PAWS Location info using RFC5491**** >> >> ** ** >> >> Hello everybody,**** >> >> ** ** >> >> First of all, thank you for interesting presentations in Orlando, I hope >> weather was bit warmer than here in Finland where I was doomed to watch >> them.**** >> >> ** ** >> >> I'm not sure how much discussion you've had on the method used to >> describe location in this draft. So I apologize in advance if this issue is >> closed.**** >> >> ** ** >> >> This draft of PAWS protocol uses JSON syntax, but RFC5491, which is used >> to describe location is XML based protocol. **** >> >> This causes a problem for us implementers, because this hybrid loses **** >> >> unambiguity i.e. I cannot verify the location entries against json-schema >> because it doesn't exist.**** >> >> ** ** >> >> As an alternative I think something like following would be useful as a >> replacement or an alternative.**** >> >> ** ** >> >> Most implementations of geospatial databases understand ISO/IEC >> 13249-3:2011 WKT and BKT format for geometric representations and there >> are a lot of ready made code to handle it.**** >> >> ** ** >> >> http://en.wikipedia.org/wiki/Well-known_text#Well-known_binary**** >> >> ** ** >> >> so instead of **** >> >> "location": {**** >> >> "point": {**** >> >> "center": {"latitude": 37.0005, "longitude": -101.3005}**** >> >> } }**** >> >> ** ** >> >> one could enter**** >> >> ** ** >> >> "location": {**** >> >> "wkt": "POINT (101.3005 37.0005)",**** >> >> "srid":4326 }**** >> >> ** ** >> >> or WKB equivalent. Just a note: (srid 4326 is the id for WGS84)**** >> >> ** ** >> >> Advantage of this is that since WKT and WKB are understood by most >> geospatial databases there is very little parsing to do, validation is >> trivial and as a bonus it can be directly entered as a part of a query. >> Protocol covers other geometric shapes.**** >> >> ** ** >> >> It doesn't cover ellipse though, but then again it's not very common >> feature in geospatial databases and ellipses need to be converted into >> polygons anyway to make geospatial queries.**** >> >> ** ** >> >> Cheers,**** >> >> Kalle Kuismanen**** >> >> Fairspectrum**** >> >> ** ** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > --e89a8ff255d4580d4f04d7de30cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Thanks for the clarification. I think it's b= it far fetched to say that paws uses RFC5491. Instead basically paws draft = defines the GeoLocation object in the draft and it is inspired by RFC5491.= =A0


One note on Martins response: "Any = advantage gained by those who are implementing with GIS databases is far ou= tweighed by the cost to those implementations that consume the information.= "

I don't know if there are any other implementations= than the GIS databases that consume the information. Since WS database pre= tty much has to be a GIS database of some sort.


Kalle

On= Wed, Mar 13, 2013 at 10:35 PM, Vincent Chen <vchen@google.com> wrote:
Thanks to Martin for the cl= arifications.

RE: confidence

= =A0- It is included, because some regulators have defined the confidence le= vel to use for specifying location uncertainty. This parameter was included= to allow for possible variations amongst different regulators.

=A0- As for the default value for confidence, 95 may in= deed be a better default, if there are no objections on the list.
=

=A0- For the PAWS protocol, we are allowing a location = to be specified as a "point" (with uncertainty) or "region&q= uot;, so the last sentence is only distinguishing between these two options= , rather than a physical "point". I can clarify the language.

=A0=A0

On Wed, Mar 13, 2013 at= 12:54 PM, <Gabor.Bajko@nokia.com> wrote:

One of the authors of the cited RFC was= kind enough to respond to this email, and I am forwarding his mail:=

=A0

=A0

From: ext Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Wednesday, March 13, 2013 6:43 AM

Suggestions of this nature are extremely common.=A0 After all, there are= very many standardized representations of location.=A0 I'd be surprise= d if you haven't already had suggestions for GeoJSON, KML, 3GPP TS 23.0= 32, or one of the many other commonly used serializations of location.=A0 WKT is very much unsurp= rising.

=A0

The problem with WKT is that it was developed with SQL in mind.=A0 It= 9;s a structured textual format.=A0 That means that processors are required= to understand the parsing rules in order to extract the information they n= eed.=A0 Use of WKT in paws would require considerable effort to properly profile the format.=A0 = Any advantage gained by those who are implementing with GIS databases is fa= r outweighed by the cost to those implementations that consume the informat= ion.

=A0

I haven't been tracking paws, so I was encouraged to see that the ha= ndling of location was largely sensible and pragmatic.=A0 In the complexity= /value trade-off, I might have chosen circle over ellipse, though ellipse i= s clearly valuable to the extent that it is the natural product of a GPS trilaterator and a g= ood fit for a cell sector coverage area.

=A0

Reading through the paws protocol draft, the following jumped out at me:=

=A0

=A0=A0 confidence:=A0 The location confidence level, as an integer perce= ntage,

=A0=A0=A0=A0=A0 MAY be required, depending on the regulatory domain.=A0 = When the

=A0=A0=A0=A0=A0 parameter is optional, its default value is 100.=A0 This= values is

=A0=A0=A0=A0=A0 only meaningful when GeoLocation refers to a point.

=A0

100 is an invalid value for confidence.=A0 Confidence is an estimate of = the probability that the provided uncertainty region includes the measurand= .=A0 Claiming a probability of 1 for confidence is never possible in practi= ce.

=A0

Setting the value to 100 by default is actually nonsensical.=A0 95 might= be a better default if you care about RFC 4119/5985 interactions.=A0 67 wo= uld be a better fit for what most GPS trilaterators produce.<= /p>

=A0

That last sentence is directly wrong.=A0 Assuming point positioning, it&= #39;s never possible to have any more than zero confidence in an estimate t= hat does not have uncertainty.

=A0

I was somewhat surprised to see confidence in the draft.=A0 We didn'= t add it to RFC 5491 because it isn't well understood and it makes thin= gs like comparisons difficult.=A0 It's not actually possible, without m= aking assumptions, to compare locations that have different confidence values.

=A0

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Kalle Kuismanen
Sent: Tuesday, March 12, 2013 7:22 PM
To: paws@ietf.org=
Subject: [paws] PAWS Location info using RFC5491

=A0

Hello everybody,

=A0

First of all, thank you for interesting presentation= s in Orlando, I hope weather was bit warmer than here in Finland where I wa= s doomed to watch them.

=A0

I'm not sure how much discussion you've had = on the method used to describe location in this draft. So I apologize in ad= vance if this issue is closed.

=A0

This draft of PAWS protocol uses JSON syntax, but RF= C5491, which is used to describe location is XML based protocol.=A0<= u>

This causes a problem for us implementers, because t= his hybrid loses=A0

unambiguity i.e. I cannot verify the location entrie= s against json-schema because it doesn't exist.

=A0

As an alternative I think something like following w= ould be useful as a replacement or an alternative.

=A0

Most implementations of geospatial databases underst= and=A0ISO/IEC 13249-3:2011=A0WKT and BKT= format for geometric representations and there are a lot of ready made code to handle it.

=A0

=A0

so instead of=A0

"location": {

=A0"point": {

=A0"center": {"latitude": 37.000= 5, "longitude": -101.3005}

=A0} }

=A0

one could enter

=A0

"location": {

=A0"wkt": "POINT (101.30= 05=A037.0005)",

=A0"srid":4326=A0}<= /u>

=A0

or WKB equivalent. Just a note: (srid 4326 is the id= for WGS84)

=A0

Advantage of this is that since WKT and WKB are unde= rstood by most geospatial databases there is very little parsing to do, val= idation is trivial and as a bonus it can be directly entered as a part of a= query. Protocol covers other geometric shapes.

=A0

It doesn't cover ellipse though, but then again = it's not very common feature in geospatial databases and ellipses need = to be converted into polygons anyway to make geospatial queries.<= /u>

=A0

Cheers,

Kalle Kuismanen

Fairspectrum

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws


<= br clear=3D"all">

--
-vince

--e89a8ff255d4580d4f04d7de30cf-- From vchen@google.com Sat Mar 16 11:57:24 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C30F21F8630 for ; Sat, 16 Mar 2013 11:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C0Jfmlr5t6i for ; Sat, 16 Mar 2013 11:57:24 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id A5F6221F850C for ; Sat, 16 Mar 2013 11:57:23 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id 8so595695wgl.6 for ; Sat, 16 Mar 2013 11:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=t1QMeoLpF0h52ReOfWWmK2cDl6OKHqop9l0cDDcXNUE=; b=ZsK8PA8RvttpaBKKpZMn+1ovdrt1CXngSxBPDlM2m6DxTNumw4/lRwHDRIk4JIUaYt 3n8D/GLGnUA5UXRor9kJGKI/djXfGpiZbTp81QvgZPnu/JRdVnZNh5JXTNKLZNsFBAOw lYgUaBpko6ups9hgrUUmt/lR/ZjvaxI0uX6TqUIEro5i9GrK9YEjq9ko7GPJUnnaj+Pf Zp7VmaEVSa8a8HREQJmE3aLqR4Th7t45SGN9Gurt35D1Aajh/Oybd6m5FZ4l66pFuMFN cJ7Sx8RBsPNniESX+cFI7TH6fXIVhpacpJooxNYxjaJvudT7CIBo8OYp5dgRzXtQI99z MNRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=t1QMeoLpF0h52ReOfWWmK2cDl6OKHqop9l0cDDcXNUE=; b=HO+X0Yn8csFm8dobxsVlozmOrNQRfGUkSQ/oSV01o8XXaejrmQ89gV2jcEVO5yHBzg sxtUPWd1wRuFt6svHTHkoCHrYNU7oRpR1ImH3fiAifZkiH0hrtMygkhdvzmSTJ1LRqCR OK7AfofZhc78udb0hr4mPyyLnAOCG475jhlfDZTp58joXoMR2rxlfhG9ExgHqMukyDTd pLD6B6AHdXg6E4sbgBYezqQa1mhavGuXrr911p9d1IGF9g18b4+gqea8NlN6sIa3nPeE Cf39q194T9FHf2yUFNgifMgWtLfrJTtB5fK2VG3L8rrLBLM7Bq9M8z8CUMcOfiDEAj0k ilmw== MIME-Version: 1.0 X-Received: by 10.180.87.170 with SMTP id az10mr9175525wib.3.1363460242808; Sat, 16 Mar 2013 11:57:22 -0700 (PDT) Received: by 10.194.240.230 with HTTP; Sat, 16 Mar 2013 11:57:22 -0700 (PDT) Date: Sat, 16 Mar 2013 11:57:22 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=f46d0444e97f703fc804d80f5345 X-Gm-Message-State: ALoCoQkXUDB1L4auuq/tVVuov09iXku7K8GKc8+uoFc8jLpliurPZB5FK0qY3FwEYK/ncw0P+O4/+MRTAd/ZDBY+8BPUrBhD6HXbCqMLfhzwwCMuD5CuZFpMdjJwxoMQqCGEXcpjznEgpdE/4qH38PbNXO0/9KqB2EgAAQYEULcy4MQyocRYYnkYHhNICXdk88FEdL7UXdnl Subject: [paws] Proposal: "namespace" prefix for method names X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 18:57:24 -0000 --f46d0444e97f703fc804d80f5345 Content-Type: text/plain; charset=ISO-8859-1 ALL, It has come to my attention that the method names in the JSON-RPC encoding may need to have a prefix in order to support services that host multiple JSON-RPCs. Specifically, I propose that method names to be changed to add a "spectrum.paws." prefix, such that: "init" -> "spectrum.paws.init" "register" -> "spectrum.paws.register" "getSpectrum" -> "spectrum.paws.getSpectrum" "getSpectrumBatch" -> "spectrum.paws.getSpectrumBatch" "notifySpectrumUse" -> "spectrum.paws.notifySpectrumUse" "verifyDevice" -> "spectrum.paws.verifyDevice" An alternative would be per-database prefix, but that would be messy. Is this acceptable? -- -vince --f46d0444e97f703fc804d80f5345 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
ALL,

It has come to my attention that t= he method names in the JSON-RPC encoding may need to have a prefix in order= to support services that host multiple JSON-RPCs.

Specifically, I propose that method names to be changed to add a "spec= trum.paws." prefix,
such that:

=A0 "init" -> "spectrum.paws.init"
=A0 &= quot;register" -> "spectrum.paws.register"
=A0 "getSpectrum" -> "spectrum.paws.getSpectrum"= ;
=A0 "getSpectrumBatch" -> "spectrum.paws.getS= pectrumBatch"
=A0 "notifySpectrumUse" -> "= spectrum.paws.notifySpectrumUse"
=A0 "verifyDevice" -> "spectrum.paws.verifyDevice&qu= ot;

An alternative would be per-database prefix, b= ut that would be messy.

Is this acceptable?

--
-vince
--f46d0444e97f703fc804d80f5345-- From vchen@google.com Mon Mar 18 16:42:30 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F0121F880F for ; Mon, 18 Mar 2013 16:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.977 X-Spam-Level: X-Spam-Status: No, score=-103.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zGAlU21t6fs for ; Mon, 18 Mar 2013 16:42:29 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 82E9421F8700 for ; Mon, 18 Mar 2013 16:42:28 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id d7so5376345wer.22 for ; Mon, 18 Mar 2013 16:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hZT4BlhPOpH1U4SAyp2hTZkPO59qrmda759VjNmnlUc=; b=hXyRWUrW/5EZ/ESHl7aMHA8sshVr2nYlrh/6rorcJ5KAM6xkRqQx5Ta4oGcQRW53Di CWmKBFu7Ea5aHgbCX+ZKQLMjH57AL4pZNcvO0nZPIG6qCqxH61mFapNPhSjPgFqlJKCV AOGjCmFuJ6WCnJ73EKHsHzLPfrDYmT/xircxmutrl7IApWCG9Cmizo3oA4HsBH5u2ko7 eVEipk13H4wXDjmEQG46TC+Dxi3cxzEuqlBWRnVak7BXSaO8qmUd7X2OyGhvfo97XhnJ pjL03qTydbRBlr3hR7lhIi5R3AIZkEwd4PlUX2c7PIhbYa/BdRsI2kMtvXJS+Tm4feZw 7W6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=hZT4BlhPOpH1U4SAyp2hTZkPO59qrmda759VjNmnlUc=; b=ah+ai2Xg4hAyIRNanfFeofYIFCwlbbxh4B89HjQT/jOsQql1vxdDqD0oyuhDVPFqAZ vQ3MQ+o7Zcr8PWRV777PMSRbPXzyEdcj3YDSg8xAtNy4aYtoTJa1q1Wr5HoQMmFlbulj zXGfWYPbWFylo06wsAaS7QcfBCwb3z2aOliWFyNmD4ZSap1sz7rwyx/kVMlZ4yKiJ1jL aU8w0G/g+1iahXKQCIusmiGqj+bFS29apBA7Fw5v2Gu+Aaotp5+RmrKwaxXh4HaaXGpU f6AQ0vheU7IFg0u7ibiG1oVBahYBFcN4Tc++j3ewOm3ZoXsdFK14Sj1DprFqwQodJ3w6 tj3Q== MIME-Version: 1.0 X-Received: by 10.194.157.42 with SMTP id wj10mr28706119wjb.12.1363650147499; Mon, 18 Mar 2013 16:42:27 -0700 (PDT) Received: by 10.194.240.230 with HTTP; Mon, 18 Mar 2013 16:42:27 -0700 (PDT) In-Reply-To: <5D3E853BEE49C848BB63047C794C86559EB94325@WOK-INTRA-EXC02.intra.ofcom.local> References: <5D3E853BEE49C848BB63047C794C86559EB94325@WOK-INTRA-EXC02.intra.ofcom.local> Date: Mon, 18 Mar 2013 16:42:27 -0700 Message-ID: From: Vincent Chen To: Cesar Gutierrez Content-Type: multipart/alternative; boundary=089e0112c512a3da1c04d83b8a4c X-Gm-Message-State: ALoCoQkULQYXXfcBW5T+oU506E0gyjTrA4LTQwrYuM3op2GWFIak9DGR6pAjEjaw5q30fbopyO/JMucIsIqfogwEdVPhAgYVHkSL9iLLdDbvrp4gvZfVU3Jzup3qZfujwLby/JgeS1LLokzB67+BYunEsiHXJvEDkP6pDWXww6fAkMH8jc4IftLnIihjpL+DYGpLCnKf7ZRH Cc: "paws@ietf.org" , Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] Extensibility for Ofcom X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:42:30 -0000 --089e0112c512a3da1c04d83b8a4c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Cesar, Thanks for your input. For timing, we are hoping to get to "last call" in the next couple of months. We need to address the open issues raised at the Face-to-Face. There will be a final review process that will extend that time frame some more. It would be nice to encode the Ofcom/Etsi parameters in the base PAWS protocol document. For example, should we use "etsiHs" prefix for all the parameter names you have listed? We can at least start by adding the names, even though the final parameter values have not been determined yet. What do you think? On Fri, Mar 15, 2013 at 3:45 AM, Cesar Gutierrez < Cesar.Gutierrez@ofcom.org.uk> wrote: > Hi Vince, > > > > Thanks for this. Note that we have not made final decisions on a number o= f > aspects of the UK regulations and of the ETSI Harmonised Standard, so som= e > of the parameters are still work in progress. Please see below my comment= s > on the points you raise: > > - Unique Device Identifier. Predictably, its purpose is to enable > databases to uniquely identify a device. In that sense it is similar to t= he > pair FCC Identifier + serial number in the US regulations. However, we do > not have an equivalent to the FCC Identifier in Europe, so the Unique > Device Identifier would be the set of 1) a manufacturer identifier, 2) a > model number and 3) the serial number. We haven=92t concluded on the for= mats > of these in ETSI BRAN. However, it is probably safe to say that 2) and 3) > would be strings of characters whose content is decided by the > manufacturer. On the other hand, it is less clear at present what the > manufacturer identifier could be. Options under consideration are a IEEE > OUI, or the manufacturer=92s name in text. > We will not have a certification ID in the ETSI standard or the UK > regulations. > > - Device class. A better name is Device Emission Class. It > characterises the out of block emissions of the device. There will be a > number of classes specified in ETSI Harmonised Standard =96 there four in= the > current draft (class 1 to class 4) but the count may change in the coming > months. > > - Technology ID. I think =93Technology ID=94 is good as a name. Ac= cess > technologies may be developed in the future that provide better protectio= n > to incumbents, and databases will need to know the technology of the devi= ce > if they are to apply protection ratios that account for it. Currently, ET= SI > HS defines this parameter as a string. > > - Other device parameters currently in the ETSI HS are the device > Category and the device Type. Device Category can take the values =93Mast= er=94 > and =93Slave=94, and it is very unlikely to change or to have additional = new > values. The current draft of the HS allows for two values for the Type > parameter: Type A and Type B. Simplistically, Type A is a fixed device an= d > Type B is a mobile device. However, there is considerable debate on the > types ongoing, and in any case we expect to add new types in the future. > These will take letter values such as Type E, Type C. > > - In addition, the database will send the device two parameters > that I believe are not captured in PAWS. These are the =93Maximum total > bandwidth=94 and the =93Maximum nominal channel bandwidth=94. They repres= ent the > maximum number of channels and the maximum number of contiguous channels > that the device can use, respectively. Both are integer in value. In PAWS= , > they probably should go into the =93SpectrumSchedule=94 or =93Spectrum=94 > parameters. > > > > I think you also raised questions about the ruleset. The issue is whether= , > at this point, the ruleset should be based on European regulation or UK > regulation. I think there might be no difference in practice between the > two approaches, since we expect that all UK requirements with regards to > devices will be captured in the ETSI Harmonised Standard. However, I thin= k > we need to reflect on this a bit more in Ofcom and in ETSI. > > > > This raises the question of timelines. Do you have a deadline for changes > to the parameters in your draft? > > > > Thank you and regards, > > Cesar > > > > > > *From:* Vincent Chen [mailto:vchen@google.com ] > *Sent:* 14 March 2013 05:17 > *To:* Cesar Gutierrez; paws@ietf.org > *Subject:* Extensibility for Ofcom > > > > Cesar, > > > > Thanks for joining the call for the IETF/PAWS. > > > > I want to follow up with you on the parameter names and values that we > should consider adding to the draft to support Ofcom White Space rules. I= n > particular: > > > > - What is the "unique device identifier" intended to be? Is there a > separate certification ID apart from the serial number? > > > > - What should be the parameter name for "device class"? What are the > possible values and what do they mean? > > > > - What should be the parameter name for "technology ID"? What are the > possible vales and what do they mean? > > > > Are you aware of other parameters that must be defined for Ofcom? > > > > Thanks for your help. > > > > -- > -vince > > ------------------------------ > > > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use > of the addressee only. > > If you have received this email in error please notify the originator of > the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s > at your own risk. > > Any views expressed in this message are those of the individual sender an= d > do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > > *************************************************************************= ***************************************** > --=20 -vince --089e0112c512a3da1c04d83b8a4c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Cesar,

Thanks for your input.
<= div>
For timing, we are hoping to get to "last call"= ; in the next couple of months. We need to address the open issues raised a= t the Face-to-Face. There will be a final review process that will extend t= hat time frame some more.

It would be nice to encode the Ofcom/Etsi parameters in= the base PAWS protocol document.
For example, should we use &quo= t;etsiHs" prefix for all the parameter names you have listed?
We can at least start by adding the names, even though the final param= eter values have not been determined yet.

What do you think?
=A0


On Fri, Mar 15, 20= 13 at 3:45 AM, Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> wrote:

Hi Vince,

=A0

Thanks for this. Note tha= t we have not made final decisions on a number of aspects of the UK regulat= ions and of the ETSI Harmonised Standard, so some of the parameters are still work in progress. Please see below my comments on the= points you raise:

-=A0=A0=A0=A0=A0=A0=A0 Unique Device Identifier. P= redictably, its purpose is to enable databases to uniquely identify a devic= e. In that sense it is similar to the pair FCC Identifier + serial number in the US regulations. However, we do not have an equivale= nt to the FCC Identifier in Europe, so the Unique Device Identifier would b= e the set of 1) a manufacturer identifier, 2) a model number and =A03) the = serial number. We haven=92t concluded on the formats of these in ETSI BRAN. However, it is probably safe to say = that 2) and 3) would be strings of characters whose content is decided by t= he manufacturer. On the other hand, it is less clear at present what the ma= nufacturer identifier could be. Options under consideration are a IEEE OUI, or the manufacturer=92s name i= n text.
We will not have a certification ID in the ETSI standard or the UK regulati= ons.

-=A0=A0=A0=A0=A0=A0=A0 Device class. A better name= is Device Emission Class. It characterises the out of block emissions of t= he device. There will be a number of classes specified in ETSI Harmonised Standard =96 there four in the current draft (class 1 t= o class 4) but the count may change in the coming months.

-=A0=A0=A0=A0=A0=A0=A0 Technology ID. I think =93T= echnology ID=94 is good as a name. Access technologies may be developed in = the future that provide better protection to incumbents, and databases will need to know the technology of the device if they are t= o apply protection ratios that account for it. Currently, ETSI HS defines t= his parameter as a string.

-=A0=A0=A0=A0=A0=A0=A0 Other device parameters cur= rently in the ETSI HS are the device Category and the device Type. Device C= ategory can take the values =93Master=94 and =93Slave=94, and it is very unlikely to change or to have additional new values. The curren= t draft of the HS allows for two values for the Type parameter: Type A and = Type B. Simplistically, Type A is a fixed device and Type B is a mobile dev= ice. However, there is considerable debate on the types ongoing, and in any case we expect to add new types in= the future. These will take letter values such as Type E, Type C.

-=A0=A0=A0=A0=A0=A0=A0 In addition, the database w= ill send the device two parameters that I believe are not captured in PAWS.= These are the =93Maximum total bandwidth=94 and the =93Maximum nominal channel bandwidth=94. They represent the maximum number of channel= s and the maximum number of contiguous channels that the device can use, re= spectively. Both are integer in value. In PAWS, they probably should go int= o the =93SpectrumSchedule=94 or =93Spectrum=94 parameters.

=A0

I think you also raised q= uestions about the ruleset. The issue is whether, at this point, the rulese= t should be based on European regulation or UK regulation. I think there might be no difference in practice between the two approache= s, since we expect that all UK requirements with regards to devices will be= captured in the ETSI Harmonised Standard. However, I think we need to refl= ect on this a bit more in Ofcom and in ETSI.

=A0

This raises the question = of timelines. Do you have a deadline for changes to the parameters in your = draft?

=A0

Thank you and regards,

Cesar

=A0

=A0

From: Vincent Chen [mailto:vchen@google.com]
Sent: 14 March 2013 05:17
To: Cesar Gutierrez; paws@ietf.org
Subject: Extensibility for Ofcom

=A0

Cesar,

=A0

Thanks for joining the call for the IETF/PAWS.

=A0

I want to follow up with you on the parameter names = and values that we should consider adding to the draft to support Ofcom Whi= te Space rules. In particular:

=A0

=A0- What is the "unique device identifier"= ; intended to be? Is there a separate certification ID apart from the seria= l number?

=A0

=A0- What should be the parameter name for "dev= ice class"? What are the possible values and what do they mean?

=A0

=A0- What should be the parameter name for "tec= hnology ID"? What are the possible vales and what do they mean?

=A0

Are you aware of other parameters that must be defin= ed for Ofcom?

=A0

Thanks for your help.

=A0

--
-vince



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************



--
-vince
--089e0112c512a3da1c04d83b8a4c-- From dmandelb@bbn.com Tue Mar 19 07:07:53 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CE621F8C48 for ; Tue, 19 Mar 2013 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXNk6jz46ycV for ; Tue, 19 Mar 2013 07:07:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 59D5721F8C45 for ; Tue, 19 Mar 2013 07:07:53 -0700 (PDT) Received: from smp.bbn.com ([192.1.122.26]:62903) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UHxCi-000KOi-IW for paws@ietf.org; Tue, 19 Mar 2013 10:07:52 -0400 Received: from c-67-189-168-202.hsd1.ma.comcast.net ([67.189.168.202]:26088 helo=[10.1.1.66]) by smp.bbn.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UHxCi-000LWm-9i for paws@ietf.org; Tue, 19 Mar 2013 10:07:52 -0400 Message-ID: <1363702060.3967.4.camel@titan> From: David Mandelberg To: paws@ietf.org Date: Tue, 19 Mar 2013 10:07:40 -0400 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Authenticated-User: dmandelb Subject: [paws] discussion of IPR disclosures X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 14:07:53 -0000 Hi, Has there been any discussion about the below IPR disclosures? Do any of them apply to the current versions of PAWS documents? https://datatracker.ietf.org/ipr/1700/ https://datatracker.ietf.org/ipr/1838/ https://datatracker.ietf.org/ipr/1839/ I searched the mailing list archive and found an email about https://datatracker.ietf.org/ipr/1614/, but not about any of the above disclosures. From Gabor.Bajko@nokia.com Thu Mar 21 13:57:09 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD13221F8630 for ; Thu, 21 Mar 2013 13:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxv+S2VJOD6f for ; Thu, 21 Mar 2013 13:57:09 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 212B821F8558 for ; Thu, 21 Mar 2013 13:57:05 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2LKuO4I015674 for ; Thu, 21 Mar 2013 22:57:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.50]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Mar 2013 22:56:47 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.108]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.02.0328.011; Thu, 21 Mar 2013 20:56:47 +0000 From: To: Thread-Topic: Orlando minutes posted Thread-Index: Ac4mdoSXUPol/oEoQQyDA2ufXLSyDQ== Date: Thu, 21 Mar 2013 20:56:46 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476021B109B@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.143.158.145] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476021B109B008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Mar 2013 20:56:48.0009 (UTC) FILETIME=[9A7B4790:01CE2676] X-Nokia-AV: Clean Subject: [paws] Orlando minutes posted X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 20:57:10 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021B109B008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/86/minutes/minutes-86-paws Thanks Dorothy for taking minutes. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021B109B008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/86/minutes/minutes-86-pa= ws

 

Thanks Dorothy for taking minutes.

 

-     &= nbsp;    Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476021B109B008AM1MPN1006mg_-- From vchen@google.com Wed Mar 27 10:10:35 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867D321F923D for ; Wed, 27 Mar 2013 10:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17XxW0PxhJWU for ; Wed, 27 Mar 2013 10:10:34 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id BDD2E21F922A for ; Wed, 27 Mar 2013 10:10:30 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id y10so715317wgg.2 for ; Wed, 27 Mar 2013 10:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=gKFHN3DRU+6YGkhccUP0PzmQgVzdU22UpMWinSW+2mw=; b=K1fQurE/JjatFnYlQSkLz7KY/jq3zjCuaP2j6U86s8c/zvs9blPYHhS9AgtXahOz0L T56h9OLIHLovjXZipHzaUSZ984qX1Ru767EEArWObcfCwTKjJrMHt8ZIpv7LFXsiyKLt RY/WpdJzHY7jyRP9z+IvtObu2bC9Q66KiCt/Kc6pVhB2dhYEQ8qFA/vRL+OXJ0FaUEmT dleK0pJLa5cP4vKd4kv95dKi/Gu3UnCuSq4Q6c8HVGyv3sP47R6Lujg2JWVjXvZw36p1 iaxr6v/MCyzHI5sXBOk5LdpMOhhCn12Nix5bIGUcY/uLr4cdTfKf7NllTWKIpw/P9APa l1AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=gKFHN3DRU+6YGkhccUP0PzmQgVzdU22UpMWinSW+2mw=; b=HlbGDdZTYK0SZchoq08fhKgfnCsBt5vkLDmPdfJ8gWuIYp9jswJCPo6bKG2pdGCspi Xbx1ItPAf86GkX5RAttrTyvbhvlLLDt8bNYfzn23JxAVy89/a/zjFvY/asrKkGQXdlmS T5VPzE5u35jKh6tyR8pHAnXCgdwYBPPurHpDPghm1Ci2APXF13gEmE/DU1kLpFMJkIRZ 4RkHMntmlXLk8FvFrahcq98bxgPzb5kmWuPNJzk5LYv84CtTvY1tq5n/fVdeqjOB1MVK Rm5WHdBK0kuvgJ1/9fXHOdPlLKKvYlxL796Xg9VP91X5pdUkhI3s+I0CMHeExcAPp2yz tOww== MIME-Version: 1.0 X-Received: by 10.194.157.42 with SMTP id wj10mr33065279wjb.12.1364404226784; Wed, 27 Mar 2013 10:10:26 -0700 (PDT) Received: by 10.194.240.230 with HTTP; Wed, 27 Mar 2013 10:10:26 -0700 (PDT) Date: Wed, 27 Mar 2013 10:10:26 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=089e0112c512466a2304d8eb1d6f X-Gm-Message-State: ALoCoQkp6jAQVhijwoGQF4HetyLeB+Hc0058PqhzPpyVRhkp2je7Hu1f8HbmWWV++FvcSJvyfUylRauGwWiXPEkKnCBYu/AGnGRtTbRv2qdjv5D78U2B3zLBZzSr5RAFm4IzPbW7mLoGmqnaPCVuNjzVq6FgeiWUDG8eKQNJzHoEsinxmf1KEKIPYgzCYVSih4cWjr7UFhnV Subject: [paws] Database Discovery: static provisioning X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:10:35 -0000 --089e0112c512466a2304d8eb1d6f Content-Type: text/plain; charset=ISO-8859-1 All, At the F2F, it was decided to update the language in the draft-ietf-paws-protocol to explicitly allow static provisioning, while leaving room to adopt dynamic provisioning, when it's defined. Here is the proposed language. Comments are welcomed. Thanks -vince ------------------------------ 4.1. Database Discovery The Device MUST determine the URI for the Database before it can send PAWS messages. The Device MAY be provisioned statically with the URI of one or more Databases. The Device SHOULD be provisioned with the URI of all the databases for which it is certified or otherwise permitted to operate. The Database MAY redirect a PAWS request by returning a HTTP 3xx response, as defined by HTTP/1.1 [RFC2616]. The Database MUST provide the redirect URI in the Location header of the 3xx response, and the Device MUST handle redirects by using the Location header provided by the Database. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the Database that returns the redirect response before following the redirect. Additionally, the Device MUST authenticate the Database indicated in the redirect. Because the Device may communicate with the Database without user interaction and because the Device authenticates the Database, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation, which is an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods. The Device MAY obtain the URI of one or more Databases dynamically from authorized and authenticated entities. The Device SHOULD use dynamic provisioning of Database URI when the mechanism is defined. --089e0112c512466a2304d8eb1d6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

At the F2F, it was decided to upda= te the language in the draft-ietf-paws-protocol to explicitly allow static = provisioning, while leaving room to adopt dynamic provisioning, when it'= ;s defined.

Here is the proposed language. Comments are welco= med. Thanks

-vince
------------------------------


4.1. =A0Database Discovery

=A0= =A0The Device MUST determine the URI for the Database before it can send
=A0 =A0PAWS messages. =A0The Device MAY be provisioned statically = with the URI
=A0 =A0of one or more Databases. =A0The Device SHOULD be provisioned w= ith the
=A0 =A0URI of all the databases for which it is certified= or otherwise
=A0 =A0permitted to operate.

=A0 =A0The Database MAY redirect a PAWS request by returning a HTTP 3xx<= /div>
=A0 =A0response, as defined by HTTP/1.1 [RFC2616]. =A0The Database MUS= T
=A0 =A0provide the redirect URI in the Location header of the 3= xx response,
=A0 =A0and the Device MUST handle redirects by using= the Location header
=A0 =A0provided by the Database. =A0When redirecting, the Device MUST = observe
=A0 =A0the delay indicated by the Retry-After header. =A0= The Device MUST
=A0 =A0authenticate the Database that returns the= redirect response before
=A0 =A0following the redirect. =A0Additionally, the Device MUST authen= ticate
=A0 =A0the Database indicated in the redirect. =A0Because = the Device may
=A0 =A0communicate with the Database without user = interaction and because
=A0 =A0the Device authenticates the Database, when the response code i= s 301
=A0 =A0(Moved Permanently), the Device MAY redirect without= asking a user
=A0 =A0for confirmation, which is an exception to = the HTTP/1.1 [RFC2616]
=A0 =A0requirements for HTTP POST methods.

= =A0 =A0The Device MAY obtain the URI of one or more Databases dynamically
=A0 =A0from authorized and authenticated entities. =A0The Device S= HOULD use
=A0 =A0dynamic provisioning of Database URI when the mechanism is defi= ned.

--089e0112c512466a2304d8eb1d6f-- From presnick@qti.qualcomm.com Thu Mar 28 08:20:43 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC8D21F8E93 for ; Thu, 28 Mar 2013 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1SBHXysFLS3 for ; Thu, 28 Mar 2013 08:20:42 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id B547C21F8E99 for ; Thu, 28 Mar 2013 08:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1364484041; x=1396020041; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=luNBHrj6HZUmY69EwRF+2rWlRdwpcG+Nu74nIz5thxU=; b=qTS/ZIe5gvGTeStIUwI4YvZEMhkldTDhLQi7zW/9XEeB9wBl6+UaMTmq wC7KAEoRtIezYe/vPkFfY5gdgTk5S8EqyOusIgCRzgZDAToMwZ0AG4ZYf vPNHcVQ2ZS8G7EptAT2uNh1nFt1/Y5tQdUMkicxZRtWh3nmuTB8dN3QKp w=; X-IronPort-AV: E=Sophos;i="4.84,927,1355126400"; d="scan'208,217";a="32012166" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 28 Mar 2013 08:20:41 -0700 Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Mar 2013 08:20:40 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 28 Mar 2013 08:20:40 -0700 Message-ID: <51545FC6.8080900@qti.qualcomm.com> Date: Thu, 28 Mar 2013 10:20:38 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476021B109B@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476021B109B@008-AM1MPN1-006.mgdnok.nokia.com> Content-Type: multipart/alternative; boundary="------------080001020605060908030303" X-Originating-IP: [172.30.39.5] Cc: paws@ietf.org Subject: Re: [paws] Orlando minutes posted X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:20:44 -0000 --------------080001020605060908030303 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 3/21/13 3:56 PM, Gabor.Bajko@nokia.com wrote: > > http://www.ietf.org/proceedings/86/minutes/minutes-86-paws > Small updates regarding OFCOM: It shouldn't look like OFCOM was participating in some official liaison-like capacity. That isn't how things work in the IETF meetings. So: OLD Chair reviewed the agenda; one remote participant: OFCOM -- Cesar -- will provide a status update. NEW Chair reviewed the agenda; one remote participant: Cesar -- will provide a status update on OFCOM. OLD First time for Ofcom participation in PAWS NEW First time for Cesar to participate in IETF OLD Request -- Ofcom to review current use case document. NEW Request -- Cesar to review current use case document. OLD Ofcom: would have a website that will have list of all websites of the DB providers. NEW Andy: OFCOM was planning to have a website that will have list of all websites of the DB providers. --- I haven't done a scrub of the rest of the minutes, but on first glance they look fine. (Thanks Dorothy.) Other WG participants: Please review the minutes to make sure everything was captured correctly. The minutes taker and the chairs should not have *all* of the responsibility. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------080001020605060908030303 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 3/21/13 3:56 PM, Gabor.Bajko@nokia.com wrote:

http://www.ietf.org/proceedings/86/minutes/minutes-86-paws


Small updates regarding OFCOM: It shouldn't look like OFCOM was participating in some official liaison-like capacity. That isn't how things work in the IETF meetings. So:

OLD
Chair reviewed the agenda; one remote participant: OFCOM – Cesar – will provide a status update.
NEW
Chair reviewed the agenda; one remote participant: Cesar – will provide a status update on OFCOM.

OLD
First time for Ofcom participation in PAWS
NEW
First time for Cesar to participate in IETF

OLD
Request – Ofcom to review current use case document.
NEW
Request – Cesar to review current use case document.

OLD
Ofcom: would have a website that will have list of all websites of the DB providers.
NEW
Andy: OFCOM was planning to have a website that will have list of all websites of the DB providers.

---

I haven't done a scrub of the rest of the minutes, but on first glance they look fine. (Thanks Dorothy.)

Other WG participants: Please review the minutes to make sure everything was captured correctly. The minutes taker and the chairs should not have *all* of the responsibility.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------080001020605060908030303--