From iesg-secretary@ietf.org Fri Feb 1 05:24:22 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 9FF2921F8B6C; Fri, 1 Feb 2013 05:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keYNOWszy1mD; Fri, 1 Feb 2013 05:24:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F050421F8B2B; Fri, 1 Feb 2013 05:24:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> Date: Fri, 01 Feb 2013 05:24:21 -0800 Cc: paws@ietf.org Subject: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:24:22 -0000 The IESG has received a request from the Protocol to Access WS database WG (paws) to consider the following document: - 'Protocol to Access White Space (PAWS) Database: Use Cases and Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using white space spectrum at a given time and location is to verify spectrum availability with a database that manages spectrum sharing and provides spectrum-availability information. The IETF has undertaken to develop a Protocol to Access Spectrum Database [1] for such a management database. This document describes a number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol. The concept of white spaces is described along with the problems that need to be addressed to enable white space spectrum for additional uses without causing interference to currently assigned use. Use of white space is enabled by querying a database that stores information about spectrum availability at any given location and time. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1614/ From barryleiba.mailing.lists@gmail.com Mon Feb 4 06:04:48 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 AE36B21F857B; Mon, 4 Feb 2013 06:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.895 X-Spam-Level: X-Spam-Status: No, score=-102.895 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIDU7U-S7cRT; Mon, 4 Feb 2013 06:04:47 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id C126B21F8585; Mon, 4 Feb 2013 06:04:46 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id e21so3884034vbm.34 for ; Mon, 04 Feb 2013 06:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HkXgMs9XoXVVq5TJC5HDyTtFzD6rsmuD49Dnlh8n/qM=; b=jitVkVOmH83cvhxdmsEu/bMRJi0Lm7/LpxFao0d8JMu3eE4DXjb3DHsDPxcP7glbWm q2xDK6Dddk79IL5nXGJxvtunDymoK4npY1sSqCJ0+LooVxo7LDitjbJO/NK67dNFQQgf Hskq+w+RaLpwbTbTBFmQAK98qZEQ6ytYSV7DPP2eNirbuznB41v4ihPOM4/GHZUqc9Mu occ8wJo78FKb5bODPdauQ03Yo2y47V7qKRc+uHBpISkRf2w1QpTdobKGfIuXTj0ZArSh 06SFoUrkvanTgt/be3exMXB5S+fU8LLRb8gILxU/lvQmwvovo46a4F9FjnMU8GuNan+p XYyg== MIME-Version: 1.0 X-Received: by 10.58.117.229 with SMTP id kh5mr18575171veb.27.1359986686053; Mon, 04 Feb 2013 06:04:46 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 4 Feb 2013 06:04:45 -0800 (PST) In-Reply-To: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> References: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> Date: Mon, 4 Feb 2013 23:04:45 +0900 X-Google-Sender-Auth: UPzow3U0m3vFRf43cyHebtfOS_I Message-ID: From: Barry Leiba To: draft-ietf-paws-problem-stmt-usecases-rqmts.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: paws@ietf.org, IETF discussion list Subject: Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC 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 Feb 2013 14:04:48 -0000 > The IESG has received a request from the Protocol to Access WS database > WG (paws) to consider the following document: > - 'Protocol to Access White Space (PAWS) Database: Use Cases and > Requirements' > as Informational > RFC Some Last Call comments, in advance of IESG Evaluation: -- General -- It's completely a non-starter that there's no email address for Anthony Mancuso; this has to be added. He won't get any of the IESG Evaluation messages this way, and the RFC Editor won't be able to contact him during the publication process. Abstracts should not contain citations, so the "[1]" citation should be removed. But perhaps more to the point, the Abstract is too long; the first paragraph can be trimmed after the second sentence (clipping everything beginning with "An obvious requirement", which doesn't need to be in the abstract (but should be and is in the Introduction)). The first and third references need to be in RFC reference form, and not simply as URIs. They should look something like this: [1] V. Chen, S. Das, Z. Lei, J. Malyar, P. McCann, "Protocol to Access Spectrum Database", draft-ietf-paws-protocol-01 (work in progress), December 2012 [3] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems", NIMA TR8350.2 Third Edition Amendment 1, January 2000, For the second reference: the RFC Editor will not generally accept Wikipedia as a reference, because its contents are unstable. Perhaps you could use something like instead? Just an alert: the RFC Editor will probably add hyphens when "white space" is used as an adjective, as in "white-space spectrum". This is particularly notable when you have "non-white space spectrum", which looks like space that is non-white (as opposed to "non-white-space spectrum"). You may feel free to wait for them to do that. Or you can do it. -- Section 1.1 -- The first paragraph seems overlong, and could do with splitting. Perhaps start a new paragraph with "An obvious requirement", and then another with "Academia and industry". -- Section 3.1 -- It looks like a lot of stuff in these earlier sections used to have 2119 language, and got Peted. You missed one: the "MUST" in the second sentence should be "must". -- Section 3.2 -- Does Figure 1 actually show anything useful or interesting? It says it illustrates a registration requirement, but I don't see it. I'd say that "most current and up-to-date information" is redundant (this also shows up in 6.3). And anyway, step 1 isn't a step -- you don't *do* anything there. -- Section 4.1 -- Figure 2 (Figure 2) depicts the general architecture such a simple master-slave network You're missing an "of". And is there a reason for "Figure 2 (Figure 2)" (and with other figures) that I don't understand? Bullet 3: There is no Section 4.1.1 to see. Bullet 4: It's not really optional (which implies that it's at the option of the master). It's required if the database requires it, but not all databases require it. Can you re-word? (And there is no Section 4.1.2, either.) Bullet 5: The part beginning "Note that" is out of place here, but that's OK, because it's repeated where it belongs, in bullet 6. I suggest you just remove it from here. -- Section 5 -- The databases may be regulatory specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be regulatory independent. Is "should be" appropriate? I should think "has to be". In Figure 11, note that there could be multiple databases serving white space devices. There is no Figure 11. You mean 7? The databases are locale specific since the regulations and available spectrum may vary. I think you mean "location-specific"; in the App world "locale" has a particular meaning that I don't think you mean (in other words, this is not an issue of local language). This applies to the use of "locale" elsewhere in the document as well. -- Section 5.1 -- Bullet 3 confuses me. First it says that it's possible for the device to know what rules are applicable, because it knows its location. Then it says to note that even though it knows its location, it may not be able to know what rule set to use. Is that not contradictory, or am I misunderstanding? Then it gives an important requirement that's buried at the end. I suggest putting the requirement earlier, and then following it with the extended explanation of the need for it. -- Section 5.2 -- The device needs to determine the location of the specific database to which it can send queries in addition to registering itself for operation and using the available spectrum. I'm having a lot of trouble parsing this sentence, and I'm still not sure I understand what it means. Can you try rephrasing it? -- Section 6.1 -- The Data Model MUST support WGS84 (see NGA: DoD World Geodetic System 1984 [3]). I think this statement makes that reference normative. D.3 The Data Model MUST support device description data that identifies a device (serial number, certification IDs, etc.) and describes device characteristics, such as or device class (fixed, mobile, portable, indoor, outdoor, etc.), Radio Access Technology (RAT), etc. Is the "or" in there a stray, or is there something else wrong? -- Section 6.2 -- P.9 The protocol MUST support an available spectrum request from the master device to the database. These parameters MAY include any of the parameters and attributes required to be supported in the Data Model Requirements. "These parameters" implies that you've mentioned parameters before, but you haven't. What parameters? (Same comment for P.10 and P.11.) -- Section 6.3 -- O.5 The master device MAY register with the database according to local regulatory policy. As above: this is not a correct use of MAY, because it's not at the option of the master device. In fact, as you say later in this requirement, it MUST register when it's required to. Please re-word this. (O.6) Parameters provided to the database MAY include device location, accuracy of the location Again... are these parameters provided purely at the option of the requestor (in which case "MAY" is fine), or are they provided because they're required by the database (in which case "MAY" is not right)? O.8 According to local regulator policy, a master device MAY inform the database of the actual frequency usage O.10 According to local regulatory policy, the master device MAY query the database with parameters received from the slave device. More of the same about the "MAY". -- Section 8 -- It is assumed that both the master device and the white space database have NOT been compromised from a security standpoint. Threat 1: User modifies a device to masquerade as another valid certified device Here's how I read these two adjacent paragraphs: (1) It is assumed that the device is not compromised; (2) Threat 1: A user compromises the device. Am I completely misunderstanding? (I also find the explanation below that to be convoluted. Can you work on it, and try to un-convolute it?) A master device MAY need to identify itself to the database and be authorized to obtain information about available spectrum. Totally wrong "MAY"; make it "might". Remember that "MAY" means that something is entirely optional. "MAY need to" is pretty much always wrong. Threat 4: The available spectrum information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using spectrum that is not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. That's quite a sentence. Please unravel it and re-word. Threat 6: Expand "MiM". The security requirements arising from the above threats are captured in the requirements of Section 6.1 (Section 6.1). There's that duplication again: "Section 6.1 (Section 6.1)" -- Section 9 -- This section is entirely unnecessary, and you should remove it. There's no need to repeat what you've already said. Barry From sm@resistor.net Mon Feb 4 09:21:23 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 4B24021F8A99; Mon, 4 Feb 2013 09:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zblPgety+kVe; Mon, 4 Feb 2013 09:21:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7362721F8A7E; Mon, 4 Feb 2013 09:21:22 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r14HLGPP020340; Mon, 4 Feb 2013 09:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359998481; bh=RsIHZkGiFeM7WBl4ktLKdH1vtt5r9yaRLd6j4MPFttA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=aOkiI/rp/vVi3EbvaZQZAynywbD3ASfbBjQ9YgIx9T4fCmjqWW8s1d1s7y3M14SrS Mt66G6RllMuOEbw+2FWTJx4dQ4hhXoEvf3hQRkMDL8b5HOS5hBLMo5SFqX8UXDSyMq A8jpa4rkUo+XAuMF/o6a/SYGiZs0Xxvm6muip3mA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359998481; i=@resistor.net; bh=RsIHZkGiFeM7WBl4ktLKdH1vtt5r9yaRLd6j4MPFttA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QNKaiUt0biSuw5m3kwemLnEbNbDk6Vnvz04jq/dPJlcxgSPNwKzXykTN6SGOtuYoq Z6KWGvVYDvQ7vHCNB38V2bOXXCxhG2TOKrh1wxv1tafFMoA0Bydc4Q70Pak15bnVvI q/DTWHSq3MZa04hnUb1Cirp7lTdmntSIOXswPGeI= Message-Id: <6.2.5.6.2.20130204064015.09261fa0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 04 Feb 2013 09:18:18 -0800 To: ietf@ietf.org From: SM In-Reply-To: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> References: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 04 Feb 2013 09:40:36 -0800 Cc: paws@ietf.org Subject: Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC 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 Feb 2013 17:21:23 -0000 At 05:24 01-02-2013, The IESG wrote: >The IESG has received a request from the Protocol to Access WS database >WG (paws) to consider the following document: >- 'Protocol to Access White Space (PAWS) Database: Use Cases and > Requirements' > as Informational >RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2013-02-15. Exceptionally, comments may be I read the draft. I am okay with whatever the working group decides. In Section 1.1: "Academia and Industry have studied multiple cognitive radio [2] mechanisms for use in such a scenario." The reference seemed odd. It took me some time to understand that it was put in to address a comment. However, the first (external) reference that defines that is a 404. There are two occurrences of the RFC 2119 boilerplate in the draft. In Section 3.1: "Before the master device can transmit in white space spectrum, it MUST obtain the address of a trusted white space database, which it will query for available white space spectrum." Why is this a MUST? In Section 4.2: "A simplified operation scenario of offloading content, such as video stream, from the a metered Internet connection to the a WS connection consists of the following steps:" What is a metered Internet connection? In Section 4.4: "To set up a replacement network, spectrum needs to be quickly cleared and reallocated to the crisis response organization." Is that what P.15 is about? BTW, O.17 uses a "should" for this. In Section 6.2: "P.3 The protocol MUST provide the ability for the database to authenticate the master device." "P.5 The messages sent by the master device to the database and the messages sent by the database to the master device MUST support integrity protection." "P.6 The protocol MUST provide the capability for messages sent by the master device and database to be encrypted." This sounds like the usual IETF security stuff. "P.8 The protocol MUST support a registration acknowledgement indicating the success of failure of the master device registration." The "success of failure" might need fixing. "P.14 The protocol MUST support a validation response from the database to the master to indicate if the slave device is validated by the WSDB. The validation response MUST indicate the success or failure of the validation request." What is WSDB? In Section 6.3: "O.1 The database and the master device MUST be connected to the Internet." What is the Internet? "O.2 A master device MUST be able to determine its location including uncertainty and confidence level." Does the working group plan to build its deliverables upon the GEOPRIV work? I found the draft easy to read. The draft goes into extraneous details in some parts. As an off-topic comment I see that the working group had the usual JSON versus XML discussion [1]. :-) I understood the concept of white spaces as discussed in the draft. If I understood correctly the usage of database is related to the data model in Section 6. On seeing Figure 7 it seemed to me that what was missing is an architecture document which provides a high-level view of how all this is supposed to work. I am not suggesting a reorganization of the draft as it may end up as too much work. The draft attempts to convince the reader about the importance of white spaces and its use cases. It's basically about database queries. Regards, -sm 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07261.html From barryleiba.mailing.lists@gmail.com Mon Feb 4 14:18:02 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 C457621F8B2E; Mon, 4 Feb 2013 14:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.892 X-Spam-Level: X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnvVl61agJ1b; Mon, 4 Feb 2013 14:18:02 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id B803721F8B1A; Mon, 4 Feb 2013 14:18:01 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id cz10so1995152veb.7 for ; Mon, 04 Feb 2013 14:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mwk6Dtt0fP0JgbsiWlZ/0+h9i6f9diGOtbPlyfWCmyU=; b=J9dvIzWpnE23CSIiANjp6ddNpLOByqI32TQxhqF3u4Z/IEH3KDAwn09yIvEgmQh6Ki DbbMafHW+JT7SPkVJN4Q1okpY47PvGK0UxS0Mh7Y8CaNph0hldUSF3OKqO9dLfxrcs3H oih+cJFG92fZ9mOOtzZ2Nym0u9ImVwMX5SidamNB1OlXPPJgSSUQBnjxhKK/OiNWf6Fy kKLPKabVkRftzWJ6dGd/2NObSfyPR942vTzdG3f67lHADGGglGXu9bucDzhamH0rgfD3 GoglfbL6+7Moo4LdlpWEXgzE0i6Q0A/b2QmErGKXtXJSSRmGggAy5jZQJ3LXmIOizC1P Aq3A== MIME-Version: 1.0 X-Received: by 10.52.91.142 with SMTP id ce14mr21563805vdb.84.1360016281063; Mon, 04 Feb 2013 14:18:01 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 4 Feb 2013 14:18:00 -0800 (PST) In-Reply-To: References: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> Date: Tue, 5 Feb 2013 07:18:00 +0900 X-Google-Sender-Auth: 9c9M6aWeyIVFz7eI_Ek9PhK09Sc Message-ID: From: Barry Leiba To: draft-ietf-paws-problem-stmt-usecases-rqmts.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: paws@ietf.org, IETF discussion list Subject: Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC 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 Feb 2013 22:18:02 -0000 >> The IESG has received a request from the Protocol to Access WS database >> WG (paws) to consider the following document: >> - 'Protocol to Access White Space (PAWS) Database: Use Cases and >> Requirements' >> as Informational >> RFC > > Some Last Call comments, in advance of IESG Evaluation: Sorry: one that I forgot to include. -- Section 5.1 -- Bullet 1 says "Radio/air interface agnostic", but seems to be talking about the messaging between the master and the DB, which will not necessarily be over an air interface. Please re-word this bullet, being careful to make the distinction between white-space usage (which will of course be over the air) and DB access (which could be over any network interface). Barry From hassnaamoustafa@gmail.com Thu Feb 7 10:32:27 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 5446F21F83EF for ; Thu, 7 Feb 2013 10:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6nJJrm110Ky for ; Thu, 7 Feb 2013 10:32:26 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84AB721F8319 for ; Thu, 7 Feb 2013 10:32:26 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so7293853wid.17 for ; Thu, 07 Feb 2013 10:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=RcadZ75cZXY1T9fF8P0RRB8kKITBJl3Cj9Qb5vDC99s=; b=ayBo6KtF3BJ1vSMLvZwM9dB8FJ1bZpVHOaU9XKdZZzR5HxQ0d2/9I2zi9308qWrBcB WNr4Bjs+kRxWKcVxO/f7B3N3DlUWp3tOHqgyfRG4O6fKkC37A5IUpFAzHTBUHOUM/PwK W/HGZWa6hgG6hcFP4D2j+WOBt2DBUZGR1Adocsq5avh+a7Q8mAgodDRg9qLJ/R2U/OdV YUdpscTC19a250sEPMt/5p0iUppMcJYDmAC2YJs5BzRnoFEY+wSX4OFOsrgUgwxNQyE/ Giry0lGFOiYrYS0Hvo/jNPqrZcYWxM5J4bahQRXb30WD+qZIFI/vi5cyXZ9Y9jHdFpNv qA2w== MIME-Version: 1.0 X-Received: by 10.194.92.65 with SMTP id ck1mr4786772wjb.54.1360261945622; Thu, 07 Feb 2013 10:32:25 -0800 (PST) Received: by 10.180.96.170 with HTTP; Thu, 7 Feb 2013 10:32:25 -0800 (PST) Date: Thu, 7 Feb 2013 10:32:25 -0800 Message-ID: From: Hassnaa Moustafa To: paws@ietf.org Content-Type: multipart/alternative; boundary=047d7bd91f1012013404d526aac3 Subject: [paws] Spectrum Sharing 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 Feb 2013 18:32:27 -0000 --047d7bd91f1012013404d526aac3 Content-Type: text/plain; charset=ISO-8859-1 Hi Brian, Gabor and all, I read the last use-cases draft ( draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt) and the recent version of the protocol draft, and I notice that the use-cases focus on White Spaces utilization. I have a couple of questions: - Does the WS database aims to consider the TVWS only or any other frequencies (WiFi, cellular, ... for instance)? - In the charter of the WG, the scope is on WS utilization, would the PAWS protocol under progress be applicable to (LSA: Licensed Share Access) also or would be limited to the WS? Thanks in advance. Regards, Hasnaa --047d7bd91f1012013404d526aac3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Brian, Gabor and all,
=A0
I read the last use-cases draft (draft-ietf-paws-problem-stmt-u= secases-rqmts-12.txt) and the recent version of the protocol draft, = and I notice that the use-cases focus on White Spaces utilization.
I have a couple of questions:
- Does the WS database aims to consider the TVWS only or any other fre= quencies (WiFi, cellular, ... for instance)?
- In the charter of the WG, the scope is on WS utilization, would the = PAWS protocol under progress be applicable to (LSA: Licensed Share Access) = also or=A0would=A0be limited to the WS?
=A0
Thanks in advance.
=A0
Regards,
Hasnaa
=A0
--047d7bd91f1012013404d526aac3-- From brian.rosen@neustar.biz Thu Feb 7 10:36: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 DC35121F88DD for ; Thu, 7 Feb 2013 10:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.809, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDs9IPT67M7R for ; Thu, 7 Feb 2013 10:36:08 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3D21F88D8 for ; Thu, 7 Feb 2013 10:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1360262033; x=1675617745; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=Fv6PziHod+Od0oM831EmGVSKNCOzunwquGSDdTV5Rh0=; b=P/DyMk8h4xU2dzYvgjYBFRrKdR97zs+z7UUxZLtrti8/4WXf+aS19+z2nuB7zw DScMr5W0RZD3OFw84araNwiw== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.16203062; Thu, 07 Feb 2013 13:33:52 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 7 Feb 2013 13:36:01 -0500 From: "Rosen, Brian" To: Hassnaa Moustafa , "paws@ietf.org" Date: Thu, 7 Feb 2013 13:35:58 -0500 Thread-Topic: [paws] Spectrum Sharing Thread-Index: Ac4FYfo5nr6gwuc/SkG0zwjajh/kQw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: 04YzEsaz85HXxg7s2EqVXw== Content-Type: multipart/alternative; boundary="_000_CD395DA613F85brianrosenneustarbiz_" MIME-Version: 1.0 Subject: Re: [paws] Spectrum Sharing 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 Feb 2013 18:36:10 -0000 --_000_CD395DA613F85brianrosenneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our goal in the IETF is to be as widely applicable as we can within our cha= rter, balanced against getting something done sooner rather than later. That's probably not as helpful as you would like. I think LSA is in scope =3D we're definitely not limited to TV bands, and w= e're not limited to unlicensed spectrum. brian From: Hassnaa Moustafa > Date: Thursday, February 7, 2013 1:32 PM To: "paws@ietf.org" > Subject: [paws] Spectrum Sharing Hi Brian, Gabor and all, I read the last use-cases draft (draft-ietf-paws-problem-stmt-usecases-rqmt= s-12.txt) and the recent version of the protocol draft, and I notice that t= he use-cases focus on White Spaces utilization. I have a couple of questions: - Does the WS database aims to consider the TVWS only or any other frequenc= ies (WiFi, cellular, ... for instance)? - In the charter of the WG, the scope is on WS utilization, would the PAWS = protocol under progress be applicable to (LSA: Licensed Share Access) also = or would be limited to the WS? Thanks in advance. Regards, Hasnaa --_000_CD395DA613F85brianrosenneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Our goal in the IETF is = to be as widely applicable as we can within our charter, balanced against g= etting something done sooner rather than later. 

<= div>That's probably not as helpful as you would like.

<= div>I think LSA is in scope =3D we're definitely not limited to TV bands, a= nd we're not limited to unlicensed spectrum.

brian=

From: Ha= ssnaa Moustafa <hassnaamous= tafa@gmail.com>
Date: Th= ursday, February 7, 2013 1:32 PM
To: "paws@ietf.org" <paws@ietf.org>
Subject: [paws] Spectrum Sharing

<= meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
Hi Brian, Gabor and all,
 
I read the last = use-cases draft (draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt) and th= e recent version of the protocol draft, and I notice that the use-cases foc= us on White Spaces utilization.
I have a couple of questions:
- Does the = WS database aims to consider the TVWS only or any other frequencies (WiFi, = cellular, ... for instance)?
- In the charter of the WG, the scop= e is on WS utilization, would the PAWS protocol under progress be applicabl= e to (LSA: Licensed Share Access) also or would be limited to the= WS?
 
Thanks in advance.
 
Regards,
Hasnaa
 
 --_000_CD395DA613F85brianrosenneustarbiz_-- From pierrejeanmuller@gmail.com Thu Feb 7 13:14: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 3CBEB21F87EE for ; Thu, 7 Feb 2013 13:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fvn8ld9aRYoT for ; Thu, 7 Feb 2013 13:14:10 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1D94121F8809 for ; Thu, 7 Feb 2013 13:14:09 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so92715wid.12 for ; Thu, 07 Feb 2013 13:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=PaDOzFUbc3fZl50Qao++v5pwfqbt0ZiJXH0sG5ejNoE=; b=FIMUBxwo7S+Rceg0wos5ntvGCdqkgMHLG/zwn9Fi/MO+xuwftiCf+jnpd/dWQu608Y tSFhTFmWPYSQ0k93WrWJDn2BjCAV4+9gE1Y7fkSRG5T+g+B1RGNUfVKoFGsBp550TAUr XkUjnOdeB+adTRYAjwbVqvTbWWTZSxjmY6Cs9/eEL6R8gWLGuuHeugbL5CuUrYAXb7xX me0ChRiz3V4+/TqDFMc/OLLrw6kyrWQFaozqoff68E7eyeQl4H2BmAF0TTEhcLjpHez+ eO0C+WRQoY0+Xr+yVPdBWPm/UaT2Mwn0pfIdEmocwQmPkG8T4zyBQ8zaMSjm6qKBptav URrA== X-Received: by 10.194.158.100 with SMTP id wt4mr5624513wjb.37.1360271649140; Thu, 07 Feb 2013 13:14:09 -0800 (PST) Received: from [192.168.1.22] (26.26.70.86.rev.sfr.net. [86.70.26.26]) by mx.google.com with ESMTPS id eo10sm11861049wib.9.2013.02.07.13.14.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 13:14:08 -0800 (PST) Message-ID: <51141923.2060508@gmail.com> Date: Thu, 07 Feb 2013 22:14:11 +0100 From: Gmail User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: paws@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020105020108080704060500" Subject: Re: [paws] Spectrum Sharing 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 Feb 2013 21:14:11 -0000 This is a multi-part message in MIME format. --------------020105020108080704060500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Brian, Hassnaa, Despite having some characteristics in common, LSA and WS are, to me, different animals and i doubt there is enough synergy between WS & LSA to fall naturally into the scope of PAWS: "Sharing under the LSA is binary by nature, with spectrum being used by either the incumbent(s) or the LSA licensee(s). I believe PAWS framework (i.e. direct link between a DB and a master device) is tightly coupled with the unlicensed nature of WS concept where LSA is about "exclusive spectrum rights of use where and when the spectrum is not used by the incumbent(s)". Regards, Pierre-Jean Muller RED Technologies Le 07/02/2013 19:35, Rosen, Brian a écrit : > Our goal in the IETF is to be as widely applicable as we can within > our charter, balanced against getting something done sooner rather > than later. > > That's probably not as helpful as you would like. > > I think LSA is in scope = we're definitely not limited to TV bands, > and we're not limited to unlicensed spectrum. > > brian > > From: Hassnaa Moustafa > > Date: Thursday, February 7, 2013 1:32 PM > To: "paws@ietf.org " > > Subject: [paws] Spectrum Sharing > > Hi Brian, Gabor and all, > I read the last use-cases draft > (draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt) and the recent > version of the protocol draft, and I notice that the use-cases focus > on White Spaces utilization. > I have a couple of questions: > - Does the WS database aims to consider the TVWS only or any other > frequencies (WiFi, cellular, ... for instance)? > - In the charter of the WG, the scope is on WS utilization, would the > PAWS protocol under progress be applicable to (LSA: Licensed Share > Access) also or would be limited to the WS? > Thanks in advance. > Regards, > Hasnaa > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --------------020105020108080704060500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Brian, Hassnaa,

Despite having some characteristics in common, LSA and WS are, to me, different animals and i doubt there is enough synergy between WS & LSA to fall naturally into the scope of PAWS:  "Sharing under the LSA is binary by nature, with spectrum being used by either the incumbent(s) or the LSA licensee(s). I believe PAWS framework (i.e. direct link between a DB and a master device) is tightly coupled with the unlicensed nature of WS concept where LSA is about "exclusive spectrum rights of use where and when the spectrum is not used by the incumbent(s)".

Regards,
Pierre-Jean Muller
RED Technologies 

Le 07/02/2013 19:35, Rosen, Brian a écrit :
Our goal in the IETF is to be as widely applicable as we can within our charter, balanced against getting something done sooner rather than later. 

That's probably not as helpful as you would like.

I think LSA is in scope = we're definitely not limited to TV bands, and we're not limited to unlicensed spectrum.

brian

From: Hassnaa Moustafa <hassnaamoustafa@gmail.com>
Date: Thursday, February 7, 2013 1:32 PM
To: "paws@ietf.org" <paws@ietf.org>
Subject: [paws] Spectrum Sharing

Hi Brian, Gabor and all,
 
I read the last use-cases draft (draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt) and the recent version of the protocol draft, and I notice that the use-cases focus on White Spaces utilization.
I have a couple of questions:
- Does the WS database aims to consider the TVWS only or any other frequencies (WiFi, cellular, ... for instance)?
- In the charter of the WG, the scope is on WS utilization, would the PAWS protocol under progress be applicable to (LSA: Licensed Share Access) also or would be limited to the WS?
 
Thanks in advance.
 
Regards,
Hasnaa
 
 

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

--------------020105020108080704060500-- From brian.rosen@neustar.biz Thu Feb 7 13:25:56 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 1AB0821F88C8 for ; Thu, 7 Feb 2013 13:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FZHRAn5yz19 for ; Thu, 7 Feb 2013 13:25:55 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id CA29621F86AA for ; Thu, 7 Feb 2013 13:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1360272547; x=1675630748; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=RYIag72+3IORA1M3+hUSrIU8uzJX26kb5KGNgbE/o5E=; b=S7ZE6sKsjdTJJqQ5tzt/G5O0iqBJS9qPRdw/W+TYFJ95Vi7wQJIli/a37iIoID RNYshDHOyMxPjOWK5Ix2d4YQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.19535449; Thu, 07 Feb 2013 16:29:06 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 7 Feb 2013 16:25:52 -0500 From: "Rosen, Brian" To: Gmail , "paws@ietf.org" Date: Thu, 7 Feb 2013 16:25:46 -0500 Thread-Topic: [paws] Spectrum Sharing Thread-Index: Ac4FebSrvKi3uMyVTkefwniDNBYAzA== Message-ID: In-Reply-To: <51141923.2060508@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 34pxadn9f5MhurcmfN3H1w== Content-Type: multipart/alternative; boundary="_000_CD3984E7141F0brianrosenneustarbiz_" MIME-Version: 1.0 Subject: Re: [paws] Spectrum Sharing 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 Feb 2013 21:25:56 -0000 --_000_CD3984E7141F0brianrosenneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We would need to understand what in our charter doesn't work for LSA. ISTM that as long as there is a database, the database tracks the incumbent= 's use, and provides a response to a location based query for available spe= ctrum, that it fits, regardless of whether the secondary user is licensed o= r unlicensed. I think we do get out of scope if, for example, the spectrum available to o= ne querier is different from another, and we're definitely not dealing with= shared use of spectrum (sharing among secondary users). Sharing under WS is binary =96 either an incumbent user is using it, or sec= ondary users can use it. Brian From: Gmail > Date: Thursday, February 7, 2013 4:14 PM To: "paws@ietf.org" > Subject: Re: [paws] Spectrum Sharing Hi Brian, Hassnaa, Despite having some characteristics in common, LSA and WS are, to me, diffe= rent animals and i doubt there is enough synergy between WS & LSA to fall n= aturally into the scope of PAWS: "Sharing under the LSA is binary by natur= e, with spectrum being used by either the incumbent(s) or the LSA licensee(= s). I believe PAWS framework (i.e. direct link between a DB and a master de= vice) is tightly coupled with the unlicensed nature of WS concept where LSA= is about "exclusive spectrum rights of use where and when the spectrum is = not used by the incumbent(s)". Regards, Pierre-Jean Muller RED Technologies Le 07/02/2013 19:35, Rosen, Brian a =E9crit : Our goal in the IETF is to be as widely applicable as we can within our cha= rter, balanced against getting something done sooner rather than later. That's probably not as helpful as you would like. I think LSA is in scope =3D we're definitely not limited to TV bands, and w= e're not limited to unlicensed spectrum. brian From: Hassnaa Moustafa > Date: Thursday, February 7, 2013 1:32 PM To: "paws@ietf.org" > Subject: [paws] Spectrum Sharing Hi Brian, Gabor and all, I read the last use-cases draft (draft-ietf-paws-problem-stmt-usecases-rqmt= s-12.txt) and the recent version of the protocol draft, and I notice that t= he use-cases focus on White Spaces utilization. I have a couple of questions: - Does the WS database aims to consider the TVWS only or any other frequenc= ies (WiFi, cellular, ... for instance)? - In the charter of the WG, the scope is on WS utilization, would the PAWS = protocol under progress be applicable to (LSA: Licensed Share Access) also = or would be limited to the WS? Thanks in advance. Regards, Hasnaa _______________________________________________ paws mailing list paws@ietf.orghttps://www.ietf.org/mailman/listinfo/pa= ws --_000_CD3984E7141F0brianrosenneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
We would need to understand wha= t in our charter doesn't work for LSA.

ISTM that a= s long as there is a database, the database tracks the incumbent's use, and= provides a response to a location based query for available spectrum, that= it fits, regardless of whether the secondary user is licensed or unlicense= d.

I think we do get out of scope if, for example,= the spectrum available to one querier is different from another, and we're= definitely not dealing with shared use of spectrum (sharing among secondar= y users).

Sharing under WS is binary =96 either an= incumbent user is using it, or secondary users can use it.

<= /div>
Brian

F= rom: Gmail <pierre= jeanmuller@gmail.com>
Date: Thursday, February 7, 2013 4:14 PM
= To: "paws@ietf.org" = <paws@ietf.org>
Subject: Re: [paws] Spectrum Sharing

Hi Brian, Hassnaa,

Despite having some characteristics in common, LSA and WS are, to me, diffe= rent animals and i doubt there is enough synergy between WS & LSA to fa= ll naturally into the scope of PAWS:  "Sharing under the LSA is b= inary by nature, with spectrum being used by either the incumbent(s) or the LSA licensee(s). I believe PAWS framework (i.e. di= rect link between a DB and a master device) is tightly coupled with the unl= icensed nature of WS concept where LSA is about "exclusive spectrum ri= ghts of use where and when the spectrum is not used by the incumbent(s)".

Regards,
Pierre-Jean Muller
RED Technologies 

Le 07/02/2013 19:35, Rosen, Brian a =E9crit :
Our g= oal in the IETF is to be as widely applicable as we can within our charter,= balanced against getting something done sooner rather than later. 

That's probably not as helpful as you would like.

I think LSA is in scope =3D we're definitely not lim= ited to TV bands, and we're not limited to unlicensed spectrum.
<= br>
brian

<= div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">From: Hassnaa Moustafa <hassnaamoustafa@gmail.com>=
Date: Thursday, February 7, 201= 3 1:32 PM
To: "paws@ietf.org" <<= a moz-do-not-send=3D"true" href=3D"mailto:paws@ietf.org">paws@ietf.org&= gt;
Subject: [paws] Spectrum Sha= ring

Hi Brian, Gabor and all,
<= div> 
I read the last use-cases draft (draft-ietf-paws-problem-stmt= -usecases-rqmts-12.txt) and the recent version of the protocol draft= , and I notice that the use-cases focus on White Spaces utilization.
I have a couple of questions:=
- Does the WS database aims to consider the TVWS only or any oth= er frequencies (WiFi, cellular, ... for instance)?
- In the chart= er of the WG, the scope is on WS utilization, would the PAWS protocol under= progress be applicable to (LSA: Licensed Share Access) also or would&= nbsp;be limited to the WS?
 
Thanks in advance.
 
Regards,
Hasnaa
 

<= br>
_______________________________________________
paws mailing list
paws@ie=
tf.orghttps://www.ietf.org/mailman/listinfo/paws
<= /blockquote>
--_000_CD3984E7141F0brianrosenneustarbiz_-- From jmalyar@telcordia.com Thu Feb 7 13:42:32 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 C66A621F853E for ; Thu, 7 Feb 2013 13:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mslQK3ZzNumJ for ; Thu, 7 Feb 2013 13:42:32 -0800 (PST) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.23]) by ietfa.amsl.com (Postfix) with ESMTP id DB16621F83EF for ; Thu, 7 Feb 2013 13:42:31 -0800 (PST) Received: from pya-dte-bms01.telcordia.com (pya-dte-bms01.cc.telcordia.com [128.96.37.48]) by dnsmx2pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id r17LgTNA028377; Thu, 7 Feb 2013 16:42:30 -0500 (EST) X-AuditID: 80602530-b7f206d0000040f7-6d-51141fc66d99 Received: from rrc-dte-exhb3.dte.telcordia.com (rrc-dte-exhb3.cc.telcordia.com [128.96.105.72]) by pya-dte-bms01.telcordia.com (Symantec Messaging Gateway) with SMTP id 97.39.16631.6CF14115; Thu, 7 Feb 2013 16:42:30 -0500 (EST) Received: from RRC-DTE-EXMB4.dte.telcordia.com ([fe80::8ad:5ccb:8fe0:2314]) by rrc-dte-exhb3.dte.telcordia.com ([2002:8060:6948::8060:6948]) with mapi id 14.01.0379.000; Thu, 7 Feb 2013 16:42:30 -0500 From: "Malyar, John P" To: Gmail , "paws@ietf.org" Thread-Topic: [paws] Spectrum Sharing Thread-Index: AQHOBWF9j4c0P6Q54UuBQ+8YK5uYZJhvDP8AgAAsNYD//67qQA== Date: Thu, 7 Feb 2013 21:42:08 +0000 Message-ID: References: <51141923.2060508@gmail.com> In-Reply-To: <51141923.2060508@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2002:8060:ab78::8060:ab78] Content-Type: multipart/alternative; boundary="_000_E7916FF82420BB40A104D4CAAB11C78828001A31rrcdteexmb4dtet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsXSkJDpoXtMXiTQYMc/DYsDPXOZLU5u38rm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVMfX6MpeBLasXkR2eZGhh3RHQxcnJICJhI HNp6kA3CFpO4cG89mC0k8IxRYtLDwi5GLiD7DKPE/P6V7CAJNgE9iVv/OsFsEQF3iQtfjoE1 CAuoSGx5fIQVIq4qcWTJHijbSeJnx3kWEJsFqGbrltlMIDavQJjE7gW3GSGWBUu8734LVs8p oCkxbzNEPSPQQd9PrQGrZxYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+B9TLAWTrSrQuS4Eoz5fo aPzOBrFKUOLkzCcsExhFZiGZNAtJ2SwkZRBxPYkbU6ewQdjaEssWvmaGsHUlZvw7xIIsvoCR fRWjdEFlom5KSapuUm6xgaFeSWpOcn5RSmaiXnJ+7iZGcISpGuxg3P1L/RCjNAeLkjjvFn1/ HyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M+Vlz438bnpMPWLQ04rvBc99bia8rKzLmpBXo mVSf/v+C94uilW3QN3G+T4+OzndIOfWqz+dxIZPKXJP4/LuPrDkXzBV+spk1+ZhoVcGFmTPe cfjP1SnIC0zg7qtqnhk4SeB1WWSW3u8Ur53KSplm4uoHjs546Bgedu70lR8O0rP/Ry1UunVR iaU4I9FQi7moOBEAg2j1dX4CAAA= Subject: Re: [paws] Spectrum Sharing 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 Feb 2013 21:42:32 -0000 --_000_E7916FF82420BB40A104D4CAAB11C78828001A31rrcdteexmb4dtet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would respectfully disagree with the conclusion below. The interface betw= een the Radio (device) and the Database is for accessing available (white s= pace) spectrum. The policy on how to determine if the spectrum is available= (or not) is separate from the Interface. If the Regulator chooses to imple= ment a specific policy regarding sharing such as including prioritization o= f users, limiting the number of concurrent users or allowing unlicensed acc= ess of a band it is internal to the database implementation for that locati= on/Regulator. IMHO the value of the interface is to provide an abstraction = for devices worldwide regarding the potential numerous regulatory policies. My understanding since the beginning was we were not limiting the scope to = TVWS; hence the title PAWS and not PATVWS. Regards, John Malyar From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gma= il Sent: Thursday, February 07, 2013 4:14 PM To: paws@ietf.org Subject: Re: [paws] Spectrum Sharing Hi Brian, Hassnaa, Despite having some characteristics in common, LSA and WS are, to me, diffe= rent animals and i doubt there is enough synergy between WS & LSA to fall n= aturally into the scope of PAWS: "Sharing under the LSA is binary by natur= e, with spectrum being used by either the incumbent(s) or the LSA licensee(= s). I believe PAWS framework (i.e. direct link between a DB and a master de= vice) is tightly coupled with the unlicensed nature of WS concept where LSA= is about "exclusive spectrum rights of use where and when the spectrum is = not used by the incumbent(s)". Regards, Pierre-Jean Muller RED Technologies Le 07/02/2013 19:35, Rosen, Brian a =E9crit : Our goal in the IETF is to be as widely applicable as we can within our cha= rter, balanced against getting something done sooner rather than later. That's probably not as helpful as you would like. I think LSA is in scope =3D we're definitely not limited to TV bands, and w= e're not limited to unlicensed spectrum. brian From: Hassnaa Moustafa > Date: Thursday, February 7, 2013 1:32 PM To: "paws@ietf.org" > Subject: [paws] Spectrum Sharing Hi Brian, Gabor and all, I read the last use-cases draft (draft-ietf-paws-problem-stmt-usecases-rqmt= s-12.txt) and the recent version of the protocol draft, and I notice that t= he use-cases focus on White Spaces utilization. I have a couple of questions: - Does the WS database aims to consider the TVWS only or any other frequenc= ies (WiFi, cellular, ... for instance)? - In the charter of the WG, the scope is on WS utilization, would the PAWS = protocol under progress be applicable to (LSA: Licensed Share Access) also = or would be limited to the WS? Thanks in advance. Regards, Hasnaa _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_E7916FF82420BB40A104D4CAAB11C78828001A31rrcdteexmb4dtet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would respectfully disa= gree with the conclusion below. The interface between the Radio (device) an= d the Database is for accessing available (white space) spectrum. The policy on how to determine if the spectrum is available (or = not) is separate from the Interface. If the Regulator chooses to implement = a specific policy regarding sharing such as including prioritization of use= rs, limiting the number of concurrent users or allowing unlicensed access of a band it is internal to the databa= se implementation for that location/Regulator. IMHO the value of the interf= ace is to provide an abstraction for devices worldwide regarding the potent= ial numerous regulatory policies.

 <= /p>

My understanding since th= e beginning was we were not limiting the scope to TVWS; hence the title PAW= S and not PATVWS.

 <= /p>

Regards,

 <= /p>

John Malyar   &= nbsp;

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.o= rg] On Behalf Of Gmail
Sent: Thursday, February 07, 2013 4:14 PM
To: paws@ietf.org
Subject: Re: [paws] Spectrum Sharing

 

Hi Brian, Hassnaa,

Despite having some characteristics in common, LSA and WS are, to me, diffe= rent animals and i doubt there is enough synergy between WS & LSA to fa= ll naturally into the scope of PAWS:  "Sharing under the LSA is b= inary by nature, with spectrum being used by either the incumbent(s) or the LSA licensee(s). I believe PAWS framework (i.e. di= rect link between a DB and a master device) is tightly coupled with the unl= icensed nature of WS concept where LSA is about "exclusive spectrum ri= ghts of use where and when the spectrum is not used by the incumbent(s)".

Regards,
Pierre-Jean Muller
RED Technologies 

Le 07/02/2013 19:35, Rosen, Brian a =E9crit :

Our goal in the IETF is to be as widely applicable a= s we can within our charter, balanced against getting something done sooner= rather than later. 

 

That's probably not as helpful as you would like.

 

I think LSA is in scope =3D we're definitely not lim= ited to TV bands, and we're not limited to unlicensed spectrum.<= /p>

 

brian

 

From: Hassnaa Moustafa <hassnaamoustafa@gmail.com>
Date: Thursday, February 7, 2013 1:32 PM
To: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] Spectrum Sharing

 

Hi Brian, Gabor and all,

 

I read the last use-cases draft (draft-= ietf-paws-problem-stmt-usecases-rqmts-12.txt) and the recent version= of the protocol draft, and I notice that the use-cases focus on White Spaces utilization.

I have a couple of questions:

- Does the WS database aims to consider the TVWS onl= y or any other frequencies (WiFi, cellular, ... for instance)?

- In the charter of the WG, the scope is on WS utili= zation, would the PAWS protocol under progress be applicable to (LSA: Licen= sed Share Access) also or would be limited to the WS?<= /p>

 

Thanks in advance.

 

Regards,

Hasnaa

 




_______________________________________________
paws mailing list
paws@ietf.org
https://www.iet=
f.org/mailman/listinfo/paws

 

--_000_E7916FF82420BB40A104D4CAAB11C78828001A31rrcdteexmb4dtet_-- From peter@spectrumbridge.com Thu Feb 7 13:48:27 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 729E321F8414 for ; Thu, 7 Feb 2013 13:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIiVdLxIoEcq for ; Thu, 7 Feb 2013 13:48:26 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 09E4521F8939 for ; Thu, 7 Feb 2013 13:48:24 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 7 Feb 2013 16:48:18 -0500 From: Peter Stanforth To: "Malyar, John P" , Gmail , "paws@ietf.org" Date: Thu, 7 Feb 2013 16:48:15 -0500 Thread-Topic: [paws] Spectrum Sharing Thread-Index: Ac4FfNb0R7t9r2FXTZmvB3YVq5cf2w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD398AC471A3peterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] Spectrum Sharing 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 Feb 2013 21:48:27 -0000 --_000_CD398AC471A3peterspectrumbridgecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Absolutely! PAWS is a protocol for a device to ask for spectrum to use. As such the PAW= S protocol must include enough information for the database to decide what = answer to give. The response must clearly define what access rights the device has been giv= en. No more, no less. From: , John P = > Date: Thursday, February 7, 2013 4:42 PM To: Gmail >, = "paws@ietf.org" > Subject: Re: [paws] Spectrum Sharing I would respectfully disagree with the conclusion below. The interface betw= een the Radio (device) and the Database is for accessing available (white s= pace) spectrum. The policy on how to determine if the spectrum is available= (or not) is separate from the Interface. If the Regulator chooses to imple= ment a specific policy regarding sharing such as including prioritization o= f users, limiting the number of concurrent users or allowing unlicensed acc= ess of a band it is internal to the database implementation for that locati= on/Regulator. IMHO the value of the interface is to provide an abstraction = for devices worldwide regarding the potential numerous regulatory policies. My understanding since the beginning was we were not limiting the scope to = TVWS; hence the title PAWS and not PATVWS. Regards, John Malyar From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gmail Sent: Thursday, February 07, 2013 4:14 PM To: paws@ietf.org Subject: Re: [paws] Spectrum Sharing Hi Brian, Hassnaa, Despite having some characteristics in common, LSA and WS are, to me, diffe= rent animals and i doubt there is enough synergy between WS & LSA to fall n= aturally into the scope of PAWS: "Sharing under the LSA is binary by natur= e, with spectrum being used by either the incumbent(s) or the LSA licensee(= s). I believe PAWS framework (i.e. direct link between a DB and a master de= vice) is tightly coupled with the unlicensed nature of WS concept where LSA= is about "exclusive spectrum rights of use where and when the spectrum is = not used by the incumbent(s)". Regards, Pierre-Jean Muller RED Technologies Le 07/02/2013 19:35, Rosen, Brian a =E9crit : Our goal in the IETF is to be as widely applicable as we can within our cha= rter, balanced against getting something done sooner rather than later. That's probably not as helpful as you would like. I think LSA is in scope =3D we're definitely not limited to TV bands, and w= e're not limited to unlicensed spectrum. brian From: Hassnaa Moustafa > Date: Thursday, February 7, 2013 1:32 PM To: "paws@ietf.org" > Subject: [paws] Spectrum Sharing Hi Brian, Gabor and all, I read the last use-cases draft (draft-ietf-paws-problem-stmt-usecases-rqmt= s-12.txt) and the recent version of the protocol draft, and I notice that t= he use-cases focus on White Spaces utilization. I have a couple of questions: - Does the WS database aims to consider the TVWS only or any other frequenc= ies (WiFi, cellular, ... for instance)? - In the charter of the WG, the scope is on WS utilization, would the PAWS = protocol under progress be applicable to (LSA: Licensed Share Access) also = or would be limited to the WS? Thanks in advance. Regards, Hasnaa _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CD398AC471A3peterspectrumbridgecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Absolutely!
PA= WS is a protocol for a device to ask for spectrum to use. As such the PAWS = protocol must include enough information for the database to decide what an= swer to give.
The response must clearly define what access rights= the device has been given.
No more, no less.

From: <Malyar>, John P= <jmalyar@telcordia.com>=
Date: Thursday, February 7, 20= 13 4:42 PM
To: Gmail <pierrejeanmuller@gmail.com>,= "paws@ietf.org" <paws@ietf.org>
S= ubject: Re: [paws] Spectrum Sharing

I would respectfully disagree with the conclusion bel= ow. The interface between the Radio (device) and the Database is for access= ing available (white space) spectrum. The policy on how to determine if the spectrum is available (or = not) is separate from the Interface. If the Regulator chooses to implement = a specific policy regarding sharing such as including prioritization of use= rs, limiting the number of concurrent users or allowing unlicensed access of a band it is internal to the databa= se implementation for that location/Regulator. IMHO the value of the interf= ace is to provide an abstraction for devices worldwide regarding the potent= ial numerous regulatory policies.

 

My understanding since the beginning was we were not limitin= g the scope to TVWS; hence the title PAWS and not PATVWS.=

 

Regards,

 

John Malyar    

 

=

From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gmail
Sent: Thursday, February 07, 2013 4:14 = PM
To: paws@ietf.org
S= ubject: Re: [paws] Spectrum Sharing

 

Hi Br= ian, Hassnaa,

Despite having some characteristics in common, LSA and WS are, to me, diffe= rent animals and i doubt there is enough synergy between WS & LSA to fa= ll naturally into the scope of PAWS:  "Sharing under the LSA is binary= by nature, with spectrum being used by either the incumbent(s) or the LSA licensee(s). I believe PAWS framework (i.e. di= rect link between a DB and a master device) is tightly coupled with the unl= icensed nature of WS concept where LSA is about "exclusive spectrum rights = of use where and when the spectrum is not used by the incumbent(s)".

Regards,
Pierre-Jean Muller
RED Technologies 

Le 07/02/2013 19:35, Rosen, Brian a =E9crit :

Our goal in the IETF is to be as widely applicable as we can within= our charter, balanced against getting something done sooner rather than la= ter. 

 

That's probably not as helpful as yo= u would like.

 

I think LSA is in scope =3D we're= definitely not limited to TV bands, and we're not limited to unlicensed sp= ectrum.

 

brian

 

<= b>From: Hassnaa Moustafa <hassn= aamoustafa@gmail.com>
Date: Thursday, February 7, 2013 1:3= 2 PM
To: "paws@ietf.org" <= ;paws@ietf.org>
Subject: = [paws] Spectrum Sharing

 

Hi Bri= an, Gabor and all,

 

I read the last use-cases dr= aft (dr= aft-ietf-paws-problem-stmt-usecases-rqmts-12.txt) and the recent ver= sion of the protocol draft, and I notice that the use-cases focus on White Spaces utilization.

I have a couple of questions:

- Does the WS database aims to consider the TVWS only or any ot= her frequencies (WiFi, cellular, ... for instance)?

- In the charter of the WG, the scope is on WS uti= lization, would the PAWS protocol under progress be applicable to (LSA: Lic= ensed Share Access) also or would be limited to the WS?

 

Thanks in advance.

 

Regards,<= o:p>

Hasnaa

=

 




____________________________=
___________________
paws mailing list
= 
paws@ietf.org
https://www.ietf.o= rg/mailman/listinfo/paws

 

 --_000_CD398AC471A3peterspectrumbridgecom_-- From pierrejeanmuller@gmail.com Thu Feb 7 14:19: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 0A9E421F858E for ; Thu, 7 Feb 2013 14:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=-2.268, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v42NriSLQ380 for ; Thu, 7 Feb 2013 14:19:43 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 85ED321F856F for ; Thu, 7 Feb 2013 14:19:42 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id r5so2521407wey.32 for ; Thu, 07 Feb 2013 14:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type; bh=OjBYQTezkNkDO/jX7ZJNnT0+MKSxt2ZuWD16NKLf9dw=; b=bYfjlCvK+ns3Pj2La08ExqjPhGdlSzVbBrk+EGfXp7mNGZv7zXaVek9NLDyoUKcRte O/2h6HFfz5Sw0MhjFbKEgVdClWjKU4oj+cEW8S9wE0ThYUTT27bFigHxRSTlDV3u4ijz 7Wq7l9ZuEjgiZ71N21+oPW4mV2otO4uyxazIQvtLRhU3cvqPkWR/zRrRP1gi12WbMrK0 TtUmDgbv0KlqRyfe6nTl8SKylFWrEDvAxpsv1it9vOA2DMbwbf5WWf9dlLe4UrdjNOKZ /55eJMdE6oIYNDYmfou06xBh2mCHNZ6V0ln/fn59wKpqdXDgvWx1p716Hu8t6WvDZ9yb eyeg== X-Received: by 10.194.171.198 with SMTP id aw6mr5939568wjc.3.1360275581520; Thu, 07 Feb 2013 14:19:41 -0800 (PST) Received: from [192.168.1.22] (26.26.70.86.rev.sfr.net. [86.70.26.26]) by mx.google.com with ESMTPS id cu7sm11255959wib.8.2013.02.07.14.19.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 14:19:40 -0800 (PST) Message-ID: <51142880.6030602@gmail.com> Date: Thu, 07 Feb 2013 23:19:44 +0100 From: Gmail User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: paws@ietf.org References: <51142333.6010005@gmail.com> In-Reply-To: <51142333.6010005@gmail.com> X-Forwarded-Message-Id: <51142333.6010005@gmail.com> Content-Type: multipart/alternative; boundary="------------060200000605000701090001" Subject: [paws] Fwd: Re: Spectrum Sharing 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 Feb 2013 22:19:44 -0000 This is a multi-part message in MIME format. --------------060200000605000701090001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Ok you may see different scenarios under the LSA concept but so far it has been thought as an enabler to contribute to more frequency bands for mobile broadband with "individual" licenses of "10 to 15 years" duration where such "a protocol for a device to ask for spectrum to use" may not be the obvious implementation. Note i do not disagree that PAWS is not limited to TV bands. Regards, Pierre-Jean Muller RED Technologies Le 07/02/2013 22:48, Peter Stanforth a écrit : > Absolutely! > PAWS is a protocol for a device to ask for spectrum to use. As such > the PAWS protocol must include enough information for the database to > decide what answer to give. > The response must clearly define what access rights the device has > been given. > No more, no less. > > From: , John P > > Date: Thursday, February 7, 2013 4:42 PM > To: Gmail >, "paws@ietf.org > " > > Subject: Re: [paws] Spectrum Sharing > > I would respectfully disagree with the conclusion below. The interface > between the Radio (device) and the Database is for accessing available > (white space) spectrum. The policy on how to determine if the spectrum > is available (or not) is separate from the Interface. If the Regulator > chooses to implement a specific policy regarding sharing such as > including prioritization of users, limiting the number of concurrent > users or allowing unlicensed access of a band it is internal to the > database implementation for that location/Regulator. IMHO the value of > the interface is to provide an abstraction for devices worldwide > regarding the potential numerous regulatory policies. > > My understanding since the beginning was we were not limiting the > scope to TVWS; hence the title PAWS and not PATVWS. > > Regards, > > John Malyar > > *From:*paws-bounces@ietf.org > [mailto:paws-bounces@ietf.org] *On Behalf Of *Gmail > *Sent:* Thursday, February 07, 2013 4:14 PM > *To:* paws@ietf.org > *Subject:* Re: [paws] Spectrum Sharing > > Hi Brian, Hassnaa, > > Despite having some characteristics in common, LSA and WS are, to me, > different animals and i doubt there is enough synergy between WS & LSA > to fall naturally into the scope of PAWS: "Sharing under the LSA is > binary by nature, with spectrum being used by either the incumbent(s) > or the LSA licensee(s). I believe PAWS framework (i.e. direct link > between a DB and a master device) is tightly coupled with the > unlicensed nature of WS concept where LSA is about "exclusive spectrum > rights of use where and when the spectrum is not used by the > incumbent(s)". > > Regards, > Pierre-Jean Muller > RED Technologies > > Le 07/02/2013 19:35, Rosen, Brian a écrit : > > Our goal in the IETF is to be as widely applicable as we can > within our charter, balanced against getting something done sooner > rather than later. > > That's probably not as helpful as you would like. > > I think LSA is in scope = we're definitely not limited to TV > bands, and we're not limited to unlicensed spectrum. > > brian > > *From: *Hassnaa Moustafa > > *Date: *Thursday, February 7, 2013 1:32 PM > *To: *"paws@ietf.org " > > *Subject: *[paws] Spectrum Sharing > > Hi Brian, Gabor and all, > > I read the last use-cases draft > (draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt) and the > recent version of the protocol draft, and I notice that the > use-cases focus on White Spaces utilization. > > I have a couple of questions: > > - Does the WS database aims to consider the TVWS only or any other > frequencies (WiFi, cellular, ... for instance)? > > - In the charter of the WG, the scope is on WS utilization, would > the PAWS protocol under progress be applicable to (LSA: Licensed > Share Access) also or would be limited to the WS? > > Thanks in advance. > > Regards, > > Hasnaa > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > --------------060200000605000701090001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Ok you may see different scenarios under the LSA concept but so far it has been thought as an enabler to contribute to more frequency bands for mobile broadband with "individual" licenses of "10 to 15 years" duration where such "a protocol for a device to ask for spectrum to use" may not be the obvious implementation.

Note i do not disagree that PAWS is not limited to TV bands.

Regards,
Pierre-Jean Muller
RED Technologies

Le 07/02/2013 22:48, Peter Stanforth a écrit :
Absolutely!
PAWS is a protocol for a device to ask for spectrum to use. As such the PAWS protocol must include enough information for the database to decide what answer to give.
The response must clearly define what access rights the device has been given.
No more, no less.

From: <Malyar>, John P <jmalyar@telcordia.com>
Date: Thursday, February 7, 2013 4:42 PM
To: Gmail <pierrejeanmuller@gmail.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Spectrum Sharing

I would respectfully disagree with the conclusion below. The interface between the Radio (device) and the Database is for accessing available (white space) spectrum. The policy on how to determine if the spectrum is available (or not) is separate from the Interface. If the Regulator chooses to implement a specific policy regarding sharing such as including prioritization of users, limiting the number of concurrent users or allowing unlicensed access of a band it is internal to the database implementation for that location/Regulator. IMHO the value of the interface is to provide an abstraction for devices worldwide regarding the potential numerous regulatory policies.

 

My understanding since the beginning was we were not limiting the scope to TVWS; hence the title PAWS and not PATVWS.

 

Regards,

 

John Malyar    

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gmail
Sent: Thursday, February 07, 2013 4:14 PM
To: paws@ietf.org
Subject: Re: [paws] Spectrum Sharing

 

Hi Brian, Hassnaa,

Despite having some characteristics in common, LSA and WS are, to me, different animals and i doubt there is enough synergy between WS & LSA to fall naturally into the scope of PAWS:  "Sharing under the LSA is binary by nature, with spectrum being used by either the incumbent(s) or the LSA licensee(s). I believe PAWS framework (i.e. direct link between a DB and a master device) is tightly coupled with the unlicensed nature of WS concept where LSA is about "exclusive spectrum rights of use where and when the spectrum is not used by the incumbent(s)".

Regards,
Pierre-Jean Muller
RED Technologies 

Le 07/02/2013 19:35, Rosen, Brian a écrit :

Our goal in the IETF is to be as widely applicable as we can within our charter, balanced against getting something done sooner rather than later. 

 

That's probably not as helpful as you would like.

 

I think LSA is in scope = we're definitely not limited to TV bands, and we're not limited to unlicensed spectrum.

 

brian

 

From: Hassnaa Moustafa <hassnaamoustafa@gmail.com>
Date: Thursday, February 7, 2013 1:32 PM
To: "paws@ietf.org" <paws@ietf.org>
Subject: [paws] Spectrum Sharing

 

Hi Brian, Gabor and all,

 

I read the last use-cases draft (draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt) and the recent version of the protocol draft, and I notice that the use-cases focus on White Spaces utilization.

I have a couple of questions:

- Does the WS database aims to consider the TVWS only or any other frequencies (WiFi, cellular, ... for instance)?

- In the charter of the WG, the scope is on WS utilization, would the PAWS protocol under progress be applicable to (LSA: Licensed Share Access) also or would be limited to the WS?

 

Thanks in advance.

 

Regards,

Hasnaa

 




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

 



--------------060200000605000701090001-- From pecclesi@cisco.com Fri Feb 8 19:30: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 3150D21F8C2A for ; Fri, 8 Feb 2013 19:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WmI9yjpx3W5 for ; Fri, 8 Feb 2013 19:30:08 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1DE21F8C0B for ; Fri, 8 Feb 2013 19:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6864; q=dns/txt; s=iport; t=1360380608; x=1361590208; h=from:to:cc:subject:date:message-id:mime-version; bh=LMuUC4AsEeNxNkN1JCdFgdK/2YmuS22s6+dan5KbV4Q=; b=P6IZn2wmvgzrOarlcgtTQt35ZET+agilDYtc9n70xvbyJ6AUbq7MbTVv nEmuQ0SqAaY4P5XSsguvCUKa6n7U4svnj0gpCPGUcmC374ZizMjeqZGo7 VqG4BmVEKT6BPsBG6XFukTCZQ8Q4mm+Bn+enCbEAhY2tCcwUrbeeEj6or o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALrBFVGtJV2Z/2dsb2JhbABCA4JJumqDZRZzgiEBBC1MEgEqViYBBA4NiAm/CY0lgQmCTWEDpneDAIIk X-IronPort-AV: E=Sophos;i="4.84,632,1355097600"; d="scan'208,217";a="175182166" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 09 Feb 2013 03:30:07 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r193U7cL023045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Feb 2013 03:30:07 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.58]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 21:30:07 -0600 From: "Peter Ecclesine (pecclesi)" To: "paws@ietf.org" Thread-Topic: Comments on IETF PAWS usecases Thread-Index: Ac4Gdb/5zIswmWAGQOeMXWlpFIY3HQ== Date: Sat, 9 Feb 2013 03:30:06 +0000 Message-ID: <0793F4AC2152E24E804A32C4867A50DA22C8E42D@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.124.113] Content-Type: multipart/alternative; boundary="_000_0793F4AC2152E24E804A32C4867A50DA22C8E42Dxmbalnx06ciscoc_" MIME-Version: 1.0 Cc: "Dorothy Stanley \(DStanley@arubanetworks.com\)" Subject: [paws] Comments on IETF PAWS usecases 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, 09 Feb 2013 03:30:09 -0000 --_000_0793F4AC2152E24E804A32C4867A50DA22C8E42Dxmbalnx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, After creating a white space network a master device may want to change = location, frequency, bandwidth or transmit power, and by regulation receive= permission from the database before transmitting with the changed informat= ion. OFCOM has approved requirements to cover the cases where WSDs request to= change their operation. 3.24 applies to changes from previously approved t= ransmissions as well. 3.24 Prior to transmission in the UHF TV band, a master WSD must request from an= approved WSDB the relevant instructions and parameters outlined in 3.23 pe= rtaining to itself, and where appropriate, to its served slave WSDs. PAWS usecases requirements 1.2.1 In-Scope should add the modify operation i= tems: 6. Request operation with transmission changes from those last acknowledged= to the database in step 5. 7. Receive in response permission to operate with the modified transmission= items 8. Send an acknowledgement to the database with information containing new = operation parameters. Similarly, Use Case 4.1 should be expanded to include operation with modifi= ed operation parameters. Best Regards, petere Peter Ecclesine, Technology Analyst MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 Ph 408/527-0815, FAX 408/525-9256 "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207 --_000_0793F4AC2152E24E804A32C4867A50DA22C8E42Dxmbalnx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

   After creating a white space network a = master device may want to change location, frequency, bandwidth or transmit= power, and by regulation receive permission from the database before trans= mitting with the changed information.

 

   OFCOM has approved requirements to cove= r the cases where WSDs request to change their operation. 3.24 applies to c= hanges from previously approved transmissions as well.

3.24

Prior to transmission= in the UHF TV band, a master WSD must request from an approved WSDB the relevant instructions and par= ameters outlined in 3.23 pertaining to itself, and where appropriate, to it= s served slave WSDs.

 

PAWS usecases requirements 1.2.1 In-Scope should add= the modify operation items:

6. Request operation with transmission changes from = those last acknowledged to the database in step 5.

7. Receive in response permission to operate with th= e modified transmission items

8. Send an acknowledgement to the database with info= rmation containing new operation parameters.

 

Similarly, Use Case 4.1 should be expanded to includ= e operation with modified operation parameters.

 

Best Regards,

 

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."&nbs= p; "Without Prejudice" U.C.C. 1-207

 

 

--_000_0793F4AC2152E24E804A32C4867A50DA22C8E42Dxmbalnx06ciscoc_-- From amancuso@google.com Mon Feb 11 14:43:16 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 4E1CF21F880F for ; Mon, 11 Feb 2013 14:43:16 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-8hLu7oLbj6 for ; Mon, 11 Feb 2013 14:43:15 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E852721F87E3 for ; Mon, 11 Feb 2013 14:43:14 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so6344841lab.14 for ; Mon, 11 Feb 2013 14:43:13 -0800 (PST) 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=/4DQ0Bv+mjBYye2wBbrO/RmOvUK8GwVe0E8QX1wskS0=; b=B7bhqtdFqPpej4aAxu7YzrkpptN1WCS6mlHwG1EFawYZ2oBTw3AsPb1d+erLtYhFM4 gQPobax84vDcs+E3WClFw22PWnaTxO5MuTRWoF2XSMLQd1lKL4zN06zBByx2DnuqNPGS mmlfeRM4S+T5V85tuTETNJO9HVWiJcwyefcm38obMocG76C8ZNXw3vD8CXtxCO4V86Il Rye0Clxj4RGPg13sMzQH6fjhrKKxECY8zDACFonY+XUh53F9SIDceXedYsZcXxhe9KfM O7plnuJ12zf9m0XyVWIVoF3lTJY8we9oe6HaAW8SqGCP9Tm5c9dKONGUtXsP8lAMFwNG kc2w== 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=/4DQ0Bv+mjBYye2wBbrO/RmOvUK8GwVe0E8QX1wskS0=; b=ETTNurJE4HvanFoiTvGikMCottOyoytR6i3e6JU/dhxmJSWM6vL5F73S/kprq5sSud y7DjrRWqWhEYlbWrt48ZqCJyfJeJZKSIDIS4+Vp7gx0QYb8waRFwE5seKg7sWWYoA5vw 9WGu+kEhHgt5dRqm12IPKNAMQpkUwqrk1KW+yL6Nzj9xfvSRiL454FxHxY21NKIT+1Yi 98MJqHeFIKlfWTaMUuuNr2moGKxL93safaibTC8+uLae8Av6RpR+axrSj+KwHYrCnDXC piFLbE3qNC4mHlT4DuKbQcYHUMQbEE1AR7OAGPbGt7D44rj1z3ioDW5nDPVNPwhnDzYK p9zA== MIME-Version: 1.0 X-Received: by 10.152.114.66 with SMTP id je2mr14368966lab.40.1360622593741; Mon, 11 Feb 2013 14:43:13 -0800 (PST) Received: by 10.152.102.178 with HTTP; Mon, 11 Feb 2013 14:43:13 -0800 (PST) In-Reply-To: <0793F4AC2152E24E804A32C4867A50DA22C8E42D@xmb-aln-x06.cisco.com> References: <0793F4AC2152E24E804A32C4867A50DA22C8E42D@xmb-aln-x06.cisco.com> Date: Mon, 11 Feb 2013 14:43:13 -0800 Message-ID: From: Anthony Mancuso To: "Peter Ecclesine (pecclesi)" Content-Type: multipart/alternative; boundary=90e6ba3099265f930704d57aa2e2 X-Gm-Message-State: ALoCoQk45JlWmuf6GbcpqzjJ5ZMD8MXcPm44uO6Ua+6HiMHOQK62GAKssRO8O8OSMbR3m2dp8ssG270o0aMu59Xjcb3YPWLLv1+A3OzhT94GwkX7zBZw9Nbxz/EAqoh7rkY6JXvCxEjbdfRKxBceQDxg6NpeeIVVskzMvOdyblNSjTWtRstWKQBkZBCPodHp70aKpatl8igZ Cc: "paws@ietf.org" , "Dorothy Stanley \(DStanley@arubanetworks.com\)" Subject: Re: [paws] Comments on IETF PAWS usecases 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 Feb 2013 22:43:16 -0000 --90e6ba3099265f930704d57aa2e2 Content-Type: text/plain; charset=ISO-8859-1 Hi Peter, Your points are well taken. We want to the protocol to support all known requirements, including OFCOM. I am going over the comments and hope to have another draft posted to IETF soon, which will make it clear that the envisioned protocol discussed in the use cases document includes the ability of master devices to re-register/requery/re-acknowledge with the database. Note that we are also doing our best to be "domain-agnostic" and one of the action items in updating this doc has been to remove implications that the protocol mandates regulatory-specific requirements. Instead, we want it to SUPPORT the ability of a device to conform to all (currently known and anticipated) regulatory requirements. Perhaps a subtle difference, but one we thought important to make for clarity (and the extensibility) of the protocol. Tony On Fri, Feb 8, 2013 at 7:30 PM, Peter Ecclesine (pecclesi) < pecclesi@cisco.com> wrote: > Hi All,**** > > ** ** > > After creating a white space network a master device may want to change > location, frequency, bandwidth or transmit power, and by regulation receive > permission from the database before transmitting with the changed > information.**** > > ** ** > > OFCOM has approved requirements to cover the cases where WSDs request > to change their operation. 3.24 applies to changes from previously approved > transmissions as well.**** > > 3.24 **** > > Prior to transmission in the UHF TV band, a master WSD *must *request > from an approved WSDB the relevant instructions and parameters outlined in > 3.23 pertaining to itself, and where appropriate, to its served slave WSDs. > **** > > ** ** > > PAWS usecases requirements 1.2.1 In-Scope should add the modify operation > items:**** > > 6. Request operation with transmission changes from those last > acknowledged to the database in step 5.**** > > 7. Receive in response permission to operate with the modified > transmission items**** > > 8. Send an acknowledgement to the database with information containing new > operation parameters.**** > > ** ** > > Similarly, Use Case 4.1 should be expanded to include operation with > modified operation parameters.**** > > ** ** > > Best Regards,**** > > ** ** > > petere**** > > Peter Ecclesine, Technology Analyst**** > > MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 **** > > Ph 408/527-0815, FAX 408/525-9256**** > > "Time doesn't fool around." "Without Prejudice" U.C.C. 1-207**** > > ** ** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --90e6ba3099265f930704d57aa2e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Peter,

Your points are well taken. W= e want to the protocol to support all known requirements, including OFCOM. = I am going over the comments and hope to have another draft posted to IETF = soon, which will make it clear that the envisioned protocol discussed in th= e use cases document includes the ability of master devices to re-register/= requery/re-acknowledge with the database.=A0

Note that we are also doing our best to be "domain= -agnostic" and one of the action items in updating this doc has been t= o remove implications that the protocol mandates regulatory-specific requir= ements. Instead, we want it to SUPPORT the ability of a device to conform t= o all (currently known and anticipated) regulatory requirements. Perhaps a = subtle difference, but one we thought important to make for clarity (and th= e extensibility) of the protocol.

Tony


On Fri, Feb 8, 2013 at 7:30 PM, Peter Ecclesine (pec= clesi) <pecclesi@cisco.com> wrote:

Hi All,

=A0

=A0=A0 After creating a white space network a master= device may want to change location, frequency, bandwidth or transmit power= , and by regulation receive permission from the database before transmittin= g with the changed information.

=A0

=A0=A0 OFCOM has approved requirements to cover the = cases where WSDs request to change their operation. 3.24 applies to changes= from previously approved transmissions as well.

3.24

Prior to transmission in the UHF TV ban= d, a master WSD must request from an approved WSDB the relevant instructions and par= ameters outlined in 3.23 pertaining to itself, and where appropriate, to it= s served slave WSDs.

=A0

PAWS usecases requirements 1.2.1 In-Scope should add= the modify operation items:

6. Request operation with transmission changes from = those last acknowledged to the database in step 5.

7. Receive in response permission to operate with th= e modified transmission items

8. Send an acknowledgement to the database with info= rmation containing new operation parameters.

=A0

Similarly, Use Case 4.1 should be expanded to includ= e operation with modified operation parameters.

=A0

Best Regards,

=A0

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, = CA 95134-1706

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."= =A0 "Without Prejudice" U.C.C. 1-207

=A0

=A0


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


--90e6ba3099265f930704d57aa2e2-- From internet-drafts@ietf.org Mon Feb 11 22:17:34 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 79B6F21F8C56; Mon, 11 Feb 2013 22:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Id9G1OurgK0A; Mon, 11 Feb 2013 22:17:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F12221F89AF; Mon, 11 Feb 2013 22:17:30 -0800 (PST) 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.37 Message-ID: <20130212061730.18413.45132.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 22:17:30 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-02.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: Tue, 12 Feb 2013 06:17:35 -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 Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-02.txt Pages : 78 Date : 2013-02-11 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vchen@google.com Mon Feb 11 22:27:03 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 EA08721F8C46 for ; Mon, 11 Feb 2013 22:27:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iXnqUkJFj1P for ; Mon, 11 Feb 2013 22:27:03 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id B183A21F8BBD for ; Mon, 11 Feb 2013 22:27:02 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm14so3965750wib.4 for ; Mon, 11 Feb 2013 22:27:01 -0800 (PST) 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=8WQSU+TgYPnTVePFeUjG6TErVdI/IdXS8AxhTiOiDMU=; b=OLidq6tPtduz7eJlOXJQDEUy6rKRZ1WyLGKBYItiH5XezS/0oL3qxmv5PgA1dKill8 qKfuTNo/VdgsoWEv53a5i8pxz2nQWtfZxYwlKKrqcqCzTe20U0icUYazFAJw+KsmZBro DjmvAeQLTuMlOAnAk0gq/89D2WOKnBWA4tnF4ctBJ6UUz1J3HmdTl1zt7sJWEAP5HLrR h558tfWgBbPIBtO59kydIABy4uTXtr4/ZSlDjilJo5e/fJ4geMbkQeuqA7CDDa9se/1r EnhJx8WiM17gt9Gpq3/JoZGGZA+UyyHtvqNg+hrXZKyN67H182BoIA6tC6+uBdW1gi/I BQ7w== 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=8WQSU+TgYPnTVePFeUjG6TErVdI/IdXS8AxhTiOiDMU=; b=oLix3vcL281zFArxbOhqkSmDe0TabiD4VE257WhgeqeKBc02t1VG4mIq8aDUzvN9bQ 6JyDK/vR/GatOwkT5nIps/B62BgtXMeRApLM+JuJ5344A13iVza9DtjHBEsNlh8iRClS nxn/tIKTKHO3mYLmVQ7a+UvNPLYPVBCjvf1xMXhW58HFeDKMKR85cyYaQvTPsgxJinOH 76UV5yF6NM2fDvpt0yoZ/BkJ+pEq8rRmE15weD/II50MkSf6/63V16tF4uYVcNLPE0Sj Vzsqg2vQx44R1v3aFTa/4YUu0UTahBpuK2VsosIPGaptoBkZFEX9RkrdsZqbwEkE8rGH N13w== MIME-Version: 1.0 X-Received: by 10.180.78.66 with SMTP id z2mr820711wiw.23.1360650421750; Mon, 11 Feb 2013 22:27:01 -0800 (PST) Received: by 10.194.172.229 with HTTP; Mon, 11 Feb 2013 22:27:01 -0800 (PST) In-Reply-To: <20130212061730.18413.45132.idtracker@ietfa.amsl.com> References: <20130212061730.18413.45132.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 22:27:01 -0800 Message-ID: From: Vincent Chen To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=f46d043be0d20d4c6404d5811dad X-Gm-Message-State: ALoCoQkIS+4B6mu6ESEo6yiJPdhPUmD3GOReQ/Dfqpjy4XtCL62NAb4XcGBIC0vFMeYfAqJ9pgl5njkRSn6pzcMBXFdsUivE/d70LEoXrS2odqthZN37XDI3WUfhZKRvk1WQxZZEkR/y/m/aMqd1PlVuYjUi2SaiYVJ3jQF/L97n3jKRG6LRRqd5Crfe3P8oP+b19UUHZE44 Cc: "paws@ietf.org" , i-d-announce@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-02.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: Tue, 12 Feb 2013 06:27:04 -0000 --f46d043be0d20d4c6404d5811dad Content-Type: text/plain; charset=ISO-8859-1 All, I've uploaded a new version of the PAWS protocol draft to address Extensibility, discussed at the last F2F. Summary of changes: - Added a description of message sequences to support multiple rule sets and multiple jurisdictions Section 3.1. - Modified DeviceDescriptor (Section 5.2) to add rulesetIds parameter - Modified RulesetInfo (Section 5.6), AvailableSpectrumResponse (Section 4.4.2) to add rulesetId parameter. - Add Extensibility (Section 8) section. - Filled in IANA (Section 9) section. - Removed blank Example Messages section Please note that the initial entries in Section 9 are FCC-specific, simply because its rules have been finalized and we have a complete list of required parameters. It is not intended to restrict the protocol to FCC. Comments welcomed. Thanks. -vince On Mon, Feb 11, 2013 at 10:17 PM, wrote: > > 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 Spectrum Database > Author(s) : Vincent Chen > Subir Das > Lei Zhu > John Malyar > Peter J. McCann > Filename : draft-ietf-paws-protocol-02.txt > Pages : 78 > Date : 2013-02-11 > > Abstract: > Portions of the radio spectrum that are allocated to licensees are > available for non-interfering use. This available spectrum is called > "White Space." Allowing secondary users access to available spectrum > "unlocks" existing spectrum to maximize its utilization and to > provide opportunities for innovation, resulting in greater overall > spectrum utilization. > > One approach to manage spectrum sharing uses databases to report > spectrum availability to devices. To achieve interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a protocol, the > "Protocol to Access White Space database" (PAWS). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-paws-protocol-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --f46d043be0d20d4c6404d5811dad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

I've uploaded a new vers= ion of the PAWS protocol draft to address Extensibility, discussed at the l= ast F2F.

Summary of changes:

=A0- =A0Added a description of message sequences = to support multiple rule
=A0 =A0 =A0 sets and multiple jurisdicti= ons Section 3.1.
=A0- =A0Modified DeviceDescriptor (Section 5.2) = to add rulesetIds
=A0 =A0 =A0 parameter
=A0- =A0Modified RulesetInfo (Section = 5.6), AvailableSpectrumResponse
=A0 =A0 =A0 (Section 4.4.2) to ad= d rulesetId parameter.
=A0- =A0Add Extensibility (Section 8) sect= ion.
=A0- =A0Filled in IANA (Section 9) section.
=A0- =A0Removed blank Example Messages section

Please note that the initial entries in Section 9 are FCC-specific,= simply because its rules have been finalized and we have a complete list o= f required parameters. It is not intended to restrict the protocol to FCC.<= /div>

Comments welcomed. Thanks.
=
-vince

On Mon, Feb 11, 2013 at 10:17 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Protocol to Access WS database Working = Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Protocol to Access Spectrum Dat= abase
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Vincent Chen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subir Das
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Lei Zhu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 John Malyar
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Peter J. McCann
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-paws-protocol-02.txt =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 78
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-11

Abstract:
=A0 =A0Portions of the radio spectrum that are allocated to licensees are =A0 =A0available for non-interfering use. =A0This available spectrum is cal= led
=A0 =A0"White Space." =A0Allowing secondary users access to avail= able spectrum
=A0 =A0"unlocks" existing spectrum to maximize its utilization an= d to
=A0 =A0provide opportunities for innovation, resulting in greater overall =A0 =A0spectrum utilization.

=A0 =A0One approach to manage spectrum sharing uses databases to report
=A0 =A0spectrum availability to devices. =A0To achieve interoperability amo= ng
=A0 =A0multiple devices and databases, a standardized protocol must be
=A0 =A0defined and implemented. =A0This document defines such a protocol, t= he
=A0 =A0"Protocol to Access White Space database" (PAWS).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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



--
-vince
--f46d043be0d20d4c6404d5811dad-- From chris.lowe@neul.com Tue Feb 12 09:09:40 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 1455B21F8FA5 for ; Tue, 12 Feb 2013 09:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+p3D8J5j4tg for ; Tue, 12 Feb 2013 09:09:38 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id AB47F21F8FAB for ; Tue, 12 Feb 2013 09:09:37 -0800 (PST) Received: from [85.158.137.35:31703] by server-5.bemta-3.messagelabs.com id 0B/9B-04457-B477A115; Tue, 12 Feb 2013 17:09:31 +0000 X-Env-Sender: chris.lowe@neul.com X-Msg-Ref: server-2.tower-134.messagelabs.com!1360688971!27594866!2 X-Originating-IP: [217.28.130.38] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14262 invoked from network); 12 Feb 2013 17:09:31 -0000 Received: from hostedexchange.hostedservice.com (HELO outlook.hostedservice2.net) (217.28.130.38) by server-2.tower-134.messagelabs.com with RC4-SHA encrypted SMTP; 12 Feb 2013 17:09:31 -0000 Received: from THHS2E12BE2X.hostedservice2.net ([fe80:0000:0000:0000:0484:626c:219.105.88.41]) by thhs2e12ht03.hostedservice2.net ([192.168.16.113]) with mapi; Tue, 12 Feb 2013 17:09:31 +0000 From: Chris Lowe To: "paws@ietf.org" Date: Tue, 12 Feb 2013 17:09:30 +0000 Thread-Topic: Clock drift problem against SpectrumSchedule start times Thread-Index: Ac4JQmJWygZzdcByTRucwG0CUyDwMw== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_D7A1DE1B041174488434A9F2697685800434F5CD2CTHHS2E12BE2Xh_" MIME-Version: 1.0 Subject: [paws] Clock drift problem against SpectrumSchedule start times 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 Feb 2013 17:09:40 -0000 --_000_D7A1DE1B041174488434A9F2697685800434F5CD2CTHHS2E12BE2Xh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have recently come across a problem with a similar system to PAWS, where= a small amount of clock drift between the WSD and the WSDB affects the val= idity of channel allocations. In some cases the problem causes the WSDBs t= o be repeatedly queried. WSDBs might return allocations which have a start time set to the WSDB's cu= rrent time, i.e. starting immediately. Start times on allocations are a go= od thing, since a device can receive a frequency plan for the a significant= duration without hitting the servers. But if the device's internal clock is running behind the WSDB's clock, ther= e is a potential problem: the WSDB is likely to serve up allocations which,= from the device's point of view, are in the future. If the discrepancy is= small, then the device might sensibly remain silent until its clock has ca= ught up with the SpectrumSchedule's start time. Or more pathologically, the= device might query the WSDB repeatedly in the hope of a better allocation,= each time receiving allocations that seem to always be in the future. We = have seen this phenomenon in the wild. A possible solution to this problem would be to somehow indicate that the a= llocation is for 'now'. This could be handled with a 'Generated' timestamp on the AVAIL_SPECTRUM_RE= SP. In this way, the device can deduce that the WSDB's clock disagrees wit= h the its own clock, and can see that a SpectrumSchedule is valid with imme= diate effect. The device could use the clock discrepancy as a trigger to a= djust its internal clock, perhaps using NTP. Another possible change: any SpectrumSchedules that start with immediate ef= fect should be reported as "valid immediately" by a new flag in the EventT= ime structure. Would it make sense to alter the PAWS spec in light of this problem? Cheers, Chris Lowe. -- Chris Lowe Neul Ltd. Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, Cambridge, C= B4 0EY, UK http://www.neul.com Tel: 01223 437022 --_000_D7A1DE1B041174488434A9F2697685800434F5CD2CTHHS2E12BE2Xh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have recently= come across a problem with a similar system to PAWS, where a small amount = of clock drift between the WSD and the WSDB affects the validity of channel= allocations.  In some cases the problem causes the WSDBs to be repeat= edly queried. 

 

WSDBs might return allocations which have a start ti= me set to the WSDB’s current time, i.e. starting immediately.  S= tart times on allocations are a good thing, since a device can receive a fr= equency plan for the a significant duration without hitting the servers.&nb= sp;

 

But if the device’s internal clock is running behind the WSDB&= #8217;s clock, there is a potential problem: the WSDB is likely to serve up= allocations which, from the device’s point of view, are in the futur= e.  If the discrepancy is small, then the device might sensibly remain= silent until its clock has caught up with the SpectrumSchedule’s sta= rt time. Or more pathologically, the device might query the WSDB repeatedly= in the hope of a better allocation, each time receiving allocations that s= eem to always be in the future.  We have seen this phenomenon in the w= ild.

 

A possible solution to this problem would be to somehow indicate tha= t the allocation is for ‘now’. 

 

This could be handled w= ith a ‘Generated’ timestamp on the AVAIL_SPECTRUM_RESP.  I= n this way, the device can deduce that the WSDB’s clock disagrees wit= h the its own clock, and can see that a SpectrumSchedule is valid with imme= diate effect.  The device could use the clock discrepancy as a trigger= to adjust its internal clock, perhaps using NTP. 

 

Another possible= change: any SpectrumSchedules that start with immediate effect should be r= eported as “valid immediately” by a new flag in the  Event= Time structure.

 

Would it make sense to alter the PAWS spec in light of th= is problem?

 

Cheers,

 <= /p>

Chris Lowe.

 

-- <= o:p>

= Chris Lowe

Neul Ltd.         &= nbsp;           &nbs= p;        

Suite 42 Innovation Cen= tre, Unit 23 Science Park, Milton Road, Cambridge, CB4 0EY, UK

http://www.neul.com

Tel: 01223 437022<= /span>

 

= --_000_D7A1DE1B041174488434A9F2697685800434F5CD2CTHHS2E12BE2Xh_-- From vchen@google.com Tue Feb 12 09:24:42 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 3FE2021F8F6C for ; Tue, 12 Feb 2013 09:24:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqZDcq2snG1m for ; Tue, 12 Feb 2013 09:24:41 -0800 (PST) Received: from mail-we0-x235.google.com (we-in-x0235.1e100.net [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AAC3721F8E09 for ; Tue, 12 Feb 2013 09:24:40 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t44so267992wey.40 for ; Tue, 12 Feb 2013 09:24:39 -0800 (PST) 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=AnWH4HqqTh/lw031UrPAgyF/L0qqSGbST2UKNE9HCpU=; b=bOoSbmGVTzKK4ycbbiEGPtAmjDdtvOq4OCUM82P3jEpWfHld6okau1t79W4H9JzlQ2 XU6cp1r9Rf6+3tNYsQy3nYW4wOeS0h1BzCkofwMdvbaWhtXM2DpeBi1JAXHjMVZNTcit eELI8bVdslHWjJVzf2lsNAq7F3Fc/o7OyBECqM6ToUEj/bkMzJjJpCuZTUNoJqogkwgf NP6igY4nzheJfwM2TUS6lFobwtD5RGk2tpJtfzemQGzQbCKuno3gPw3dDsHD36syQfAJ UUIEfyC5jZX/ipkTzkn+5yOz5FADvEQ7gVbW2XPVcJK1qWmoc0u8yCqm+ul2cse5Tsen H9VA== 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=AnWH4HqqTh/lw031UrPAgyF/L0qqSGbST2UKNE9HCpU=; b=h82cJalt1UkobJCf0BpRPgzKMlyFKAnJnBQ99x2xoC2FH7hkysmkChTykRw6A7TxP+ JFovh7QvrZeZKR5/BmkRHN0gUnGjnjACWF7drNpzgug5+iOeG3j+yTxtexs6IlXhYOEq YbJ+0IRyNz8s1ZQ/QUK5vtyfjcLFjS82s+5a0gWvAQDqniRgJOcR+bk3xWBHog5gcb5q BfMJOGGlkIieC/2jNGI3aKdyYxpM1Th0rwMeb5TED08PPxHyNjGNcHG8SB/Ynw69xIhx fq479gtG+erI1fzVszTur46JHQOlU1XbAIdIT/WnGMP8G8l4QYwdJpCnXlpiRTU4zwbe hKmg== MIME-Version: 1.0 X-Received: by 10.180.104.10 with SMTP id ga10mr4832714wib.23.1360689879561; Tue, 12 Feb 2013 09:24:39 -0800 (PST) Received: by 10.194.172.229 with HTTP; Tue, 12 Feb 2013 09:24:39 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 09:24:39 -0800 Message-ID: From: Vincent Chen To: Chris Lowe Content-Type: multipart/alternative; boundary=f46d04374a09ebb69d04d58a4cb9 X-Gm-Message-State: ALoCoQmuZtZgFhXdSZIVr0OPnB9wpldPoFQ15xkvbIR2O9Tgwq78gZKC3FXizps2UB2km3hjhSyQUd1ePyH9VdzrHSBeERkbG6viIQT9Hr4BbSdRQk/IY0+ir/oQi1SajW+0JehoQ4ACJQN3snGR6uGHh0L4Mgg3UucgdDOzieyksJ64oK3hkM5pV9TsXRnWUXiDiWHjfOLr Cc: "paws@ietf.org" Subject: Re: [paws] Clock drift problem against SpectrumSchedule start times 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 Feb 2013 17:24:42 -0000 --f46d04374a09ebb69d04d58a4cb9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Chris, Good suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) and AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that is the "Generated time". Looks like I forgot to add them to the data models in Section 4. The intent of this field is, indeed, for the device to determine any clock skew. I will add the field to the next draft. -vince On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe wrote: > We have recently come across a problem with a similar system to PAWS, > where a small amount of clock drift between the WSD and the WSDB affects > the validity of channel allocations. In some cases the problem causes th= e > WSDBs to be repeatedly queried. **** > > ** ** > > WSDBs might return allocations which have a start time set to the WSDB=92= s > current time, i.e. starting immediately. Start times on allocations are = a > good thing, since a device can receive a frequency plan for the a > significant duration without hitting the servers. **** > > ** ** > > But if the device=92s internal clock is running behind the WSDB=92s clock= , > there is a potential problem: the WSDB is likely to serve up allocations > which, from the device=92s point of view, are in the future. If the > discrepancy is small, then the device might sensibly remain silent until > its clock has caught up with the SpectrumSchedule=92s start time. Or more > pathologically, the device might query the WSDB repeatedly in the hope of= a > better allocation, each time receiving allocations that seem to always be > in the future. We have seen this phenomenon in the wild.**** > > ** ** > > A possible solution to this problem would be to somehow indicate that the > allocation is for =91now=92. **** > > ** ** > > This could be handled with a =91Generated=92 timestamp on the > AVAIL_SPECTRUM_RESP. In this way, the device can deduce that the WSDB=92= s > clock disagrees with the its own clock, and can see that a SpectrumSchedu= le > is valid with immediate effect. The device could use the clock discrepan= cy > as a trigger to adjust its internal clock, perhaps using NTP. **** > > ** ** > > Another possible change: any SpectrumSchedules that start with immediate > effect should be reported as =93valid immediately=94 by a new flag in the > EventTime structure.**** > > ** ** > > Would it make sense to alter the PAWS spec in light of this problem?**** > > ** ** > > Cheers,**** > > ** ** > > Chris Lowe.**** > > ** ** > > -- **** > > Chris Lowe**** > > Neul Ltd. **** > > Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, Cambridge, > CB4 0EY, UK**** > > http://www.neul.com **** > > Tel: 01223 437022**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --f46d04374a09ebb69d04d58a4cb9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Chris,

Good suggestion. In the JS= ON encoding of AVAIL_SPECTRUM_RESP (6.4.2) and AVAIL_SPECTRUM_BATCH_RESP (6= .5.2), there is a "timestamp" field that is the "Generated t= ime".

Looks like I forgot to add them to the data= models in Section 4.

The intent of th= is field is, indeed, for the device to determine any clock skew.

I will add the field to the next draft.

-vince

On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe <chris.lowe@neul.com> wrote:

We have recently come across a problem w= ith a similar system to PAWS, where a small amount of clock drift between t= he WSD and the WSDB affects the validity of channel allocations.=A0 In some= cases the problem causes the WSDBs to be repeatedly queried.=A0 =

=A0

WSDBs mi= ght return allocations which have a start time set to the WSDB=92s current = time, i.e. starting immediately.=A0 Start times on allocations are a good t= hing, since a device can receive a frequency plan for the a significant dur= ation without hitting the servers.=A0

=A0

But if t= he device=92s internal clock is running behind the WSDB=92s clock, there is= a potential problem: the WSDB is likely to serve up allocations which, fro= m the device=92s point of view, are in the future.=A0 If the discrepancy is= small, then the device might sensibly remain silent until its clock has ca= ught up with the SpectrumSchedule=92s start time. Or more pathologically, t= he device might query the WSDB repeatedly in the hope of a better allocatio= n, each time receiving allocations that seem to always be in the future.=A0= We have seen this phenomenon in the wild.

=A0

A possib= le solution to this problem would be to somehow indicate that the allocatio= n is for =91now=92.=A0

=A0<= u>

This could be handled with a =91Generated=92 timestamp on the AVAIL_SPECTRU= M_RESP.=A0 In this way, the device can deduce that the WSDB=92s clock disag= rees with the its own clock, and can see that a SpectrumSchedule is valid w= ith immediate effect.=A0 The device could use the clock discrepancy as a tr= igger to adjust its internal clock, perhaps using NTP.=A0

=A0

Another = possible change: any SpectrumSchedules that start with immediate effect sho= uld be reported as =93valid immediately=94 by a new flag in the =A0EventTim= e structure.

=A0

Would it= make sense to alter the PAWS spec in light of this problem?<= /p>

=A0

Cheer= s,

=A0

Chris Lo= we.

=A0

--

Chris Lowe

Neul Ltd.=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=

Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, Cambr= idge, CB4 0EY, UK

http://www.neul.com

Tel: 01223 437= 022

=A0


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




--
-vince
--f46d04374a09ebb69d04d58a4cb9-- From nbravin@earthlink.net Tue Feb 12 11:40:45 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 2EE0321F8C1A for ; Tue, 12 Feb 2013 11:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 HkwQQe1IJ44k for ; Tue, 12 Feb 2013 11:40:43 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5B821F890E for ; Tue, 12 Feb 2013 11:40:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WZEkCBN8p06mIiXbe08IYJLKDEj1KwvVVT1bGg7YPcxhdf9zKGNz4jdnfPaT/Wh4; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.8]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1U5LiM-0004jK-6y; Tue, 12 Feb 2013 14:40:26 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_21801921-D4CA-4231-8BE1-8DAB405D1E64" From: Nancy Bravin In-Reply-To: Date: Tue, 12 Feb 2013 11:40:20 -0800 Message-Id: <4CDD7A2A-8AAF-4A9A-BDAC-8B69F8E517C4@earthlink.net> References: To: Vincent Chen X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad867c6867b64e0772da8d2acebcbe2fc178350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: "paws@ietf.org" Subject: Re: [paws] Clock drift problem against SpectrumSchedule start times 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 Feb 2013 19:40:45 -0000 --Apple-Mail=_21801921-D4CA-4231-8BE1-8DAB405D1E64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Vincent, It is an important issue, and one that could cause issues at the = approval level of the draft, and for potential users should we not have something there. Is it possible to add to this revision?=20 Even a reference to JSON 6.5.2 ? Sincerely, N On Feb 12, 2013, at 9:24 AM, Vincent Chen wrote: > Chris, >=20 > Good suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) = and AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that = is the "Generated time". >=20 > Looks like I forgot to add them to the data models in Section 4. >=20 > The intent of this field is, indeed, for the device to determine any = clock skew. >=20 > I will add the field to the next draft. >=20 > -vince >=20 >=20 > On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe = wrote: > We have recently come across a problem with a similar system to PAWS, = where a small amount of clock drift between the WSD and the WSDB affects = the validity of channel allocations. In some cases the problem causes = the WSDBs to be repeatedly queried.=20 >=20 > =20 >=20 > WSDBs might return allocations which have a start time set to the = WSDB=92s current time, i.e. starting immediately. Start times on = allocations are a good thing, since a device can receive a frequency = plan for the a significant duration without hitting the servers.=20 >=20 > =20 >=20 > But if the device=92s internal clock is running behind the WSDB=92s = clock, there is a potential problem: the WSDB is likely to serve up = allocations which, from the device=92s point of view, are in the future. = If the discrepancy is small, then the device might sensibly remain = silent until its clock has caught up with the SpectrumSchedule=92s start = time. Or more pathologically, the device might query the WSDB repeatedly = in the hope of a better allocation, each time receiving allocations that = seem to always be in the future. We have seen this phenomenon in the = wild. >=20 > =20 >=20 > A possible solution to this problem would be to somehow indicate that = the allocation is for =91now=92.=20 >=20 > =20 >=20 > This could be handled with a =91Generated=92 timestamp on the = AVAIL_SPECTRUM_RESP. In this way, the device can deduce that the WSDB=92s= clock disagrees with the its own clock, and can see that a = SpectrumSchedule is valid with immediate effect. The device could use = the clock discrepancy as a trigger to adjust its internal clock, perhaps = using NTP.=20 >=20 > =20 >=20 > Another possible change: any SpectrumSchedules that start with = immediate effect should be reported as =93valid immediately=94 by a new = flag in the EventTime structure. >=20 > =20 >=20 > Would it make sense to alter the PAWS spec in light of this problem? >=20 > =20 >=20 > Cheers, >=20 > =20 >=20 > Chris Lowe. >=20 > =20 >=20 > -- >=20 > Chris Lowe >=20 > Neul Ltd. =20 >=20 > Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, = Cambridge, CB4 0EY, UK >=20 > http://www.neul.com >=20 > Tel: 01223 437022 >=20 > =20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=20 >=20 > --=20 > -vince > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_21801921-D4CA-4231-8BE1-8DAB405D1E64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Vincent,
It is an important issue, and one that could cause issues = at the approval level of the draft, and for potential users should we = not
have something there. Is it possible to add to this = revision? 
Even a reference to JSON 6.5.2 = ?
Sincerely, N

On Feb 12, 2013, at = 9:24 AM, Vincent Chen wrote:

Chris,

Good suggestion. In the = JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) and = AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that is = the "Generated time".

Looks like I forgot to add = them to the data models in Section 4.

The intent of this field is, indeed, for the device to = determine any clock skew.

I will add the field to the next = draft.

-vince


On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe <chris.lowe@neul.com> wrote:

We have = recently come across a problem with a similar system to PAWS, where a = small amount of clock drift between the WSD and the WSDB affects the = validity of channel allocations.  In some cases the problem causes = the WSDBs to be repeatedly queried. 

 

WSDBs = might return allocations which have a start time set to the WSDB=92s = current time, i.e. starting immediately.  Start times on = allocations are a good thing, since a device can receive a frequency = plan for the a significant duration without hitting the servers.  =

 

But if the device=92s internal clock is running = behind the WSDB=92s clock, there is a potential problem: the WSDB is = likely to serve up allocations which, from the device=92s point of view, = are in the future.  If the discrepancy is small, then the device = might sensibly remain silent until its clock has caught up with the = SpectrumSchedule=92s start time. Or more pathologically, the device = might query the WSDB repeatedly in the hope of a better allocation, each = time receiving allocations that seem to always be in the future.  = We have seen this phenomenon in the wild.

 

A = possible solution to this problem would be to somehow indicate that the = allocation is for =91now=92. 

 

This could be handled with a =91Generated=92 timestamp on the = AVAIL_SPECTRUM_RESP.  In this way, the device can deduce that the = WSDB=92s clock disagrees with the its own clock, and can see that a = SpectrumSchedule is valid with immediate effect.  The device could = use the clock discrepancy as a trigger to adjust its internal clock, = perhaps using NTP. 

 

Another= possible change: any SpectrumSchedules that start with immediate effect = should be reported as =93valid immediately=94 by a new flag in the =  EventTime structure.

 

Would = it make sense to alter the PAWS spec in light of this = problem?

 

Cheers,

 

Chris = Lowe.

 

-- =

Chris Lowe

Neul = Ltd.           &nbs= p;            =       

Suite 42 Innovation = Centre, Unit 23 Science Park, Milton Road, Cambridge, CB4 0EY, = UK

http://www.neul.com

Tel: 01223 = 437022

 


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




-- =
-vince
_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws

= --Apple-Mail=_21801921-D4CA-4231-8BE1-8DAB405D1E64-- From vchen@google.com Tue Feb 12 14:22:36 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 4264021F8C05 for ; Tue, 12 Feb 2013 14:22:36 -0800 (PST) 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=[AWL=-0.000, 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 9D3xPDKuP+B2 for ; Tue, 12 Feb 2013 14:22:35 -0800 (PST) Received: from mail-ie0-x231.google.com (ie-in-x0231.1e100.net [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63A21F8BF2 for ; Tue, 12 Feb 2013 14:22:34 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id 16so845091iea.36 for ; Tue, 12 Feb 2013 14:22:27 -0800 (PST) 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=oz4SThN7mBwtnt7FWCArNM1JW8kdeSVha4UaxCy2BYU=; b=Wt4pljukBeuDS2PoNm6xXNRr1k86FK5nsGwa2vYT+Kc/fN/BAtW4nRdbWRs8u9/tyI jzApqVutNIqOJZeWNDvFcLSObxezE+hSQjvxpa+flOrvnLmNNZrdsZoTFzVUpACZngme 2kR6gO/BvsYaI6/DDQA0YunPXSXH8CL8vMRmr+xJJBN1J+RVrLLzzLpGSk+47Pe7BUhw QH/GfJgSqXwReE/B3E22NTRd3GF+Sebhp0pb1a3GlcWfQutNw3LZRnkQpZjgZjcylGs2 Eb3YI7wE+G+9kp5d02W85qjFAqiKTwIhk1QypjGEsV+YCbxfeibvjin0/P9KaGx5TP6Z lE/w== 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=oz4SThN7mBwtnt7FWCArNM1JW8kdeSVha4UaxCy2BYU=; b=LypoDhSe/VzbrwKrpOU0DZpUT/iCPaZiNTirL2n1Ujep1Y9bXNnFK1eV8iGA9+yd2t beASTKEoFJwFBwu2r/ohKeopQX9HSrc4y283El3wLd70w5S28Hi8/Z/QtZ4P2zQB/VTP cbQCjKQV/Md8xNKr7y1SvpwN6Icr9/eE6J/Ley/uWKPs0KcRRCTXGpAhA9jdvitK4l2F kd2HgUtcUUZB95sb/xAu1zrjfw2CL6QYBEX2v8MNLuVE/EABGoWfQnqL0AlIDsFl6W/F VSe076bcMlEZZbpaWJAw7y6nvbAyinFYKaZ1HBoeWr6DCuN4sEjE4rYDmBgss4EPb4wm EUWQ== MIME-Version: 1.0 X-Received: by 10.50.194.164 with SMTP id hx4mr6509886igc.35.1360707747399; Tue, 12 Feb 2013 14:22:27 -0800 (PST) Received: by 10.64.14.227 with HTTP; Tue, 12 Feb 2013 14:22:27 -0800 (PST) In-Reply-To: <4CDD7A2A-8AAF-4A9A-BDAC-8B69F8E517C4@earthlink.net> References: <4CDD7A2A-8AAF-4A9A-BDAC-8B69F8E517C4@earthlink.net> Date: Tue, 12 Feb 2013 14:22:27 -0800 Message-ID: From: Vincent Chen To: Nancy Bravin Content-Type: multipart/alternative; boundary=14dae9340de1ed49b004d58e75d6 X-Gm-Message-State: ALoCoQnzl7u2387GhfHewqggZkYC6Dz+pD3LCbgfWXaCDjZfwvNkIRC/C8bTH4Ve85JP1AczZi8EDj4WWGgQ3faxnqSL/ovnG8e3VpfIImSOrhjJQQ2aPYFTsSZaiYNKLYFZg7hBaczN+HX1cIR8taBOnokzsuaQ30F5XNBt/g+onuwRxpmxI+cv1C7xxR4YzoiiByXrXdS7 Cc: "paws@ietf.org" Subject: Re: [paws] Clock drift problem against SpectrumSchedule start times 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 Feb 2013 22:22:36 -0000 --14dae9340de1ed49b004d58e75d6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I can create a new draft -03. I'll try to upload that later today. On Tue, Feb 12, 2013 at 11:40 AM, Nancy Bravin wrote= : > Hi Vincent, > It is an important issue, and one that could cause issues at the approval > level of the draft, and for potential users should we not > have something there. Is it possible to add to this revision? > Even a reference to JSON 6.5.2 ? > Sincerely, N > > On Feb 12, 2013, at 9:24 AM, Vincent Chen wrote: > > Chris, > > Good suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) and > AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that is t= he > "Generated time". > > Looks like I forgot to add them to the data models in Section 4. > > The intent of this field is, indeed, for the device to determine any cloc= k > skew. > > I will add the field to the next draft. > > -vince > > > On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe wrote: > >> We have recently come across a problem with a similar system to PAWS, >> where a small amount of clock drift between the WSD and the WSDB affects >> the validity of channel allocations. In some cases the problem causes t= he >> WSDBs to be repeatedly queried. **** >> >> ** ** >> >> WSDBs might return allocations which have a start time set to the WSDB= =92s >> current time, i.e. starting immediately. Start times on allocations are= a >> good thing, since a device can receive a frequency plan for the a >> significant duration without hitting the servers. **** >> >> ** ** >> >> But if the device=92s internal clock is running behind the WSDB=92s cloc= k, >> there is a potential problem: the WSDB is likely to serve up allocations >> which, from the device=92s point of view, are in the future. If the >> discrepancy is small, then the device might sensibly remain silent until >> its clock has caught up with the SpectrumSchedule=92s start time. Or mor= e >> pathologically, the device might query the WSDB repeatedly in the hope o= f a >> better allocation, each time receiving allocations that seem to always b= e >> in the future. We have seen this phenomenon in the wild.**** >> >> ** ** >> >> A possible solution to this problem would be to somehow indicate that th= e >> allocation is for =91now=92. **** >> >> ** ** >> >> This could be handled with a =91Generated=92 timestamp on the >> AVAIL_SPECTRUM_RESP. In this way, the device can deduce that the WSDB= =92s >> clock disagrees with the its own clock, and can see that a SpectrumSched= ule >> is valid with immediate effect. The device could use the clock discrepa= ncy >> as a trigger to adjust its internal clock, perhaps using NTP. **** >> >> ** ** >> >> Another possible change: any SpectrumSchedules that start with immediate >> effect should be reported as =93valid immediately=94 by a new flag in th= e >> EventTime structure.**** >> >> ** ** >> >> Would it make sense to alter the PAWS spec in light of this problem?**** >> >> ** ** >> >> Cheers,**** >> >> ** ** >> >> Chris Lowe.**** >> >> ** ** >> >> -- **** >> >> Chris Lowe**** >> >> Neul Ltd. **** >> >> Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, Cambridge= , >> CB4 0EY, UK**** >> >> http://www.neul.com **** >> >> Tel: 01223 437022**** >> >> ** ** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > --=20 -vince --14dae9340de1ed49b004d58e75d6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I can create a new draft -03. I'll try to upload that = later today.


On Tue, Feb 12, 2013 at 11:40 AM, Nancy Bravin <<= a href=3D"mailto:nbravin@earthlink.net" target=3D"_blank">nbravin@earthlink= .net> wrote:
Hi Vince= nt,
It is an important issue, and one that could cause issues at the ap= proval level of the draft, and for potential users should we not
have something there. Is it possible to add to this revision?=A0
=
Even a reference to JSON 6.5.2 ?
Sincerely, N

On Feb 12, 2013, at 9:24 AM, Vincent Chen = wrote:

Chris,

Go= od suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) and AVAI= L_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that = is the "Generated time".

Looks like I forgot to add them to the data models in S= ection 4.

The intent of this field is, indeed, for= the device to determine any clock skew.

I will add the field to the next draft.

=
-vince


On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe <= ;chris.lowe@neul.c= om> wrote:

We have recently come across a problem w= ith a similar system to PAWS, where a small amount of clock drift between t= he WSD and the WSDB affects the validity of channel allocations.=A0 In some= cases the problem causes the WSDBs to be repeatedly queried.=A0 =

=A0

WSDBs mi= ght return allocations which have a start time set to the WSDB=92s current = time, i.e. starting immediately.=A0 Start times on allocations are a good t= hing, since a device can receive a frequency plan for the a significant dur= ation without hitting the servers.=A0

=A0

But if t= he device=92s internal clock is running behind the WSDB=92s clock, there is= a potential problem: the WSDB is likely to serve up allocations which, fro= m the device=92s point of view, are in the future.=A0 If the discrepancy is= small, then the device might sensibly remain silent until its clock has ca= ught up with the SpectrumSchedule=92s start time. Or more pathologically, t= he device might query the WSDB repeatedly in the hope of a better allocatio= n, each time receiving allocations that seem to always be in the future.=A0= We have seen this phenomenon in the wild.

=A0

A possib= le solution to this problem would be to somehow indicate that the allocatio= n is for =91now=92.=A0

=A0<= u>

This could be handled with a =91Generated=92 timestamp on the AVAIL_SPECTRU= M_RESP.=A0 In this way, the device can deduce that the WSDB=92s clock disag= rees with the its own clock, and can see that a SpectrumSchedule is valid w= ith immediate effect.=A0 The device could use the clock discrepancy as a tr= igger to adjust its internal clock, perhaps using NTP.=A0

=A0

Another = possible change: any SpectrumSchedules that start with immediate effect sho= uld be reported as =93valid immediately=94 by a new flag in the =A0EventTim= e structure.

=A0

Would it= make sense to alter the PAWS spec in light of this problem?<= /p>

=A0

Cheer= s,

=A0

Chris Lo= we.

=A0

--

Chris Lowe

Neul Ltd.=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=

Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, Cambr= idge, CB4 0EY, UK

http://www.neul.com

Tel: 01223 43= 7022

=A0


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




--
-vince
_______________________________________________
paws mailing list
paws@ietf.org
https://= www.ietf.org/mailman/listinfo/paws




--
-vince --14dae9340de1ed49b004d58e75d6-- From amancuso@google.com Tue Feb 12 17:00:15 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 E666321F89A6 for ; Tue, 12 Feb 2013 17:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.955 X-Spam-Level: X-Spam-Status: No, score=-99.955 tagged_above=-999 required=5 tests=[AWL=-1.472, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 1AuJsX5T4Qn4 for ; Tue, 12 Feb 2013 17:00:09 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id BEC8521F8945 for ; Tue, 12 Feb 2013 17:00:08 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id gg13so557393lbb.2 for ; Tue, 12 Feb 2013 17:00:07 -0800 (PST) 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=ok2wjQIYhTjAlcbaA1Dc1iWo2pDs4yACcnXXpnDqmbY=; b=iM6U9zI14hBWm2TAYNzu21DyL76d8F6zUit0dQdja2rDruvEx6TlfJwsx+Sc1+NPhE 11B48/UPZj2gMcKgTYydWBF1beEEpgD2an+roRbaGgPh7x/0dZEhKiJP9NJtm2N9j5LU D93voPDPaCfKOkbwvgl4RdgOPTQFPdTH3VtzMJ5DSB/s6LB7DPggRvqTnGWGvdVYCYkL Na3q4NuNaGiGAcDiFC/fXnraLJS49NBGUtEVoUtDoGM2M1i6pZgqCjec/+ajGt+vut5Z Mdo3ocf4y8a3G4HcVqb4SloLrssUM+aJ8Rqli3sooO29UrBhGjuWmjxpDLBlW5vOaqQW +8Wg== 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=ok2wjQIYhTjAlcbaA1Dc1iWo2pDs4yACcnXXpnDqmbY=; b=ZBWMEkgyqE6SrgP6bzDPSmtUkv1NgbMVrdsWcREopd1MNhGTMGfXKlpLy8NSptJ7gw wpjP4jeOThYHz1TjHHzDmmWMTcq51ltY3PpIPamx1O0bY+gK2XNaglBWqXJvQAP4I55i WNSuRk8uWviazGtPmbj4kBkajwBpit8SR4CWdqa92u9zkvbhqdTjli8BW3SS0XWP618L 16DoASiljUgzPeD0OoaUfy5XYNY6zuM9QcnYkj0uKM1rV8WiOT8ilkXezIu+Tmvmp/kI mRPSL8RnJYocypw3nmRd4QP5+babg8xSOA2fBQ9k4ATf+A4SgMkeendetQ5Pzb1lzhAB QzwQ== MIME-Version: 1.0 X-Received: by 10.152.122.100 with SMTP id lr4mr18440939lab.28.1360717207424; Tue, 12 Feb 2013 17:00:07 -0800 (PST) Received: by 10.152.102.178 with HTTP; Tue, 12 Feb 2013 17:00:07 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130204064015.09261fa0@resistor.net> References: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130204064015.09261fa0@resistor.net> Date: Tue, 12 Feb 2013 17:00:07 -0800 Message-ID: From: Anthony Mancuso To: SM , Pete Resnick , Gabor Bajko Content-Type: multipart/alternative; boundary=f46d042ef661c9d0a904d590a9c6 X-Gm-Message-State: ALoCoQmeodUJadlRHAFRd7wqXCv0JnBdBCpOTrmhN23cPo40n376V0y4xicU2/nSOx/cPTu21fSe/zYvTjxHh/oZHQS4kjOCtmzLSkJfSKAhl7v2hrTSEsEB6H2Ry4CSc2iN85pd10gPw6ewj8ebOQ/D/2rX4iwTaI2D09X+dkODRAwrkPquE701/wKx8s2ycXvILohpva8z Cc: "paws@ietf.org" , ietf@ietf.org Subject: Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC 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 Feb 2013 01:00:16 -0000 --f46d042ef661c9d0a904d590a9c6 Content-Type: text/plain; charset=ISO-8859-1 IESG members (and PAWS list), Below are the Last Call comments and my responses, which I am using to generate v. 13 of the PAWS Use Cases & Requirements Draft. I expect to post v. 13 soon, perhaps this Friday morning. Please follow up as soon as you can with any further comments. I list Pete Resnick's and Peter Stanforth's comments and my responses first, followed by Barry Leila's, then SM's. Note: Some sections are affected by multiple comments so you may need to read all the comments and responses to a section to understand the final effect of all comments on a section. I apologize that some of the section references may be difficult to coordinate with the last (and next) posted version of the doc since I did some reorganizing (partially in response to these comments). I did my best to show the new section numbers in my responses. Thanks for all your comments. They greatly helped in clarifying this material and tying it to an extensible protocol to access whitespace. Tony Mancuso ********************* Pete Resnick's comments: Abstract End of the first paragraph, perhaps add: "The IETF has undertaken to develop a protocol for that management database." ___ Mancuso: For purposes of the abstract, I think this IETF doc speaks to the our efforts to develop the protocol (but I added this sentence in the Intro). _____ Introduction Added reference to the PAWS protocol to 1.1. Please don't refer to the WG, either in the Abstract or in the Intro. First of all, there ought to be no references in the Abstract anyway since the Abstract is often displayed in announcements and other places without the rest of the document. But more importantly, I don't think what you put in flows very well. In the Abstract, just saying "protocol" is sufficient. In the Intro, I'd suggest simply changing the last paragraph to: This document includes the problem statement for the development of a database query protocol to access a database of whitespace information followed by use cases and requirements for that protocol associated with the use of white space spectrum by secondary users. -- Deleted reference in abstract. Changed last Intro paragraph as suggested. Also moved the problem statement section up (as described in the text, it should follow the Introduction and precede the Use Cases section. Also moved the discussions of protocol services into the problem statement (there were two db features mentioned and one (db discovery) was duplicative of an existing section in the existing Problem Statement section. _____ Stanforth: Broadcast use case is a master with no slave, at least in the context of a slave that communicates with or is controlled by a master. _____ Resnick: So are you saying we do or do not need the term "master" in these sections? _____ Mancuso: I clarified the definition of master device: "A device that queries a database, on its own behalf and/or on behalf of a slave device, to obtain available spectrum information.". I think this definition plus the definition of a slave device ("A device that queries the database through a Master Device.") makes the use of the term in this and latter sections and illustrations appropriate -- namely, a master device is one that contacts a database to obtain spectrum (for itself or other devices). Slave devices under these definitions, do not contact the db directly, omitting them from the discussion and referring in the text or illustrations solely to a master device makes sense, and is not dependent on also referencing a slave device. Another way of saying it: we use the term master only as a way of describing a device used to query the db directly for spectrum availability. Denoting a device as master does not necessarily imply the use of slaves (devices that are not used to query the db directly) in a particular use case or illustration. That's all fine, but then in the first sentence of 3.1, it says "A white space radio network is created by a master device." That's not true, or at least not necessarily true. The white space network is created by either the master or the high-power slave. What defines something as a master is not that it creates a white space radio network. A master is simply defined as that which queries the database. So I suspect the word "master" in this section is wrong and the first paragraph of 3.1 needs a bit more work to remove all reference to creation of the whitespace network. Creating the network is not part of the discovery phase at all. -- This doc as originally written had a lot of extra wording (which we have been working to prune and clarify). This section is an example of such extra wording that needs trimming. I simplified this section to limit the discussion to discovery. However, I still wonder why you say that a high-power slave can establish a white-space network since, by our definition, it can't query the database for available white space spectrum. I think perhaps you are referring to a high-power portable device acting as a master device, but I'm not sure. 3.2: Similar questions regarding regulatory domains. For example, "2. To register with the database, the master device sends the database the registration information required under regulatory rules." How does the device determine which regulatory rules it is under and therefore which information to send to the database. If the answer is, "It queries the database", then it is not the regulatory rules the device cares about; it is the information the database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol work). If the answer is, "It is pre-configured in the device", then the regulatory rules are again out of band. Either way, mention of them would be unnecessary. ___ Mancuso: Agreed. I think this was simply a matter of misphrasing. Deleted the extra language to read: "To register with the database, the master device sends registration information to the database. There are still several references in 3.2 to "regulatory domain" and "regulatory requirement" that I think are unnecessary and confusing and should be removed. -- Removed references to regulatory domain and simplified the steps to eliminate unnecessary discussion of regulatory requirements. 4.2: This scenario was confusing to me because the master seems completely unnecessary to the example. Please explain. _____ Mancuso: As noted, the master is optionally used by the slave to query the db for spectrum. And again, master only connotes the device's ability to query the db directly. OK, this section still does not make sense to me. The slave is getting whitespace in this scenario. But in the diagram, the slave doesn't have the antenna; the master does. That doesn't jibe with the rest of the example. If it's the slave that wants to move away from its metered service and use whitespace, then it should have the antenna. If the slave wants to talk to an AP that's going to use the whitespace, there should be a box for the AP in the diagram. If you want to say that the master and the AP can be one device, still show two boxes but say they can be in the same box. If the master is doing the querying and setting up the whitespace and the "slave" is doing nothing with regard to whitespace but simply using the master as an Internet gateway, then the "slave" is not a slave. -- Yes, the slave needs an antenna. I think the terms "master" and "slave" (as we define them) were muddying the illustration. I changed the illustration and text to clarify that the portable device here is using white space to offload video streaming from a metered Internet service to an unmetered AP Internet service (the portable device talks to the AP over whitespace). 5.1, item 1: Is this referring to the Internet connectivity between the WS device and the database? If so, as above, does it necessarily need to be an air interface? ___ Mancuso: This wasn't meant to imply air the exclusive interface -- Made this clearer by using "any" air interface used by devices; further limited reference to messages between devices and db as messages from master device to db (since, by definition, slave devices don't communicate directly to db). You missed one bit of what I was asking: Couldn't the interface between the database and the master be wired, not air at all? --- Rephrased to be more explicit: "Interface agnostic - An interface between a master white space device and database can be wired or unwired (e.g., a radio/air interface technology such as IEEE 802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc.) However, the messaging interface between a master white space device and the database should be agnostic to the interface used for such messaging while being cognizant of the characteristics of the interface technology and the need to include any relevant attributes in the query to the database." Requirements: _____ P.1: "The master device may validate the database against a list of approved databases maintained by a regulatory body." I don't understand that as a protocol requirement. What is being required? ___ Mancuso: (Moved info up from Operation requirements per later comment). Rephrased to clarify that the master device MUST identify a db, and MAY discover or be pre-configured with db URIs, and MAY validate db URIs against a list of approved databases maintained by a regulatory body." I don't think I explained my question well enough. So let me try it this way. Here's what you currently have: P.1 The master device MUST identify a database to which it can register, make spectrum availability requests, etc. That's not the requirement. Here you're just describing what the master is going to do. So MUST isn't needed here. "will" is probably sufficient. Next comes the requirement: The master device MAY select a database by discovery at run time or by means of a pre-programmed URI address. That's fine, but it doesn't make it clear that the discovery protocol is a requirement. Shouldn't it say, "The protocol must support the discovery of an appropriate database given a location provided by the master device. The master device may select a database..."? The master device MAY validate discovered or configured database addresses against a list of approved databases maintained by a regulatory body. Here's my original confusion. I think this would be better as, "The master device may validate discovered or configured database addresses against a list of known databases (e.g., a list of databases approved by a regulatory body)." That is, the requirement (and it's not a protocol requirement) is that the master will have the ability to (optionally) do the validation against a list. Where that list comes from, e.g., a regulatory body, is not part of the requirement. -- Made the suggested wording changes. O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required by the database"? _____ Stanforth: Acceptable Location Accuracy is defined by the regulator and applied to the calculations of the database _____ Resnick: So the database will tell the device what level of accuracy is required? _____ Mancuso: Clarified as follows: "Locations MUST be determined to the accuracy required by the applicable regulatory domain." These are operational requirements, and not part of the protocol. Accuracy is verified by certification of devices by regulators. Oh, I think that made it worse. If the regulators are determining the accuracy and certifying the devices, this is not an operational requirement; it's all going to be pre-configured. Is that what you mean? -- Restated to: "A master device MUST be able to determine its location including uncertainty and confidence level. A fixed master device MAY use a location programmed at installation or be configured to determine its location to the accuracy required by the applicable regulatory domain." These seems like a valid operational requirement for devices that use the protocol. O.4: Again, "regulatory body" seems unnecessary here. Substituting "database" seems sufficient, since you'll be getting the rule set from the database. _____ Stanforth: General observation about this and the next couple of comments. The FCC Certifies a radio and a database as a "system" OFCOMis not considering a system. Other regulators may have other thoughts. In the case of the FCC some of the function is validated/certified, what ever you want to call it for the combination not as a function of one or the other. So while it seems logical to have an implementation within a database it is not necessarily considered as such. _____ Resnick: Again, I'm not understand your reply. Can you expand on what you mean here? _____ Mancuso: The statement here is regarding the rule set, which is from the regulator, so the current phrasing seems OK. I think we are talking past each other: How does the master device determine the rule set? Is it getting it from the database? Is it pre-configured? In any event, does the master device know that the rule set came from the regulator? If not, then there's no need to mention the regulator at all. -- The best I could do here, given the range of responses a db may communicate to a device regarding a rule set (the name of the rule set, a more detailed list of all parameters in a rule set, etc.) is "The master device MUST be configured to understand the requirements of the rule set of the regulatory body that apply to its operation at its location." Note there are a significant number of device-only rule-set requirements (complexity is to be expected), so the operational requirement here is for the master to obtain "information." The current expectation is that the db may communicate the name of the applicable regulatory rule set to the device, but not the specific parameters. But the master device is only dealing with the name of the rule set. It doesn't have semantics to the master device. The master device DOES NOT CARE that the rule set came from a regulator, or the manufacturer, or from invaders from Mars. The concept of the regulator is irrelevant to the operational requirement. -- Yes, but humans (perhaps invading Martians, someday?) will read this doc --- the qualification to the rule set described here "rule set of the regulatory body" is only meant to explain what rule set we are talking about. Just mentioning "rule set" seems incomplete and ambiguous. _____ O.5 (and O.9 through O.10 and O.12 through O.14): As above, you can change "local regul8atory policy" to "the database rule set", "determined by regulator policy" can be "enumerated in the database rule set", etc. ____ Mancuso: A db can serve multiple regulatory domains, and hence, rule sets. And note that the currently applicable rule set may not come from a local regulatory domain, but be imported from a foreign regulator (e.g., Brazil decides to use FCC rules) _____ Security Considerations Section 8, generally: Same issue with "regulatory". See if there are any that are more accurately "database rules". ____ Mancuso: Again, multiple rule sets may apply for a given regulatory domain. See above. I agree with the request to pare down the references to regulatory domain. Further, a lot of the "requirements" in this section either are not requirements, strictly speaking, or restated protocol requirements. Hence, I pared down this section significantly to state as simply as possible what a device and db must minimally do to operate in white space. **************** Barry Leila's comments: Some Last Call comments, in advance of IESG Evaluation: -- General -- It's completely a non-starter that there's no email address for Anthony Mancuso; this has to be added. He won't get any of the IESG Evaluation messages this way, and the RFC Editor won't be able to contact him during the publication process. ___ Fixed this. Added email and other author (editor) information. _________ The first and third references need to be in RFC reference form, and not simply as URIs. They should look something like this: [1] V. Chen, S. Das, Z. Lei, J. Malyar, P. McCann, "Protocol to Access Spectrum Database", draft-ietf-paws-protocol-01 (work in progress), December 2012 [3] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems", NIMA TR8350.2 Third Edition Amendment 1, January 2000, For the second reference: the RFC Editor will not generally accept Wikipedia as a reference, because its contents are unstable. Perhaps you could use something like instead? ____ TODO(amancuso): I'm working on these cites. I am still figuring out how to do this in xxe. I'll return to this after I respond to all the other last call comments. ----- Just an alert: the RFC Editor will probably add hyphens when "white space" is used as an adjective, as in "white-space spectrum". This is particularly notable when you have "non-white space spectrum", which looks like space that is non-white (as opposed to "non-white-space spectrum"). You may feel free to wait for them to do that. Or you can do it. ----- added hyphens to "white-space" and "non-white-space" throughout. ----- Abstract Abstracts should not contain citations, so the "[1]" citation should be removed. But perhaps more to the point, the Abstract is too long; the first paragraph can be trimmed after the second sentence (clipping everything beginning with "An obvious requirement", which doesn't need to be in the abstract (but should be and is in the Introduction)). ----- Removed cite. Trimmed down the abstract. ____ -- Section 1.1 -- The first paragraph seems overlong, and could do with splitting. Perhaps start a new paragraph with "An obvious requirement", and then another with "Academia and industry". ----- Done. _____ -- Section 3.1 -- (old section 3 moved into new section 3 subsections) It looks like a lot of stuff in these earlier sections used to have 2119 language, and got Peted. You missed one: the "MUST" in the second sentence should be "must". --- Done. _____ -- Section 3.2 -- Does Figure 1 actually show anything useful or interesting? It says it illustrates a registration requirement, but I don't see it. ----- Agreed. Deleted figure and renumbered successive figures. ____ I'd say that "most current and up-to-date information" is redundant (this also shows up in 6.3). And anyway, step 1 isn't a step -- you don't *do* anything there. ----- N/A. Refers to deleted language. ----- -- Section 4.1 -- Figure 2 (Figure 2) depicts the general architecture such a simple master-slave network You're missing an "of". And is there a reason for "Figure 2 (Figure 2)" (and with other figures) that I don't understand? ---- fixed "of"; Deleted extra figure names throughout. ----- Bullet 3: There is no Section 4.1.1 to see. Bullet 4: It's not really optional (which implies that it's at the option of the master). It's required if the database requires it, but not all databases require it. Can you re-word? (And there is no Section 4.1.2, either.) ---- Subsection numbering was changed in last iterations of the doc. Clarification: the db doesn't require registration -- the rules set of the regulatory domain that applies to the device may. The db may notify the device of the rule set name that applies to it. To avoid listing protocol requirements here, though, I generalized the language differently, and simply said that the device "may" register. This section is not meant to define the required protocol steps, just common ones in a communication exchange between the device and the db. Bullet 5: The part beginning "Note that" is out of place here, but that's OK, because it's repeated where it belongs, in bullet 6. I suggest you just remove it from here. ---- Removed the redundant part covered in item 6 but kept the part that mentions that a item 5 (spectrum availability request) may be made by the master on behalf of a slave device. -- Section 5 (now Section 3)-- The databases may be regulatory specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be regulatory independent. Is "should be" appropriate? I should think "has to be". ----- I rephrased to clarify the point trying be made here in relation to the regulatory agnostic protocol steps: "While databases are expected to support the rule set(s) of one or more regulatory domains, and the regulations and available spectrum associated with each rule set may vary, the fundamental operation of the protocol should be regulatory independent." In Figure 11, note that there could be multiple databases serving white space devices. There is no Figure 11. You mean 7? ----- fixed figure numbering ----- The databases are locale specific since the regulations and available spectrum may vary. I think you mean "location-specific"; in the App world "locale" has a particular meaning that I don't think you mean (in other words, this is not an issue of local language). This applies to the use of "locale" elsewhere in the document as well. ---- Deleted this sentence since it was peripheral to the main point about multiple dbs. But I do agree that "locale" is an overloaded term, and "location" is more appropriate. I changed "locale" to "location" throughout. -- Section 5.1 -- Bullet 1 says "Radio/air interface agnostic", but seems to be talking about the messaging between the master and the DB, which will not necessarily be over an air interface. Please re-word this bullet, being careful to make the distinction between white-space usage (which will of course be over the air) and DB access (which could be over any network interface). ---- this language was updated in response to earlier comments, and now makes it clear that master-db connection nor constrained to air interfaces. ----- Bullet 3 confuses me. First it says that it's possible for the device to know what rules are applicable, because it knows its location. Then it says to note that even though it knows its location, it may not be able to know what rule set to use. Is that not contradictory, or am I misunderstanding? Then it gives an important requirement that's buried at the end. I suggest putting the requirement earlier, and then following it with the extended explanation of the need for it. ---- deleted extra wording that clouded the main (and general) point that the protocol must support the communication of domain-specific rule set information to devices: "To allow the global use of white space devices in different countries (whatever the regulatory domain), the protocol should support the database communicating applicable regulatory rule set information to the white space device.." -- Section 5.2 -- The device needs to determine the location of the specific database to which it can send queries in addition to registering itself for operation and using the available spectrum. I'm having a lot of trouble parsing this sentence, and I'm still not sure I understand what it means. Can you try rephrasing it? -- reworded (and renumbered) section 3.2 limits the discussion to db discovery and explains the steps that can be taken to do this. ----- -- Section 6.1 -- (new section 5) The Data Model MUST support WGS84 (see NGA: DoD World Geodetic System 1984 [3]). I think this statement makes that reference normative. ---- I think you mean the cite should be to an RFC. TODO(amancuso): Update the cite. D.3 The Data Model MUST support device description data that identifies a device (serial number, certification IDs, etc.) and describes device characteristics, such as or device class (fixed, mobile, portable, indoor, outdoor, etc.), Radio Access Technology (RAT), etc. Is the "or" in there a stray, or is there something else wrong? ----- deleted stray "or" ----- -- Section 6.2 -- P.9 The protocol MUST support an available spectrum request from the master device to the database. These parameters MAY include any of the parameters and attributes required to be supported in the Data Model Requirements. "These parameters" implies that you've mentioned parameters before, but you haven't. What parameters? (Same comment for P.10 and P.11.) ---- the parameters referred to here are those listed as required data items in the preceding data model section. I reworded to clarify, as follows: "The protocol MUST support an available spectrum request from the master device to the database, which may include one or more of the data items listed in [xref to Data Model section]." Added the same trailing clause to p. 10 & 11. ----- -- Section 6.3 -- O.5 The master device MAY register with the database according to local regulatory policy. As above: this is not a correct use of MAY, because it's not at the option of the master device. In fact, as you say later in this requirement, it MUST register when it's required to. Please re-word this. (O.6) Parameters provided to the database MAY include device location, accuracy of the location Again... are these parameters provided purely at the option of the requestor (in which case "MAY" is fine), or are they provided because they're required by the database (in which case "MAY" is not right)? O.8 According to local regulator policy, a master device MAY inform the database of the actual frequency usage O.10 According to local regulatory policy, the master device MAY query the database with parameters received from the slave device. More of the same about the "MAY". --- entire section reorganized and simplified in response t earlier comments to eliminate material duplicative of protocol requirements and to delete unnecessary references to regulatory domains. ---- -- Section 8 -- (now Section 7) It is assumed that both the master device and the white space database have NOT been compromised from a security standpoint. Threat 1: User modifies a device to masquerade as another valid certified device Here's how I read these two adjacent paragraphs: (1) It is assumed that the device is not compromised; (2) Threat 1: A user compromises the device. Am I completely misunderstanding? (I also find the explanation below that to be convoluted. Can you work on it, and try to un-convolute it?) --- I reorganized the sentences to make the basic point the attackers can eavesdrop on communication channels between master device and db. I deleted the confusing statement that seemed to claim that the network was uncompromisable. A master device MAY need to identify itself to the database and be authorized to obtain information about available spectrum. Totally wrong "MAY"; make it "might". Remember that "MAY" means that something is entirely optional. "MAY need to" is pretty much always wrong. --- Simplified the wording to make the basic point that device id information can be captured and reused by an attacker. Removed "permissive" wording. _____ Threat 4: The available spectrum information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using spectrum that is not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. That's quite a sentence. Please unravel it and re-word. ----- rephrased ----- Threat 6: Expand "MiM". --- rephrased ----- The security requirements arising from the above threats are captured in the requirements of Section 6.1 (Section 6.1). There's that duplication again: "Section 6.1 (Section 6.1)" --- fixed xref --- -- Section 9 -- This section is entirely unnecessary, and you should remove it. There's no need to repeat what you've already said. ----- Agreed. Deleted section ----- ***************** SM's comments: I read the draft. I am okay with whatever the working group decides. In Section 1.1: "Academia and Industry have studied multiple cognitive radio [2] mechanisms for use in such a scenario." The reference seemed odd. It took me some time to understand that it was put in to address a comment. However, the first (external) reference that defines that is a 404. TODO(amancuso): fix link There are two occurrences of the RFC 2119 boilerplate in the draft. ----- I think the MUST below is one of the two boilerplate words you had a comment on. Is there another? ----- In Section 3.1: (new 3.2) "Before the master device can transmit in white space spectrum, it MUST obtain the address of a trusted white space database, which it will query for available white space spectrum." Why is this a MUST? --- In response to earlier comments, this section was reworded and "MUST" changed to "must". I assume this is what you were questioning. ---- In Section 4.2: "A simplified operation scenario of offloading content, such as video stream, from the a metered Internet connection to the a WS connection consists of the following steps:" What is a metered Internet connection? ---- Usage is monitored (metered) and paid for. I rephrased to clarify: "more congested or costly Internet connection, such as a metered (fee-based-on-usage) wire, wireless, or satellite service." In Section 4.4: "To set up a replacement network, spectrum needs to be quickly cleared and reallocated to the crisis response organization." Is that what P.15 is about? BTW, O.17 uses a "should" for this. --- cleaned up protocol and operational requirements in response to earlier comments. This is a good example of a use case, but didn't fit comfortably as a P or O requirement, and was deleted from requirements sections. In Section 6.2: (Section 6 is now Section 5) "P.3 The protocol MUST provide the ability for the database to authenticate the master device." "P.5 The messages sent by the master device to the database and the messages sent by the database to the master device MUST support integrity protection." "P.6 The protocol MUST provide the capability for messages sent by the master device and database to be encrypted." This sounds like the usual IETF security stuff. ----- The protocol requirements were written to tie in with the primary PAWS messages that are needed. ----- "P.8 The protocol MUST support a registration acknowledgement indicating the success of failure of the master device registration." The "success of failure" might need fixing. --- changed to "success or failure" ---- "P.14 The protocol MUST support a validation response from the database to the master to indicate if the slave device is validated by the WSDB. The validation response MUST indicate the success or failure of the validation request." What is WSDB? --- White Space Database (used to be defined in terminology). Changed it simply to "database". In Section 6.3: (entire section simplified in response to other comments) "O.1 The database and the master device MUST be connected to the Internet." What is the Internet? ---- This is a rather large container of worms. We kicked it around for about a half-hour and concluded that since this doc is for the Internet Engineering Task Force, most readers will understand (and forgive). Nonetheless, this is a good point, so I generalized it as follows (while retaining the commonly used (and loosely-understood) term: "The database and the master device MUST be connected (e.g., through the Internet)." "O.2 A master device MUST be able to determine its location including uncertainty and confidence level." Does the working group plan to build its deliverables upon the GEOPRIV work? ---- This section only intends to state the general requirement. It is my understanding that the current draft of the protocol specification specifies JSON encoding of location parameters that is compatible with GEOPRIV. --- I found the draft easy to read. The draft goes into extraneous details in some parts. As an off-topic comment I see that the working group had the usual JSON versus XML discussion [1]. :-) I understood the concept of white spaces as discussed in the draft. If I understood correctly the usage of database is related to the data model in Section 6. On seeing Figure 7 it seemed to me that what was missing is an architecture document which provides a high-level view of how all this is supposed to work. I am not suggesting a reorganization of the draft as it may end up as too much work. The draft attempts to convince the reader about the importance of white spaces and its use cases. It's basically about database queries. ---- The use cases, the focus of this doc, attempt to show the high-level architecture and provide a description of typical (and simplified) white space master/slave networks and their relationship to the white space database. Database queries are a critical and necessary step in establishing a white space network (i.e., to obtain an available spectrum list). -------------- Regards, -sm *************************** end of Last Call comments. On Mon, Feb 4, 2013 at 9:18 AM, SM wrote: > At 05:24 01-02-2013, The IESG wrote: > >> The IESG has received a request from the Protocol to Access WS database >> WG (paws) to consider the following document: >> - 'Protocol to Access White Space (PAWS) Database: Use Cases and >> Requirements' >> as Informational >> RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-02-15. Exceptionally, comments may be >> > > I read the draft. I am okay with whatever the working group decides. > > In Section 1.1: > > "Academia and Industry have studied multiple cognitive radio [2] > mechanisms for use in such a scenario." > > The reference seemed odd. It took me some time to understand that it was > put in to address a comment. However, the first (external) reference that > defines that is a 404. > > There are two occurrences of the RFC 2119 boilerplate in the draft. > > In Section 3.1: > > "Before the master device can transmit in white space spectrum, it MUST > obtain the address of a trusted white space database, which it will > query for available white space spectrum." > > Why is this a MUST? > > In Section 4.2: > > "A simplified operation scenario of offloading content, such as video > stream, from the a metered Internet connection to the a WS connection > consists of the following steps:" > > What is a metered Internet connection? > > In Section 4.4: > > "To set up a replacement network, spectrum needs to be quickly > cleared and reallocated to the crisis response organization." > > Is that what P.15 is about? BTW, O.17 uses a "should" for this. > > In Section 6.2: > > "P.3 The protocol MUST provide the ability for the database to > authenticate the master device." > > "P.5 The messages sent by the master device to the database and the > messages sent by the database to the master device MUST support > integrity protection." > > "P.6 The protocol MUST provide the capability for messages sent by > the master device and database to be encrypted." > > This sounds like the usual IETF security stuff. > > "P.8 The protocol MUST support a registration acknowledgement > indicating the success of failure of the master device > registration." > > The "success of failure" might need fixing. > > "P.14 The protocol MUST support a validation response from the > database to the master to indicate if the slave device is > validated by the WSDB. The validation response MUST indicate the > success or failure of the validation request." > > What is WSDB? > > In Section 6.3: > > "O.1 The database and the master device MUST be connected to the > Internet." > > What is the Internet? > > "O.2 A master device MUST be able to determine its location including > uncertainty and confidence level." > > Does the working group plan to build its deliverables upon the GEOPRIV > work? > > I found the draft easy to read. The draft goes into extraneous details in > some parts. As an off-topic comment I see that the working group had the > usual JSON versus XML discussion [1]. :-) I understood the concept of > white spaces as discussed in the draft. If I understood correctly the > usage of database is related to the data model in Section 6. On seeing > Figure 7 it seemed to me that what was missing is an architecture document > which provides a high-level view of how all this is supposed to work. I am > not suggesting a reorganization of the draft as it may end up as too much > work. The draft attempts to convince the reader about the importance of > white spaces and its use cases. It's basically about database queries. > > Regards, > -sm > > 1. http://www.ietf.org/mail-**archive/web/apps-discuss/** > current/msg07261.html > > ______________________________**_________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/**listinfo/paws > --f46d042ef661c9d0a904d590a9c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
IESG members (and PAWS list),

Below are the Last Call comments and my responses, which I am using to ge= nerate v. 13 of the PAWS Use Cases & Requirements Draft. I expect to po= st v. 13 soon, perhaps this Friday morning. Please follow up as soon as you= can with any further comments.

I list Pete Resnick's and Peter Stanforth's com= ments and my responses first, followed by Barry Leila's, then SM's.= Note: Some sections are affected by multiple comments so you may need to r= ead all the comments and responses to a section to understand the final eff= ect of all comments on a section.=A0

I apologize that some of the section references may be = difficult to coordinate with the last (and next) posted version of the doc = since I did some reorganizing (partially in response to these comments). I = did my best to show the new section numbers in my responses.

Thanks for all your comments. They greatly helped in cl= arifying this material and tying it to an extensible protocol to access whi= tespace.

Tony Mancuso

*********************

Pete Resnick's comments:

A= bstract

End of the first paragraph, perhaps add: &= quot;The IETF has undertaken to develop a protocol for that management data= base."
___
Mancuso: For purposes of the abstract, I think this IETF= doc speaks to the our efforts to develop the protocol (but I added this se= ntence in the Intro).
_____

Introduction=

Added reference to the PAWS protocol to 1.1.
=
Please don't refer to the WG, either in the Abstract or = in the Intro. First of all, there ought to be no references in the Abstract= anyway since the Abstract is often displayed in announcements and other pl= aces without the rest of the document. But more importantly, I don't th= ink what you put in flows very well. In the Abstract, just saying "pro= tocol" is sufficient. In the Intro, I'd suggest simply changing th= e last paragraph to:

=A0 =A0This document includes the problem statement for= the development of a
=A0 =A0database query protocol to access a = database of whitespace
=A0 =A0information followed by use cases a= nd requirements for that protocol
=A0 =A0associated with the use of white space spectrum by secondary us= ers.

-- Deleted reference in abstract. Changed las= t Intro paragraph as suggested. Also moved the problem statement section up= (as described in the text, it should follow the Introduction and precede t= he Use Cases section. Also moved the discussions of protocol services into = the problem statement (there were two db features mentioned and one (db dis= covery) was duplicative of an existing section in the existing Problem Stat= ement section.
_____
Stanforth: Broadcast use case is a master with no slav= e, at least in the context of a slave that communicates with or is controll= ed by a master.
_____
Resnick: So are you saying we do = or do not need the term "master" in these sections?
_____
Mancuso: I clarified the definition of master device: = "A device that queries a database, on its own behalf and/or on behalf = of a slave device, to obtain available spectrum information.". I think= this definition plus the definition of a slave device ("A device that= queries the database through a Master Device.") makes the use of the = term in this and latter sections and illustrations appropriate -- namely, a= master device is one that contacts a database to obtain spectrum (for itse= lf or other devices). Slave devices under these definitions, do not contact= the db directly, omitting them from the discussion and referring in the te= xt or illustrations solely to a master device makes sense, and is not depen= dent on also referencing a slave device. Another way of saying it: we use t= he term master only as a way of describing a device used to query the db di= rectly for spectrum availability. Denoting a device as master does not nece= ssarily imply the use of slaves (devices that are not used to query the db = directly) in a particular use case or illustration.

That's all fine, but then in the first sentence of = 3.1, it says "A white space radio network is created by a master devic= e." That's not true, or at least not necessarily true. The white s= pace network is created by either the master or the high-power slave. What = defines something as a master is not that it creates a white space radio ne= twork. A master is simply defined as that which queries the database. So I = suspect the word "master" in this section is wrong and the first = paragraph of 3.1 needs a bit more work to remove all reference to creation = of the whitespace network. Creating the network is not part of the discover= y phase at all.

-- This doc as originally written had a lot of extra wo= rding (which we have been working to prune and clarify). This section is an= example of such extra wording that needs trimming. I simplified this secti= on to limit the discussion to discovery. However, I still wonder why you sa= y that a high-power slave can establish a white-space network since, by our= definition, it can't query the database for available white space spec= trum. I think perhaps you are referring to a high-power portable device act= ing as a master device, but I'm not sure.

3.2: Similar questions regarding regulatory domains. Fo= r example, "2. =A0To register with the database, the master device sen= ds the database the registration information required under regulatory rule= s." How does the device determine which regulatory rules it is under a= nd therefore which information to send to the database. If the answer is, &= quot;It queries the database", then it is not the regulatory rules the= device cares about; it is the information the database is configured to as= k for (which will presumably be in accordance to some regulations, but are = out of band of any protocol work). If the answer is, "It is pre-config= ured in the device", then the regulatory rules are again out of band. = Either way, mention of them would be unnecessary.
___
Mancuso: Agreed. I think this was simply a matter of mis= phrasing. Deleted the extra language to read: "To register with the da= tabase, the master device sends registration information to the database.

There are still several references in 3.2 to "regu= latory domain" and "regulatory requirement" that I think are= unnecessary and confusing and should be removed.

-- Removed references to regulatory domain and simplified the steps to elim= inate unnecessary discussion of regulatory requirements.


4.2: This scenario was confusing to me because the ma= ster seems completely unnecessary to the example. Please explain.
_____
Mancuso: As noted, the master is optionally used by th= e slave to query the db for spectrum. And again, master only connotes the d= evice's ability to query the db directly.

OK, this section still does not make sense to me. The slave is getting whit= espace in this scenario. But in the diagram, the slave doesn't have the= antenna; the master does. That doesn't jibe with the rest of the examp= le. If it's the slave that wants to move away from its metered service = and use whitespace, then it should have the antenna. If the slave wants to = talk to an AP that's going to use the whitespace, there should be a box= for the AP in the diagram. If you want to say that the master and the AP c= an be one device, still show two boxes but say they can be in the same box.= If the master is doing the querying and setting up the whitespace and the = "slave" is doing nothing with regard to whitespace but simply usi= ng the master as an Internet gateway, then the "slave" is not a s= lave.

-- Yes, the slave needs an antenna. I think the terms &= quot;master" and "slave" (as we define them) were muddying t= he illustration. I changed the illustration and text to clarify that the po= rtable device here is using white space to offload video streaming from a m= etered Internet service to an unmetered AP Internet service (the portable d= evice talks to the AP over whitespace).


5.1, item 1: Is this referring to the In= ternet connectivity between the WS device and the database? If so, as above= , does it necessarily need to be an air interface?
___
Mancuso: This wasn't meant to imply air the exclusive interface -- Made= this clearer by using "any" air interface used by devices; furth= er limited reference to messages between devices and db as messages from ma= ster device to db (since, by definition, slave devices don't communicat= e directly to db).

You missed one bit of what I was asking: Couldn't t= he interface between the database and the master be wired, not air at all?<= /div>

--- Rephrased to be more explicit: "Interface= agnostic - An interface between a master white space device and database c= an be wired or unwired (e.g., a radio/air interface technology such as IEEE= 802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc.) However, the= messaging interface between a master white space device and the database s= hould be agnostic to the interface used for such messaging while being cogn= izant of the characteristics of the interface technology and the need to in= clude any relevant attributes in the query to the database."


Requirements:
_____
= P.1: "The master device may validate the database against a list of ap= proved databases maintained by a regulatory body." I don't underst= and that as a protocol requirement. What is being required?
___
Mancuso: (Moved info up from Operation requirements per = later comment). Rephrased to clarify that the master device MUST identify a= db, and MAY discover or be pre-configured with db URIs, and MAY validate d= b URIs against a list of approved databases maintained by a regulatory body= ."

I don't think I explained my question well enough. = So let me try it this way. Here's what you currently have:
=A0 =A0P.1 =A0The master device MUST identify a database to wh= ich it can

=A0 =A0 =A0 register, make spectrum availability reques= ts, etc.

That's not the requirement. Here you&= #39;re just describing what the master is going to do. So MUST isn't ne= eded here. "will" is probably sufficient. Next comes the requirem= ent:

=A0 =A0 =A0 The master
=A0 =A0 =A0 device MAY= select a database by discovery at run time or by means

=A0 =A0 =A0 of a pre-programmed URI address.

That's fine, but it doesn't make it clear that the discovery proto= col is a requirement. Shouldn't it say, "The protocol must support= the discovery of an appropriate database given a location provided by the = master device. The master device may select a database..."?

=A0 =A0 =A0 The master device MAY validate
= =A0 =A0 =A0 discovered or configured database addresses against a list of

=A0 =A0 =A0 approved databases maintained by a regu= latory body.

Here's my original confusion. I think this would be= better as, "The master device may validate discovered or configured d= atabase addresses against a list of known databases (e.g., a list of databa= ses approved by a regulatory body)." That is, the requirement (and it&= #39;s not a protocol requirement) is that the master will have the ability = to (optionally) do the validation against a list. Where that list comes fro= m, e.g., a regulatory body, is not part of the requirement.

-- Made the suggested wording changes.


O.2: The "required accuracy" is ambiguous= . Do you mean, "accuracy required by the database"?
_____
Stanforth: Acceptable Location Accuracy is defined by the r= egulator and applied to the calculations of the database
_____
Resnick: So the database will tell the device what level of accurac= y is required?
_____
Mancuso: Clarified as follows: "Locations MUST be= determined to the accuracy required by the applicable regulatory domain.&q= uot; These are operational requirements, and not part of the protocol. Accu= racy is verified by certification of devices by regulators.

Oh, I think that made it worse. If the regulators are d= etermining the accuracy and certifying the devices, this is not an operatio= nal requirement; it's all going to be pre-configured. Is that what you = mean?

-- Restated to: "A master device MUST be able to d= etermine its location including uncertainty and confidence level. A fixed m= aster device MAY use a location programmed at installation or be configured= to determine its location to the accuracy required by the applicable regul= atory domain." These seems like a valid operational requirement for de= vices that use the protocol.


O.4: Again, "regulatory body" = seems unnecessary here. Substituting "database" seems sufficient,= since you'll be getting the rule set from the database.
_____
Stanforth: General observation about this and the next coup= le of comments. The FCC Certifies a radio and a database as a "system&= quot; OFCOMis not considering a system. Other regulators may have other tho= ughts. In the case of the FCC some of the function is validated/certified, = what ever you want to call it for the combination not as a function of one = or the other.
So while it seems logical to have an implementation within a database = it is not necessarily considered as such.
_____
Resnick= : Again, I'm not understand your reply. Can you expand on what you mean= here?
_____
Mancuso: The statement here is regarding the rule set,= which is from the regulator, so the current phrasing seems OK.
<= br>
I think we are talking past each other: How does the master d= evice determine the rule set? Is it getting it from the database? Is it pre= -configured? In any event, does the master device know that the rule set ca= me from the regulator? If not, then there's no need to mention the regu= lator at all.

-- The best I could do here, given the range of respons= es a db may communicate to a device regarding a rule set (the name of the r= ule set, a more detailed list of all parameters in a rule set, etc.) is &qu= ot;The master device MUST be configured to understand the requirements of t= he rule set of the regulatory body that apply to its operation at its locat= ion."


Note there are a significant number of d= evice-only rule-set requirements (complexity is to be expected), so the ope= rational requirement here is for the master to obtain "information.&qu= ot; The current expectation is that the db may communicate the name of the = applicable regulatory rule set to the device, but not the specific paramete= rs.

But the master device is only dealing with the name of = the rule set. It doesn't have semantics to the master device. The maste= r device DOES NOT CARE that the rule set came from a regulator, or the manu= facturer, or from invaders from Mars. The concept of the regulator is irrel= evant to the operational requirement.

-- Yes, but humans (perhaps invading Martians, someday?= ) will read this doc --- the qualification to the rule set described here &= quot;rule set of the regulatory body" is only meant to explain what ru= le set we are talking about. Just mentioning "rule set" seems inc= omplete and ambiguous.=A0
_____

O.5 (and O.9 through O.10 and O.12 thro= ugh O.14): As above, you can change "local regul8atory policy" to= "the database rule set", "determined by regulator policy&qu= ot; can be "enumerated in the database rule set", etc.
____
Mancuso: A db can serve multiple regulatory domains, an= d hence, rule sets. And note that the currently applicable rule set may not= come from a local regulatory domain, but be imported from a foreign regula= tor (e.g., Brazil decides to use FCC rules)
_____

Security Considerations

<= /div>
Section 8, generally: Same issue with "regulatory". See= if there are any that are more accurately "database rules".
____
Mancuso: Again, multiple rule sets may apply for a give= n regulatory domain.

See above.

I agree with the request to pare down the references to regulatory d= omain. Further, a lot of the "requirements" in this section eithe= r are not requirements, strictly speaking, or restated protocol requirement= s. Hence, I pared down this section significantly to state as simply as pos= sible what a device and db must minimally do to operate in white space.=A0<= /div>

****************

Barry Leila&#= 39;s comments:

Some Last Call comments, in advance= of IESG Evaluation:

-- General --

It's completely a non-starter that there's no email addr= ess for
Anthony Mancuso; this has to be added. =A0He won't ge= t any of the IESG
Evaluation messages this way, and the RFC Edito= r won't be able to
contact him during the publication process.

_= __
Fixed this. Added email and other author (editor) information.=
_________

The first and third reference= s need to be in RFC reference form, and
not simply as URIs. =A0They should look something like this:

[1] V. Chen, S. Das, Z. Lei, J. Malyar, P. McCann, "Pr= otocol to
Access Spectrum Database", draft-ietf-paws-protoco= l-01 (work in
progress), December 2012

[3] National Imagery= and Mapping Agency, "Department of Defense
World Geodetic S= ystem 1984, Its Definition and Relationships with
Local Geodetic = Systems", NIMA TR8350.2 Third Edition Amendment 1,
January 2000,

For the second reference: the RFC Editor will not generally accept
Wikipedia as a reference, because its contents are unstable. =A0Perhap= s
you could use something like <http://fcc.gov/oet/cognitiveradio/&g= t;
instead?
____
TODO(amancuso): I'm working on these cites. I am st= ill figuring out how to do this in xxe.=A0
I'll return to thi= s after I respond to all the other last call comments.
-----

Just an alert: the RFC Editor will probably add hyphens= when "white
space" is used as an adjective, as in &quo= t;white-space spectrum". =A0This is
particularly notable whe= n you have "non-white space spectrum", which
looks like space that is non-white (as opposed to "non-white-spac= e
spectrum"). =A0You may feel free to wait for them to do th= at. =A0Or you
can do it.
-----
added hyphens = to "white-space" and "non-white-space" throughout.
-----

Abstract

Abstr= acts should not contain citations, so the "[1]" citation should
be removed. =A0But perhaps more to the point, the Abstract is too = long;
the first paragraph can be trimmed after the second sentence (clipping=
everything beginning with "An obvious requirement", wh= ich doesn't need
to be in the abstract (but should be and is = in the Introduction)).
-----
Removed cite. Trimmed down the abstract.
___= _


-- Section 1.1 --

<= /div>
The first paragraph seems overlong, and could do with splitting.<= /div>
Perhaps start a new paragraph with "An obvious requirement",= and then
another with "Academia and industry".
-----
Done.
_____

-- Sectio= n 3.1 -- (old section 3 moved into new section 3 subsections)

It looks like a lot of stuff in these earlier sections = used to have
2119 language, and got Peted. =A0You missed one: the= "MUST" in the
second sentence should be "must&quo= t;.

---
Done.
_____

-- Section 3.2 --

Does Figure 1 actually sho= w anything useful or interesting? =A0It says
it illustrates a reg= istration requirement, but I don't see it.
-----
Agreed. Deleted figure and renumbered successive figur= es.
____

I'd say that "most cur= rent and up-to-date information" is redundant
(this also sho= ws up in 6.3). =A0And anyway, step 1 isn't a step -- you
don't *do* anything there.
-----
N/A. Refers t= o deleted language.
-----


-- Section 4.1 --

=A0 =A0Figure 2 (Figure 2) depi= cts the general architecture such a simple
=A0 =A0master-slave network

You're missin= g an "of". =A0And is there a reason for "Figure 2 (Figure
2)" (and with other figures) that I don't understand?
----
fixed "of"; Deleted extra figure names throughout.=
-----

Bullet 3: There is no Section 4.1= .1 to see.

Bullet 4: It's not really optional = (which implies that it's at the
option of the master). =A0It's required if the database requires i= t, but
not all databases require it. =A0Can you re-word? =A0(And = there is no
Section 4.1.2, either.)

----=
Subsection numbering was changed in last iterations of the doc.
<= div>
Clarification: the db doesn't require registration -= - the rules set of the regulatory domain that applies to the device may. Th= e db may notify the device of the rule set name that applies to it. To avoi= d listing protocol requirements here, though, I generalized the language di= fferently, and simply said that the device "may" register. This s= ection is not meant to define the required protocol steps, just common ones= in a communication exchange between the device and the db.=A0

Bullet 5: The part beginning "Note that" is o= ut of place here, but
that's OK, because it's repeated wh= ere it belongs, in bullet 6. =A0I
suggest you just remove it from= here.
----
Removed the redundant part covered in item 6 but kept t= he part that mentions that a item 5 (spectrum availability request) may be = made by the master on behalf of a slave device.

-- Section 5 (now Section 3)--

=A0 =A0The database= s may be regulatory specific
=A0 =A0since the available spectrum = and regulations may vary, but the
=A0 =A0fundamental operation of= the protocol should be regulatory
=A0 =A0independent.

Is "should be" = appropriate? =A0I should think "has to be".
-----
=
I rephrased to clarify the point trying be made here in relation to th= e regulatory agnostic protocol steps: "While databases are expected to= support the rule set(s) of one or more regulatory domains, and the regulat= ions and available spectrum associated with each rule set may vary, the fun= damental operation of the protocol should be regulatory independent."<= /div>

=A0 =A0In Figure 11, note that there could be multiple = databases serving
=A0 =A0white space devices.

There is no Figure 11. =A0You mean 7?
-----
fixed= figure numbering
-----

=A0 =A0The databases are locale specifi= c since the
=A0 =A0regulations and available spectrum may vary.

I think you mean "location-specific"; in = the App world "locale" has a
particular meaning that I don't think you mean (in other words, th= is
is not an issue of local language). =A0This applies to the use= of
"locale" elsewhere in the document as well.
----
Deleted this sentence since it was peripheral to the ma= in point about multiple dbs. But I do agree that "locale" is an o= verloaded term, and "location" is more appropriate. I changed &qu= ot;locale" to "location" throughout.

-- Section 5.1 --

Bullet 1 say= s "Radio/air interface agnostic", but seems to be talking
about the messaging between the master and the DB, which will not
necessarily be over an air interface. =A0Please re-word this bullet,
being careful to make the distinction between white-space usage (w= hich
will of course be over the air) and DB access (which could b= e over any
network interface).
----
this language was updated= in response to earlier comments, and now makes it clear that master-db con= nection nor constrained to air interfaces.
-----

Bullet 3 confuses me. =A0First it says that it's possible fo= r the device
to know what rules are applicable, because it knows = its location.
Then it says to note that even though it knows its = location, it may
not be able to know what rule set to use. =A0Is that not contradictory= ,
or am I misunderstanding? =A0Then it gives an important require= ment
that's buried at the end.

I sug= gest putting the requirement earlier, and then following it with
the extended explanation of the need for it.
----
= deleted extra wording that clouded the main (and general) point that the pr= otocol must support the communication of domain-specific rule set informati= on to devices: "To allow the global use of white space devices in diff= erent countries (whatever the regulatory domain), the protocol should suppo= rt the database communicating applicable regulatory rule set information to= the white space device.."

-- Section 5.2 --

=A0 =A0The d= evice needs to
=A0 =A0determine the location of the specific data= base to which it can send
=A0 =A0queries in addition to registeri= ng itself for operation and using the
=A0 =A0available spectrum.

I'm having a l= ot of trouble parsing this sentence, and I'm still not
sure I= understand what it means. =A0Can you try rephrasing it?
--
=
reworded (and renumbered) section 3.2 limits the discussion to db discovery= and explains the steps that can be taken to do this.
-----
=

-- Section 6.1 -- (new section 5)

=A0 =A0 =A0 =A0 =A0The Data Model MUST support WGS84 (see NGA: DoD Wor= ld Geodetic
=A0 =A0 =A0 =A0 =A0System 1984 [3]).

I think this statement makes that reference normative.
-= ---
I think you mean the cite should be to an RFC.
TODO(amancuso): Update the cite.

=A0 =A0 =A0 = D.3 =A0The Data Model MUST support device description data that
= =A0 =A0 =A0 =A0 =A0identifies a device (serial number, certification IDs, e= tc.)
=A0 =A0 =A0 =A0 =A0and describes device characteristics, such as or device = class
=A0 =A0 =A0 =A0 =A0(fixed, mobile, portable, indoor, outdoo= r, etc.), Radio Access
=A0 =A0 =A0 =A0 =A0Technology (RAT), etc.<= /div>

Is the "or" in there a stray, or is there something else wrong?
-----
deleted stray "or"
-----

-- Section 6.2 --

=A0 =A0P.9 =A0Th= e protocol MUST support an available spectrum request from the
= =A0 =A0 =A0 master device to the database. =A0These parameters MAY include = any
=A0 =A0 =A0 of the parameters and attributes required to be supported = in the
=A0 =A0 =A0 Data Model Requirements.

<= div>"These parameters" implies that you've mentioned paramete= rs before,
but you haven't. =A0What parameters? =A0(Same comment for P.10 and= P.11.)
----
the parameters referred to here are those = listed as required data items in the preceding data model section. I reword= ed to clarify, as follows: "The protocol MUST support an available spe= ctrum request from the =A0master device to the database, which may include = one or more of the data items listed in [xref to Data Model section]."=

Added the same trailing clause to p. 10 & 11.
=
-----

-- Section 6.3 --

<= div>=A0 =A0O.5 =A0The master device MAY register with the database accordin= g to
=A0 =A0 =A0 local regulatory policy.

As above= : this is not a correct use of MAY, because it's not at the
o= ption of the master device. =A0In fact, as you say later in this
= requirement, it MUST register when it's required to. =A0Please re-word<= /div>
this.

=A0 (O.6)
=A0 =A0 =A0 Paramet= ers provided to the database
=A0 =A0 =A0 MAY include device locat= ion, accuracy of the location

Again... are these p= arameters provided purely at the option of the
requestor (in which case "MAY" is fine), or are they provide= d because
they're required by the database (in which case &qu= ot;MAY" is not right)?

=A0 =A0O.8 =A0Accordin= g to local regulator policy, a master device MAY inform
=A0 =A0 =A0 the database of the actual frequency usage

<= /div>
=A0 =A0O.10 =A0According to local regulatory policy, the master d= evice MAY
=A0 =A0 =A0 query the database with parameters received= from the slave device.

More of the same about the "MAY".
<= br>
---
entire section reorganized and simplified in re= sponse t earlier comments to eliminate material duplicative of protocol req= uirements and to delete unnecessary references to regulatory domains.
----

-- Section 8 -- (now Section 7)

=A0 =A0 =A0 =A0 =A0It is assumed that both the master devi= ce and the white space
=A0 =A0 =A0 =A0 =A0database have NOT been = compromised from a security standpoint.

=A0 =A0 =A0 Threat 1: User modifies a device to masquer= ade as another valid
=A0 =A0 =A0 certified device

<= /div>
Here's how I read these two adjacent paragraphs: (1) It is as= sumed
that the device is not compromised; (2) Threat 1: A user compromises
the device.

Am I completely misunderstand= ing? =A0(I also find the explanation below
that to be convoluted.= =A0Can you work on it, and try to un-convolute
it?)
---
I reorganized the sentences to make the b= asic point the attackers can eavesdrop on communication channels between ma= ster device and db. I deleted the confusing statement that seemed to claim = that the network was uncompromisable.

=A0 =A0 =A0 =A0 =A0A master device MAY
=A0 = =A0 =A0 =A0 =A0need to identify itself to the database and be authorized to=
=A0 =A0 =A0 =A0 =A0obtain information about available spectrum.<= /div>

Totally wrong "MAY"; make it "might= ". =A0Remember that "MAY" means that
something is entirely optional. =A0"MAY need to" is pretty m= uch always
wrong.
---
Simplified the wording = to make the basic point that device id information can be captured and reus= ed by an attacker. Removed "permissive" wording.
_____

Threat 4:
=A0 =A0 =A0 =A0 =A0= The available spectrum
=A0 =A0 =A0 =A0 =A0information or transmit= power allowed type of parameters
=A0 =A0 =A0 =A0 =A0carried in t= he response could be modified by the attacker
=A0 =A0 =A0 =A0 =A0resulting in the master device using spectrum that = is not
=A0 =A0 =A0 =A0 =A0available at a location or transmitting= at a greater power
=A0 =A0 =A0 =A0 =A0level than allowed resulti= ng in interference to the primary
=A0 =A0 =A0 =A0 =A0user of that spectrum.

Tha= t's quite a sentence. =A0Please unravel it and re-word.
-----=
rephrased
-----

Threat 6: Exp= and "MiM".
---
rephrased
-----

=A0 = =A0The security requirements arising from the above threats are captured
=A0 =A0in the requirements of Section 6.1 (Section 6.1).
=
There's that duplication again: "Section 6.1 (Section 6.1)&qu= ot;

---
fixed xref
---
-- Section 9 --

This section is entirely unnece= ssary, and you should remove it.
There's no need to repeat what you've already said.
=
-----
Agreed. Deleted section
-----

*****************

SM's co= mments:

I read the draft. =A0I am okay with whatever the workin= g group decides.

In Section 1.1:

=A0 "Academia and Industry have studied multiple cognitive rad= io [2]
=A0 =A0mechanisms for use in such a scenario."

The reference seemed odd. =A0It took me some time to understand that= it was put in to address a comment. =A0However, the first (external) refer= ence that defines that is a 404.

TODO(amancuso): fix link

There= are two occurrences of the RFC 2119 boilerplate in the draft.
-----
I think the MUST below is one of the two boile= rplate words you had a comment on. Is there another?
-----

In Section 3.1: (new 3.2)
=A0 "Before the master device can transmit in white space = spectrum, it MUST
=A0 =A0obtain the address of a trusted white sp= ace database, which it will
=A0 =A0query for available white space spectrum."

<= /div>
Why is this a MUST?
---
In response to earlie= r comments, this section was reworded and "MUST" changed to "= ;must". I assume this is what you were questioning.
----

In Section 4.2:

=A0 "A simplified operation scenario of offloading content, such as v= ideo
=A0 =A0stream, from the a metered Internet connection to the= a WS connection
=A0 =A0consists of the following steps:"

What is a metered Internet connection?
----
Usage is m= onitored (metered) and paid for. I rephrased to clarify: "more congest= ed or costly Internet connection, such as a metered (fee-based-on-usage) wi= re, wireless, or satellite service."


In Section 4.4:

=A0 "To set up a replacement network, spectrum needs to be quickly
=A0 =A0cleared and reallocated to the crisis response organization.= "

Is that what P.15 is about? =A0BTW, O.17 uses a "s= hould" for this.
---
cleaned up protocol and opera= tional requirements in response to earlier comments. This is a good example= of a use case, but didn't fit comfortably as a P or O requirement, and= was deleted from requirements sections.=A0

In Section 6.2: (Section 6 is now Section 5)
=
=A0 "P.3 =A0The protocol MUST provide the ability for t= he database to
=A0 =A0 =A0authenticate the master device."

=A0 "P.5 =A0The messages sent by the master device to t= he database and the
=A0 =A0 =A0 messages sent by the database to = the master device MUST support
=A0 =A0 =A0 integrity protection.&= quot;

=A0 "P.6 =A0The protocol MUST provide the capability fo= r messages sent by
=A0 =A0 =A0 the master device and database to = be encrypted."

This sounds like the usual IET= F security stuff.
-----
The protocol requirements were written to tie in with = the primary PAWS messages that are needed.
-----

=A0 "P.8 =A0The protocol MUST support a registration acknowle= dgement
=A0 =A0 =A0 indicating the success of failure of the master device
=A0 =A0 =A0 registration."

The "s= uccess of failure" might need fixing.
---
changed = to "success or failure"
----

=A0 "P.14 =A0The protocol MUST supp= ort a validation response from the
=A0 =A0 =A0 database to the ma= ster to indicate if the slave device is
=A0 =A0 =A0 validated by = the WSDB. =A0The validation response MUST indicate the
=A0 =A0 =A0 success or failure of the validation request."
<= div>
What is WSDB?
---
White Space Databa= se (used to be defined in terminology). Changed it simply to "database= ".

In Section 6.3: (entire section simplified in response = to other comments)

=A0 "O.1 =A0The database a= nd the master device MUST be connected to the
=A0 =A0 =A0 Interne= t."

What is the Internet?
----
This is = a rather large container of worms. We kicked it around for about a half-hou= r and concluded that since this doc is for the Internet Engineering Task Fo= rce, most readers will understand (and forgive). Nonetheless, this is a goo= d point, so I generalized it as follows (while retaining the commonly used = (and loosely-understood) term: "The database and the master device MUS= T be connected (e.g., through the Internet)."

=A0 "O.2 =A0A master device MUST be able to determ= ine its location including
=A0 =A0 =A0 uncertainty and confidence= level."

Does the working group plan to build= its deliverables upon the GEOPRIV work?=A0
----
This section only intends to state the general requirem= ent. It is my understanding that the current draft of the protocol specific= ation specifies JSON encoding of location parameters that is compatible wit= h GEOPRIV.
---

I found the draft easy to read. =A0The dr= aft goes into extraneous details in some parts. =A0As an off-topic comment = I see that the working group had the usual JSON versus XML discussion [1]. = :-) =A0I understood the concept of white spaces as discussed in the draft. = =A0If I understood correctly the usage of database is related to the data m= odel in Section 6. =A0On seeing Figure 7 it seemed to me that what was miss= ing is an architecture document which provides a high-level view of how all= this is supposed to work. =A0I am not suggesting a reorganization of the d= raft as it may end up as too much work. =A0The draft attempts to convince t= he reader about the importance of white spaces and its use cases. =A0It'= ;s basically about database queries.

----
The use cases, the focus of this doc, at= tempt to show the high-level architecture and provide a description of typi= cal (and simplified) white space master/slave networks and their relationsh= ip to the white space database. Database queries are a critical and necessa= ry step in establishing a white space network (i.e., to obtain an available= spectrum list).
--------------

Regards,
-sm

***************************

end = of Last Call comments.




On Mon, Feb 4, 2013 at 9:18 AM, SM <sm@re= sistor.net> wrote:
At 05:24 01-02-2013, The IESG wrote:
The IESG has received a request from the Protocol to Access WS database
WG (paws) to consider the following document:
- 'Protocol to Access White Space (PAWS) Database: Use Cases and
=A0 =A0Requirements'
=A0 <draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt> as In= formational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin= g lists by 2013-02-15. Exceptionally, comments may be

I read the draft. =A0I am okay with whatever the working group decides.

In Section 1.1:

=A0 "Academia and Industry have studied multiple cognitive radio [2] =A0 =A0mechanisms for use in such a scenario."

The reference seemed odd. =A0It took me some time to understand that it was= put in to address a comment. =A0However, the first (external) reference th= at defines that is a 404.

There are two occurrences of the RFC 2119 boilerplate in the draft.

In Section 3.1:

=A0 "Before the master device can transmit in white space spectrum, it= MUST
=A0 =A0obtain the address of a trusted white space database, which it will<= br> =A0 =A0query for available white space spectrum."

Why is this a MUST?

In Section 4.2:

=A0 "A simplified operation scenario of offloading content, such as vi= deo
=A0 =A0stream, from the a metered Internet connection to the a WS connectio= n
=A0 =A0consists of the following steps:"

What is a metered Internet connection?

In Section 4.4:

=A0 "To set up a replacement network, spectrum needs to be quickly
=A0 =A0cleared and reallocated to the crisis response organization."
Is that what P.15 is about? =A0BTW, O.17 uses a "should" for this= .

In Section 6.2:

=A0 "P.3 =A0The protocol MUST provide the ability for the database to<= br> =A0 =A0 =A0authenticate the master device."

=A0 "P.5 =A0The messages sent by the master device to the database and= the
=A0 =A0 =A0 messages sent by the database to the master device MUST support=
=A0 =A0 =A0 integrity protection."

=A0 "P.6 =A0The protocol MUST provide the capability for messages sent= by
=A0 =A0 =A0 the master device and database to be encrypted."

This sounds like the usual IETF security stuff.

=A0 "P.8 =A0The protocol MUST support a registration acknowledgement =A0 =A0 =A0 indicating the success of failure of the master device
=A0 =A0 =A0 registration."

The "success of failure" might need fixing.

=A0 "P.14 =A0The protocol MUST support a validation response from the<= br> =A0 =A0 =A0 database to the master to indicate if the slave device is
=A0 =A0 =A0 validated by the WSDB. =A0The validation response MUST indicate= the
=A0 =A0 =A0 success or failure of the validation request."

What is WSDB?

In Section 6.3:

=A0 "O.1 =A0The database and the master device MUST be connected to th= e
=A0 =A0 =A0 Internet."

What is the Internet?

=A0 "O.2 =A0A master device MUST be able to determine its location inc= luding
=A0 =A0 =A0 uncertainty and confidence level."

Does the working group plan to build its deliverables upon the GEOPRIV work= ?

I found the draft easy to read. =A0The draft goes into extraneous details i= n some parts. =A0As an off-topic comment I see that the working group had t= he usual JSON versus XML discussion [1]. :-) =A0I understood the concept of= white spaces as discussed in the draft. =A0If I understood correctly the u= sage of database is related to the data model in Section 6. =A0On seeing Fi= gure 7 it seemed to me that what was missing is an architecture document wh= ich provides a high-level view of how all this is supposed to work. =A0I am= not suggesting a reorganization of the draft as it may end up as too much = work. =A0The draft attempts to convince the reader about the importance of = white spaces and its use cases. =A0It's basically about database querie= s.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/a= pps-discuss/current/msg07261.html =A0

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

--f46d042ef661c9d0a904d590a9c6-- From sm@resistor.net Wed Feb 13 04:35:50 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 BC33021F87E1; Wed, 13 Feb 2013 04:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 W8AsCbnnBEJ9; Wed, 13 Feb 2013 04:35:49 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBF721F87CE; Wed, 13 Feb 2013 04:35:48 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1DCZY7C013397; Wed, 13 Feb 2013 04:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360758942; bh=FBdWTZANlyeRY/OzfyEDpHyX8iXnUprs5jYYhlPK8m0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Kto3uXKWxqVVjmi8sjRS83BBMCgdwPbF7YhbrZ7cwKua4o8nGb9txzxLYQbgpMYsn dKnKEPTZe292xjre60KZWGDQ5l75O4b6LEUaBvNMsiU3l5UEshumt2NjP73gYQo/Ic knu2Wdxy6y9UdChB9XZ0rSHORKB9Dwmy+rdCIYYg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360758942; i=@resistor.net; bh=FBdWTZANlyeRY/OzfyEDpHyX8iXnUprs5jYYhlPK8m0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dXT2UuQZWlQHdUFam5NxGAK7huevda0S/SUodw+uYpD8NoKw1DbWWwGpIxxWi8tMC Ov/x2F4U7DRHhqRu8yY6IytXT/Y9BuGJZfRkr2kST7Eoa9QqqFRUJZOczajay9kG9R x/0ec3uLWzBLhXD5b3wvUk83bmsQy7IZP0nXTxl8= Message-Id: <6.2.5.6.2.20130213040129.09254bc0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 13 Feb 2013 04:33:39 -0800 To: Anthony Mancuso From: SM In-Reply-To: References: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130204064015.09261fa0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: paws@ietf.org, ietf@ietf.org Subject: Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC 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 Feb 2013 12:35:50 -0000 Hi Anthony, At 17:00 12-02-2013, Anthony Mancuso wrote: >In Section 1.1: > > "Academia and Industry have studied multiple cognitive radio [2] > mechanisms for use in such a scenario." > >The reference seemed odd. It took me some time to understand that >it was put in to address a comment. However, the first (external) >reference that defines that is a 404. > >TODO(amancuso): fix link Ok. >I think the MUST below is one of the two boilerplate words you had a >comment on. Is there another? See the section after the Abstract and Section 2.1. >In response to earlier comments, this section was reworded and >"MUST" changed to "must". I assume this is what you were questioning. Ok. >---- > >In Section 4.2: > > "A simplified operation scenario of offloading content, such as video > stream, from the a metered Internet connection to the a WS connection > consists of the following steps:" > >What is a metered Internet connection? >---- >Usage is monitored (metered) and paid for. I rephrased to clarify: >"more congested or costly Internet connection, such as a metered >(fee-based-on-usage) wire, wireless, or satellite service." In my opinion you don't really have to get into all that. I'll defer to the author. >cleaned up protocol and operational requirements in response to >earlier comments. This is a good example of a use case, but didn't >fit comfortably as a P or O requirement, and was deleted from >requirements sections. Ok. >White Space Database (used to be defined in terminology). Changed it >simply to "database". Ok. >This is a rather large container of worms. We kicked it around for >about a half-hour and concluded that since this doc is for the >Internet Engineering Task Force, most readers will understand (and >forgive). Nonetheless, this is a good point, so I generalized it as >follows (while retaining the commonly used (and loosely-understood) >term: "The database and the master device MUST be connected (e.g., >through the Internet)." I agree about that container. :-) The draft is trying to convince me that white space is better for the Internet connection (see my previous comment about metered). The requirements is about a protocol to Access Spectrum Database. IP connectivity is a lower-layer issue. I am ok with the above text. >This section only intends to state the general requirement. It is my >understanding that the current draft of the protocol specification >specifies JSON encoding of location parameters that is compatible with GEOPRIV. Ok. Regards, -sm From warren@kumari.net Wed Feb 13 07:15: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 9CBF721F86C5 for ; Wed, 13 Feb 2013 07:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, 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 bfaQXRG3-Kps for ; Wed, 13 Feb 2013 07:15:36 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F2221F8753 for ; Wed, 13 Feb 2013 07:15:36 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 3E5B71B403BA; Wed, 13 Feb 2013 10:15:35 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Wed, 13 Feb 2013 10:15:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vincent Chen X-Mailer: Apple Mail (2.1499) Cc: "paws@ietf.org" Subject: Re: [paws] Clock drift problem against SpectrumSchedule start times 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 Feb 2013 15:15:41 -0000 On Feb 12, 2013, at 12:24 PM, Vincent Chen wrote: > Chris, >=20 > Good suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) = and AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that = is the "Generated time". >=20 > Looks like I forgot to add them to the data models in Section 4. >=20 > The intent of this field is, indeed, for the device to determine any = clock skew. Great! But I'm a little confused as to what I, as a poor little device = actually *does* with this information=85 I wake up one morning and look at my clock. it is now 9:34AM on Feb = 13th, 2013=85 Being a good and diligent little radio I contact the WSDB and ask if I = can pretty please have some spectrum. I get back a response that says: protocolInfo: [ 'version': '1.0', 'messageType' : 'AVAIL_SPECTRUM_RESP'] responseInfo: [ big blob-o-stuff ] deviceId: [me! Hey, thats me!] spectumSchedue: [ 'eventTime' : '1971-01-01T14:22:19Z', 'bandwidth': = '10000', 'frequencyRange': '14420000' =85] What do I do? Do I assume that the WSDB must know what time it is better than me and = adjust my clock? Do I say "Hang on a tick, thats in the past, can't be right, I'll just = assume his clock is 42 years, 1 month, 12 days off and automagically add = that to all times from him=85"? =20 Do I only allow offsets of X minutes and Y seconds? Do I care if the messages are coming to my from the future (instead of = the past)? Nasal Demons? So, lets assume we have a "This allocation is for now" concept. What do = I do if the allocation starts "now", but ends yesterday? Hmmm... Maybe absolute times are not the answer -- so, what if we just = make allocations be: start "now", end in "now"+8h. This looks potentially much simpler, but what happens if a messages is = somehow delayed for a long time=85 Still seems better, but=85. W >=20 > I will add the field to the next draft. >=20 > -vince >=20 >=20 > On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe = wrote: > We have recently come across a problem with a similar system to PAWS, = where a small amount of clock drift between the WSD and the WSDB affects = the validity of channel allocations. In some cases the problem causes = the WSDBs to be repeatedly queried.=20 >=20 > =20 >=20 > WSDBs might return allocations which have a start time set to the = WSDB=92s current time, i.e. starting immediately. Start times on = allocations are a good thing, since a device can receive a frequency = plan for the a significant duration without hitting the servers.=20 >=20 > =20 >=20 > But if the device=92s internal clock is running behind the WSDB=92s = clock, there is a potential problem: the WSDB is likely to serve up = allocations which, from the device=92s point of view, are in the future. = If the discrepancy is small, then the device might sensibly remain = silent until its clock has caught up with the SpectrumSchedule=92s start = time. Or more pathologically, the device might query the WSDB repeatedly = in the hope of a better allocation, each time receiving allocations that = seem to always be in the future. We have seen this phenomenon in the = wild. >=20 > =20 >=20 > A possible solution to this problem would be to somehow indicate that = the allocation is for =91now=92.=20 >=20 > =20 >=20 > This could be handled with a =91Generated=92 timestamp on the = AVAIL_SPECTRUM_RESP. In this way, the device can deduce that the WSDB=92s= clock disagrees with the its own clock, and can see that a = SpectrumSchedule is valid with immediate effect. The device could use = the clock discrepancy as a trigger to adjust its internal clock, perhaps = using NTP.=20 >=20 > =20 >=20 > Another possible change: any SpectrumSchedules that start with = immediate effect should be reported as =93valid immediately=94 by a new = flag in the EventTime structure. >=20 > =20 >=20 > Would it make sense to alter the PAWS spec in light of this problem? >=20 > =20 >=20 > Cheers, >=20 > =20 >=20 > Chris Lowe. >=20 > =20 >=20 > -- >=20 > Chris Lowe >=20 > Neul Ltd. =20 >=20 > Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, = Cambridge, CB4 0EY, UK >=20 > http://www.neul.com >=20 > Tel: 01223 437022 >=20 > =20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=20 >=20 > --=20 > -vince > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they = can talk but choose not to do so in case humans put them to work, = possibly in the television industry. In fact they can talk. It's just = that they talk in Orang-utan. Humans are only capable of listening in = Bewilderment. -- Terry Practhett From vchen@google.com Wed Feb 13 08:40: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 19CC721F8893 for ; Wed, 13 Feb 2013 08:40:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl07PKFxcReD for ; Wed, 13 Feb 2013 08:40:57 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5111B21F8890 for ; Wed, 13 Feb 2013 08:40:54 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so1650526wid.6 for ; Wed, 13 Feb 2013 08:40:53 -0800 (PST) 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=1lv1gv0tge7oGte2RUEaXEEm5wMSZMerKFv3nT4wcGw=; b=V2/Qbnd8LADoq8vIou2z5QWEVpYwoHTBhJMBrH+nznqwZGcyvYyeL+j2soesIyZldU ymz1zue8iYZJGOrMM2m5g3PxsGSN+Ll7ycaYHcDrzgJt/Y41icUJldpVyjdM/QPrTbNz 8VRqlWYmqycqEZAk9sJsMNGpif4y+yy2/5LWlCiKn5Gr1+6emRimMIKmgUykATNgsH0T ByPxEhvvOX1c85O9xw6bjDzZiJI9vlBMwo2B7sI5etfqS7KEMilumnMLD+Yufp0UlcXr L7noaKAnQQ6Pxh/GqADrBLiANr8H/QbxEtkjCI502ThbwMdHN17y0QRURH9UHtug1fI5 8oAA== 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=1lv1gv0tge7oGte2RUEaXEEm5wMSZMerKFv3nT4wcGw=; b=YkwA3v2MWsSFWzxLXJiBLzCikcjeVjf89/9YRv4NaDb0b+VR093iqlDmlGtyPAzW5m +fJyCttGqoJ3E51kp/aTyrDzA/PsWq/UoT8lVzrpB7ELoB+zEMslwFL6mqoTkyMTvvFT BWmcJxB+9VrOtRMjsQLvNLXYXW0EbmcbcYtwfnpIEWijPB7ktYoRLDD70oBHzYNEwOTS suENhWiRUaoclqpb5tAvErKInv677R9o7C12D0cnUTS8C1G3mslikjkba6CQNkIe/6gB I9Ti1iMDTalYfzWAXWeHw2VRVwEm2/O+HAdSgQexAFhwVS6W9waf4NLZyLMHJT+0mX3d xC7Q== MIME-Version: 1.0 X-Received: by 10.194.92.231 with SMTP id cp7mr23873030wjb.19.1360773653114; Wed, 13 Feb 2013 08:40:53 -0800 (PST) Received: by 10.194.234.228 with HTTP; Wed, 13 Feb 2013 08:40:52 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 08:40:52 -0800 Message-ID: From: Vincent Chen To: Warren Kumari Content-Type: multipart/alternative; boundary=047d7bfd0c2e36b15104d59dce63 X-Gm-Message-State: ALoCoQm2X5CSK6kzRVAsFX422ujKcCKw1Mn1i/DviPkf136Zui/xA7+M6NPcgXlHf7elEFL2cFBoryzr5QO7R+oSskXlxW1BXk5rLlo/+4SUY0dmCEqUtEMWX+k/+myYi4aOJMVAptSOjJ6kYc/esmyWznPshC8OASqi/BMSCyf3BvEl4CK077h5LYIpCgtt1ms2V3JUTFoL Cc: "paws@ietf.org" Subject: Re: [paws] Clock drift problem against SpectrumSchedule start times 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 Feb 2013 16:40:59 -0000 --047d7bfd0c2e36b15104d59dce63 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Actually, the response says (added the missing timestamp parameter) protocolInfo: [ 'version': '1.0', 'messageType' : 'AVAIL_SPECTRUM_RESP'] timestamp: '1971-01-01T14:00:00' responseInfo: [ big blob-o-stuff ] deviceId: [me! Hey, thats me!] spectumSchedue: [ 'eventTime' : '1971-01-01T14:22:19Z', 'bandwidth': '10000', 'frequencyRange': '14420000' =85] There's a timestamp for the response, so it can be used as reference for the times in the Schedule. The device can choose to do either: - Notice that the event start time is 22 minutes after the response timestamp, so decide to turn on 22 minutes later - Decide to trust the DB's clock and update its own internal clock to match, then use the absolute event time values. On Wed, Feb 13, 2013 at 7:15 AM, Warren Kumari wrote: > > On Feb 12, 2013, at 12:24 PM, Vincent Chen wrote: > > > Chris, > > > > Good suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) an= d > AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" field that is t= he > "Generated time". > > > > Looks like I forgot to add them to the data models in Section 4. > > > > The intent of this field is, indeed, for the device to determine any > clock skew. > > Great! But I'm a little confused as to what I, as a poor little device > actually *does* with this information=85 > > I wake up one morning and look at my clock. it is now 9:34AM on Feb 13th, > 2013=85 > Being a good and diligent little radio I contact the WSDB and ask if I ca= n > pretty please have some spectrum. > > I get back a response that says: > protocolInfo: [ 'version': '1.0', 'messageType' : 'AVAIL_SPECTRUM_RESP'] > responseInfo: [ big blob-o-stuff ] > deviceId: [me! Hey, thats me!] > spectumSchedue: [ 'eventTime' : '1971-01-01T14:22:19Z', 'bandwidth': > '10000', 'frequencyRange': '14420000' =85] > > What do I do? > Do I assume that the WSDB must know what time it is better than me and > adjust my clock? > Do I say "Hang on a tick, thats in the past, can't be right, I'll just > assume his clock is 42 years, 1 month, 12 days off and automagically add > that to all times from him=85"? > Do I only allow offsets of X minutes and Y seconds? > Do I care if the messages are coming to my from the future (instead of th= e > past)? > Nasal Demons? > > > So, lets assume we have a "This allocation is for now" concept. What do I > do if the allocation starts "now", but ends yesterday? > Hmmm... Maybe absolute times are not the answer -- so, what if we just > make allocations be: start "now", end in "now"+8h. > > This looks potentially much simpler, but what happens if a messages is > somehow delayed for a long time=85 Still seems better, but=85. > > W > > > > > > I will add the field to the next draft. > > > > -vince > > > > > > On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe wrote= : > > We have recently come across a problem with a similar system to PAWS, > where a small amount of clock drift between the WSD and the WSDB affects > the validity of channel allocations. In some cases the problem causes th= e > WSDBs to be repeatedly queried. > > > > > > > > WSDBs might return allocations which have a start time set to the WSDB= =92s > current time, i.e. starting immediately. Start times on allocations are = a > good thing, since a device can receive a frequency plan for the a > significant duration without hitting the servers. > > > > > > > > But if the device=92s internal clock is running behind the WSDB=92s clo= ck, > there is a potential problem: the WSDB is likely to serve up allocations > which, from the device=92s point of view, are in the future. If the > discrepancy is small, then the device might sensibly remain silent until > its clock has caught up with the SpectrumSchedule=92s start time. Or more > pathologically, the device might query the WSDB repeatedly in the hope of= a > better allocation, each time receiving allocations that seem to always be > in the future. We have seen this phenomenon in the wild. > > > > > > > > A possible solution to this problem would be to somehow indicate that > the allocation is for =91now=92. > > > > > > > > This could be handled with a =91Generated=92 timestamp on the > AVAIL_SPECTRUM_RESP. In this way, the device can deduce that the WSDB=92= s > clock disagrees with the its own clock, and can see that a SpectrumSchedu= le > is valid with immediate effect. The device could use the clock discrepan= cy > as a trigger to adjust its internal clock, perhaps using NTP. > > > > > > > > Another possible change: any SpectrumSchedules that start with immediat= e > effect should be reported as =93valid immediately=94 by a new flag in the > EventTime structure. > > > > > > > > Would it make sense to alter the PAWS spec in light of this problem? > > > > > > > > Cheers, > > > > > > > > Chris Lowe. > > > > > > > > -- > > > > Chris Lowe > > > > Neul Ltd. > > > > Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, > Cambridge, CB4 0EY, UK > > > > http://www.neul.com > > > > Tel: 01223 437022 > > > > > > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > > > > > > > > -- > > -vince > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > -- > Consider orang-utans. > In all the worlds graced by their presence, it is suspected that they can > talk but choose not to do so in case humans put them to work, possibly in > the television industry. In fact they can talk. It's just that they talk = in > Orang-utan. Humans are only capable of listening in Bewilderment. > -- Terry Practhett > > > --=20 -vince --047d7bfd0c2e36b15104d59dce63 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Actually, the response says (added the missing timestamp p= arameter)

protocolInfo: [ 'version': '1.0', 'messag= eType' : 'AVAIL_SPECTRUM_RESP']
timestamp: '1971-01-01T14:00:00'
responseInfo: [ big blob-o-stuff ]
deviceId: [me! = Hey, thats me!]
spectumSch= edue: [ 'eventTime' : '1971-01-01T14:22:19Z', 'bandwidt= h': '10000', 'frequencyRange': '14420000' =85]<= /span>

=
There's a timestamp for the response, so it can be used as ref= erence for the times in the Schedule.

=
The device can choose to do either:
=A0- Notice that the e= vent start time is 22 minutes after the response timestamp, so decide to tu= rn on 22 minutes later
=A0-= Decide to trust the DB's clock and update its own internal =A0clock to= match, then use the absolute event time values.



On Wed, Feb 13, 2013 at 7:15 AM, Warren Kumari <= warren@kumari.net> wrote:

On Feb 12, 2013, at 12:24 PM, Vincent Chen <vchen@google.com> wrote:

> Chris,
>
> Good suggestion. In the JSON encoding of AVAIL_SPECTRUM_RESP (6.4.2) a= nd AVAIL_SPECTRUM_BATCH_RESP (6.5.2), there is a "timestamp" fiel= d that is the "Generated time".
>
> Looks like I forgot to add them to the data models in Section 4.
>
> The intent of this field is, indeed, for the device to determine any c= lock skew.

Great! But I'm a little confused as to what I, as a poor little d= evice actually *does* with this information=85

I wake up one morning and look at my clock. it is now 9:34AM on Feb 13th, 2= 013=85
Being a good and diligent little radio I contact the WSDB and ask if I can = pretty please have some spectrum.

I get back a response that says:
protocolInfo: [ 'version': '1.0', 'messageType' : &= #39;AVAIL_SPECTRUM_RESP']
responseInfo: [ big blob-o-stuff ]
deviceId: [me! Hey, thats me!]
spectumSchedue: [ 'eventTime' : '1971-01-01T14:22:19Z', = 9;bandwidth': '10000', 'frequencyRange': '14420000&= #39; =85]

What do I do?
Do I assume that the WSDB must know what time it is better than me and adju= st my clock?
Do I say "Hang on a tick, thats in the past, can't be right, I'= ;ll just assume his clock is 42 years, 1 month, 12 days off and automagical= ly add that to all times from him=85"?
Do I only allow offsets of X minutes and Y seconds?
Do I care if the messages are coming to my from the future (instead of the = past)?
Nasal Demons?


So, lets assume we have a "This allocation is for now" concept. W= hat do I do if the allocation starts "now", but ends yesterday? Hmmm... Maybe absolute times are not the answer -- so, what if we just make= allocations be: start "now", end in "now"+8h.

This looks potentially much simpler, but what happens if a messages is some= how delayed for a long time=85 Still seems better, but=85.

W


>
> I will add the field to the next draft.
>
> -vince
>
>
> On Tue, Feb 12, 2013 at 9:09 AM, Chris Lowe <chris.lowe@neul.com> wrote:
> We have recently come across a problem with a similar system to PAWS, = where a small amount of clock drift between the WSD and the WSDB affects th= e validity of channel allocations. =A0In some cases the problem causes the = WSDBs to be repeatedly queried.
>
>
>
> WSDBs might return allocations which have a start time set to the WSDB= =92s current time, i.e. starting immediately. =A0Start times on allocations= are a good thing, since a device can receive a frequency plan for the a si= gnificant duration without hitting the servers.
>
>
>
> But if the device=92s internal clock is running behind the WSDB=92s cl= ock, there is a potential problem: the WSDB is likely to serve up allocatio= ns which, from the device=92s point of view, are in the future. =A0If the d= iscrepancy is small, then the device might sensibly remain silent until its= clock has caught up with the SpectrumSchedule=92s start time. Or more path= ologically, the device might query the WSDB repeatedly in the hope of a bet= ter allocation, each time receiving allocations that seem to always be in t= he future. =A0We have seen this phenomenon in the wild.
>
>
>
> A possible solution to this problem would be to somehow indicate that = the allocation is for =91now=92.
>
>
>
> This could be handled with a =91Generated=92 timestamp on the AVAIL_SP= ECTRUM_RESP. =A0In this way, the device can deduce that the WSDB=92s clock = disagrees with the its own clock, and can see that a SpectrumSchedule is va= lid with immediate effect. =A0The device could use the clock discrepancy as= a trigger to adjust its internal clock, perhaps using NTP.
>
>
>
> Another possible change: any SpectrumSchedules that start with immedia= te effect should be reported as =93valid immediately=94 by a new flag in th= e =A0EventTime structure.
>
>
>
> Would it make sense to alter the PAWS spec in light of this problem? >
>
>
> Cheers,
>
>
>
> Chris Lowe.
>
>
>
> --
>
> Chris Lowe
>
> Neul Ltd.
>
> Suite 42 Innovation Centre, Unit 23 Science Park, Milton Road, Cambrid= ge, CB4 0EY, UK
>
> http://www.neul.com<= /a>
>
> Tel: 01223 437022
>
>
>
>
> _______________________________________________
> paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listinfo/paws
>
>
>
>
> --
> -vince
> _______________________________________________
> paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listinfo/paws

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can t= alk but choose not to do so in case humans put them to work, possibly in th= e television industry. In fact they can talk. It's just that they talk = in Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett





--
-vince
--047d7bfd0c2e36b15104d59dce63-- From amancuso@google.com Wed Feb 13 08:50:39 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 BCCE321F8A96 for ; Wed, 13 Feb 2013 08:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.807 X-Spam-Level: X-Spam-Status: No, score=-101.807 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDdV6obSTTN2 for ; Wed, 13 Feb 2013 08:50:39 -0800 (PST) Received: from mail-la0-x235.google.com (la-in-x0235.1e100.net [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2550721F8A77 for ; Wed, 13 Feb 2013 08:50:37 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fr10so1398240lab.12 for ; Wed, 13 Feb 2013 08:50:37 -0800 (PST) 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=91XQwHOWEcZn2nNZUMWkdQN2wf1xfNGRWCTmQMoVKq0=; b=fVqc5af0wgi5SpOA/uZmqncmn3gbaVxOALpzou03xeFKSxo+MovnXY9/ZwZuFS/i7+ F2evJ6K/XOHkmLeVwn7GdcnbHaWHULMmF2KM1PfjFtsDe+mYlfYs1+fi+JwL6DdcLeKX +s8spAeX7RMDW6HqSMrX9LX7Vn0cTwheye6jSq2RIbJHRs3Xlv1LBm2zDECkfKmSaxqe Ubv8RGClGCmyAWZlEhqYekL8uve33xsLhHLI0CIGE8ptnf5RNcYn43iBFbidFAbII1JU os8hE2HIFC6MGs5Ie9CUWwz9PST2fkr4PjYmMY/7y4kVFd+bhEqXdN0qWPxtDaZW+elV wIFw== 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=91XQwHOWEcZn2nNZUMWkdQN2wf1xfNGRWCTmQMoVKq0=; b=dt2IJcb/fPsb+2jsWXSR3dJ93zvepNo1aeFJt6bE87VHe0SkcIpgZVlxax2T9X3Nx0 ezttAyQHWNyIVNvsLq8eqm35fUCWEZOHczfUqA/Q33QHyo7EWQ+bVPtJVYHpxdfW3+vA N6QRzsKpONU/ybT6IY7N+HI2lXl9xJ1Cn2/7+RvmeIiQdbce2CRHgbaxlN2tE2oJEc3Y yGPPd9OAydxy3OT4WY+ULcC1+OPQD4jj56OZyHvE28xlXFDoejUzyB6or6BGdS2yAVTW eMb7pyfCLHVgUR7IuamrTplqjvvMk4GoSMw82ahP+qq0jW/4Eomni6Y6wpNkaSId/15g mNFA== MIME-Version: 1.0 X-Received: by 10.112.39.1 with SMTP id l1mr9208357lbk.35.1360774236875; Wed, 13 Feb 2013 08:50:36 -0800 (PST) Received: by 10.152.6.42 with HTTP; Wed, 13 Feb 2013 08:50:36 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130213040129.09254bc0@resistor.net> References: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130204064015.09261fa0@resistor.net> <6.2.5.6.2.20130213040129.09254bc0@resistor.net> Date: Wed, 13 Feb 2013 08:50:36 -0800 Message-ID: From: Anthony Mancuso To: SM Content-Type: multipart/alternative; boundary=0023547c9bbd022ba404d59df139 X-Gm-Message-State: ALoCoQnIOfHt4UhsP3QhxAOP0E0WDOpJfn/T4RkVJ1gB/KIiexaYAXbbZy6nIlEYVycDxlIuKVOOkx4Ao+NG6l5AIHG2Ego2amScKeWGZ6V3QUGpbPvBydK6OwD8uEz213wzehVgitwbK/TaNr+F96pOIyj7vxmOihqXUugOqLdbagHaFUkHy7EScnDFx5t/z+tbpvsQZRWE Cc: "paws@ietf.org" , ietf@ietf.org Subject: Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC 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 Feb 2013 16:50:39 -0000 --0023547c9bbd022ba404d59df139 Content-Type: text/plain; charset=ISO-8859-1 Hi SM, I responded inline to your latest comments, below, where I took additional action. Thanks, Tony On Wed, Feb 13, 2013 at 4:33 AM, SM wrote: > Hi Anthony, > > At 17:00 12-02-2013, Anthony Mancuso wrote: > >> In Section 1.1: >> >> "Academia and Industry have studied multiple cognitive radio [2] >> mechanisms for use in such a scenario." >> >> The reference seemed odd. It took me some time to understand that it was >> put in to address a comment. However, the first (external) reference that >> defines that is a 404. >> >> TODO(amancuso): fix link >> > > Ok. > I think the MUST below is one of the two boilerplate words you had a >> comment on. Is there another? >> > > See the section after the Abstract and Section 2.1. TM: Now i see the two. I removed the second (redundant) RFC 2119 wording and reference. > > > In response to earlier comments, this section was reworded and "MUST" >> changed to "must". I assume this is what you were questioning. >> > > Ok. > > > ---- >> >> In Section 4.2: >> >> "A simplified operation scenario of offloading content, such as video >> stream, from the a metered Internet connection to the a WS connection >> consists of the following steps:" >> >> What is a metered Internet connection? >> ---- >> Usage is monitored (metered) and paid for. I rephrased to clarify: "more >> congested or costly Internet connection, such as a metered >> (fee-based-on-usage) wire, wireless, or satellite service." >> > > In my opinion you don't really have to get into all that. I'll defer to > the author. TM: Agreed. Simply referred to the "metered" Internet service as a paid service. > > > cleaned up protocol and operational requirements in response to earlier >> comments. This is a good example of a use case, but didn't fit comfortably >> as a P or O requirement, and was deleted from requirements sections. >> > > Ok. > > > White Space Database (used to be defined in terminology). Changed it >> simply to "database". >> > > Ok. > > > This is a rather large container of worms. We kicked it around for about >> a half-hour and concluded that since this doc is for the Internet >> Engineering Task Force, most readers will understand (and forgive). >> Nonetheless, this is a good point, so I generalized it as follows (while >> retaining the commonly used (and loosely-understood) term: "The database >> and the master device MUST be connected (e.g., through the Internet)." >> > > I agree about that container. :-) The draft is trying to convince me that > white space is better for the Internet connection (see my previous comment > about metered). The requirements is about a protocol to Access Spectrum > Database. IP connectivity is a lower-layer issue. I am ok with the above > text. > > > This section only intends to state the general requirement. It is my >> understanding that the current draft of the protocol specification >> specifies JSON encoding of location parameters that is compatible with >> GEOPRIV. >> > > Ok. > > Regards, > -sm > --0023547c9bbd022ba404d59df139 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi SM,

I responded inline to your lates= t comments, below, where I took additional action.

Thanks,

Tony


On Wed, Feb 13, 2013 at 4:33 AM, SM <sm@r= esistor.net> wrote:
Hi Anthony,

At 17:00 12-02-2013, Anthony Mancuso wrote:
In Section 1.1:

=A0 "Academia and Industry have studied multiple cognitive radio [2] =A0 =A0mechanisms for use in such a scenario."

The reference seemed odd. =A0It took me some time to understand that it was= put in to address a comment. =A0However, the first (external) reference th= at defines that is a 404.

TODO(amancuso): fix link

Ok.=A0

I think the MUST below is one of the two boilerplate words you had a commen= t on. Is there another?

See the section after the Abstract and Section 2.1.
=A0 = =A0
=A0 =A0 TM: Now i see the two. I removed the second (re= dundant) RFC 2119 wording and reference.


In response to earlier comments, this section was reworded and "MUST&q= uot; changed to "must". I assume this is what you were questionin= g.

Ok.


----

In Section 4.2:

=A0 "A simplified operation scenario of offloading content, such as vi= deo
=A0 =A0stream, from the a metered Internet connection to the a WS connectio= n
=A0 =A0consists of the following steps:"

What is a metered Internet connection?
----
Usage is monitored (metered) and paid for. I rephrased to clarify: "mo= re congested or costly Internet connection, such as a metered (fee-based-on= -usage) wire, wireless, or satellite service."

In my opinion you don't really have to get into all that. =A0I'll d= efer to the author.
=A0
=A0 =A0 =A0TM: Agr= eed. Simply referred to the "metered" Internet service as a paid = service.


cleaned up protocol and operational requirements in response to earlier com= ments. This is a good example of a use case, but didn't fit comfortably= as a P or O requirement, and was deleted from requirements sections.

Ok.


White Space Database (used to be defined in terminology). Changed it simply= to "database".

Ok.


This is a rather large container of worms. We kicked it around for about a = half-hour and concluded that since this doc is for the Internet Engineering= Task Force, most readers will understand (and forgive). Nonetheless, this = is a good point, so I generalized it as follows (while retaining the common= ly used (and loosely-understood) term: "The database and the master de= vice MUST be connected (e.g., through the Internet)."

I agree about that container. :-) =A0The draft is trying to convince me tha= t white space is better for the Internet connection (see my previous commen= t about metered). =A0The requirements is about a protocol to Access Spectru= m Database. =A0IP connectivity is a lower-layer issue. =A0I am ok with the = above text.=A0



This section only intends to state the general requirement. It is my unders= tanding that the current draft of the protocol specification specifies JSON= encoding of location parameters that is compatible with GEOPRIV.

Ok.

Regards,
-sm

--0023547c9bbd022ba404d59df139-- From barryleiba.mailing.lists@gmail.com Wed Feb 13 12:33:38 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 0F32821F8555; Wed, 13 Feb 2013 12:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.812 X-Spam-Level: X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhXDuYun6p1O; Wed, 13 Feb 2013 12:33:37 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4755921F84EA; Wed, 13 Feb 2013 12:33:37 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db10so1470875veb.9 for ; Wed, 13 Feb 2013 12:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zL/j3gNlO/Qgcu3R1vfxxKLCBfLvJDF6S7pxaEPKv8Y=; b=Fo92R5LYXN/NkzwuQd3DTu/VasaMe4eA+IyGTuJNINfTAh5yDT4ABh1KOIeAJqozw6 awFFWGLJHr8PMRP5VetPKhwJcLO2xHgCr6nVBf41pzJsuSHkfDz0fqCkOUbcoI/12qYa Kz03K+AMbWQsZ8jy6CtZ2ND2KYpO7X1u1Dnvmpjfidbfi6o8dCAsqd/mHorztXWOAqHE 7Q0gSQMnX5bfkQSc8o9+Sdu/2I9TcsDDGyhkk/hmVwgdkayYOpseCvqtrn2knt32zCJD n4ALIiG/mamUKSpSa3X+frAKv+FhrDK5vE1GWBl1sgDYru7k9UOrDyif4Qx/gSilPvMM uuoA== MIME-Version: 1.0 X-Received: by 10.220.149.200 with SMTP id u8mr31610068vcv.7.1360787616708; Wed, 13 Feb 2013 12:33:36 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 13 Feb 2013 12:33:36 -0800 (PST) In-Reply-To: References: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130204064015.09261fa0@resistor.net> Date: Wed, 13 Feb 2013 15:33:36 -0500 X-Google-Sender-Auth: G5vQnueBH1ZEWOhkAfYiZXxfBUg Message-ID: From: Barry Leiba To: Anthony Mancuso Content-Type: text/plain; charset=ISO-8859-1 Cc: SM , Pete Resnick , "paws@ietf.org" , IETF discussion list Subject: Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC 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 Feb 2013 20:33:38 -0000 Thanks for the thorough reply, Tony. I'm happy with all the resolutions you propose to my issues, and I'm looking forward to reviewing the updated document. > I list Pete Resnick's and Peter Stanforth's comments and my responses first, > followed by Barry Leila's, then SM's. I'm not, however, happy with how you spell my name. But I'll get over it..... Barry LeiBa From amancuso@google.com Wed Feb 13 14:02:34 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 9A70021E803D for ; Wed, 13 Feb 2013 14:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.788 X-Spam-Level: X-Spam-Status: No, score=-101.788 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzBLBOR8D5-X for ; Wed, 13 Feb 2013 14:02:33 -0800 (PST) Received: from mail-la0-x233.google.com (la-in-x0233.1e100.net [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0121E8054 for ; Wed, 13 Feb 2013 14:02:33 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id fo13so1631482lab.24 for ; Wed, 13 Feb 2013 14:02:32 -0800 (PST) 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=IAzcmbnap5HVdvHsT5wHlmCEqUObIYTjzsgapLn1SYk=; b=F3pZFuGuaXhz8NkbGvUfLnMvf2Zs1P6j4qp6mynAubf0GK+zMGViYRtioHmdY3cZhj uoabEoYyOUxQtSbgUH0Yhzl5uNV3OXjFsHcu6u/l3NckYnPsq8Qq0iO+vG3kM7jGHTbl UGgaI7es3JbpWtFfkfsMh9yJNeMMRvLotNNMR8PI517APgdFVZRIFgx5J4GQGzGv2wxh U4L9vFtm2VAOu6RP67P7lth5xKWdDu4ZQv9Xh7pUDYwJvW2FxtK0HJe9O7OwDZwwJukl UP7nKwYJkpYlhY+Jc+C+Bvj54YAkBrkW1d6XkTSu8h1tl3xaqEmKtQFKeD/jvw7Decoe sKtA== 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=IAzcmbnap5HVdvHsT5wHlmCEqUObIYTjzsgapLn1SYk=; b=KS0Z0YFDzHURfjSYqeil9posinBbgJ9q8eNCcwe+NcooN2pr+CzpPwdAJ7afUWCu16 V3aSOpT/xxH22Gec1q8G3KmbEv4QS5FzcWvxl69ZaLTLm6T66uKSs+iq8TVEA2Qgh/69 7FOvdFcXfVKC/H/tZhgwcPMRc8rvaLMnqGesGwO8jyKsa6pSdDgHyg3Xg/zytCCFMOK9 vbaFcWNvrmsR1gOyldPKi1hQRewbumUJrdV26iAnE/jhkReVeTx0Q9C2jVFnTliifitb qJAeHa/iUF+M4dJ70vqVsH0Bd+Pd60Xls8oxyxtFGrxQ+bwAz6tnL7UPKM/EewDL6Ia5 CsoA== MIME-Version: 1.0 X-Received: by 10.112.26.10 with SMTP id h10mr9467549lbg.63.1360792952273; Wed, 13 Feb 2013 14:02:32 -0800 (PST) Received: by 10.152.6.42 with HTTP; Wed, 13 Feb 2013 14:02:32 -0800 (PST) In-Reply-To: References: <20130201132421.6136.92013.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130204064015.09261fa0@resistor.net> Date: Wed, 13 Feb 2013 14:02:32 -0800 Message-ID: From: Anthony Mancuso To: Barry Leiba Content-Type: multipart/alternative; boundary=bcaec553ffc0887c1404d5a24c87 X-Gm-Message-State: ALoCoQmRIMAAzaOPGI7rki+sI3VzxXHN+iVUsiwymCVjkRn65oyrTDhazj6vItqJjZA/araQOj6Hp/vn0cT1MOArhINnsGvpPwnSgmTfW+LN7Fhss1u2Sv5F+ltxxU0ogpMq3pSQl9dSbkCJmCUDtRUpnDJedAAAenhVotUe599WZegjb+Il2En0ygTbJzeKUtULhA2VCopz Cc: SM , Pete Resnick , "paws@ietf.org" , IETF discussion list Subject: Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC 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 Feb 2013 22:02:34 -0000 --bcaec553ffc0887c1404d5a24c87 Content-Type: text/plain; charset=ISO-8859-1 Apologies Barry. Please chalk it up to my haste in getting the email out. Won't happen again. Tony On Wed, Feb 13, 2013 at 12:33 PM, Barry Leiba wrote: > Thanks for the thorough reply, Tony. I'm happy with all the > resolutions you propose to my issues, and I'm looking forward to > reviewing the updated document. > > > I list Pete Resnick's and Peter Stanforth's comments and my responses > first, > > followed by Barry Leila's, then SM's. > > I'm not, however, happy with how you spell my name. But I'll get over > it..... > > Barry LeiBa > --bcaec553ffc0887c1404d5a24c87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Apologies Barry. Please chalk it up to my haste in getting= the email out. Won't happen again.

Tony

On Wed, Feb 13, 2013 at 12:33 PM, Barry Leiba = <barryleiba@computer.org> wrote:
Thanks for the thorough reply, Tony. =A0I= 9;m happy with all the
resolutions you propose to my issues, and I'm looking forward to
reviewing the updated document.

> I list Pete Resnick's and Peter Stanforth's comments and my re= sponses first,
> followed by Barry Leila's, then SM's.

I'm not, however, happy with how you spell my name. =A0But I'= ll get over it.....

Barry LeiBa

--bcaec553ffc0887c1404d5a24c87-- From internet-drafts@ietf.org Wed Feb 13 14:50:00 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 B14B521E8099; Wed, 13 Feb 2013 14:50:00 -0800 (PST) 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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8RXzNmuAxmZ; Wed, 13 Feb 2013 14:50:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4508C21E80A3; Wed, 13 Feb 2013 14:50:00 -0800 (PST) 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.40 Message-ID: <20130213225000.15013.23837.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 14:50:00 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-03.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 Feb 2013 22:50:00 -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 Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-03.txt Pages : 79 Date : 2013-02-13 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vchen@google.com Wed Feb 13 14:54:26 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 31ABE21E809B for ; Wed, 13 Feb 2013 14:54:26 -0800 (PST) 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=[AWL=-0.000, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xcKUTvlDJ53 for ; Wed, 13 Feb 2013 14:54:25 -0800 (PST) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 84BFF21E8099 for ; Wed, 13 Feb 2013 14:54:25 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so4651047wgb.0 for ; Wed, 13 Feb 2013 14:54:24 -0800 (PST) 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=Ubhi8JjLTaKqDgQw0eXa6RdGk6ZY1OFBk8x7D/CxjjQ=; b=D5FmpYgRw6it7Ask1PgCktBkaidTb6ygBOGFzywHqWCdDSuAMuEewW9YQfTf9EoX7R JXBMhKiGy+8NKIFofcAEFTfj4ACXwvowx44/87rp83qgTRgErHburijqXsDW7rXl80eU AzZah6IMvCnGuVgfVocvtWUNJp20PHjIVpjfvtlqG7eRMJTFBvgv/BNBRRwyRC+uwlLx PVLVJsmoAIjb8jprKpXAzICZUMqQ47f7SdhqXpG9z9g90Ydwc/hZXLaMD10r8m/uWDcL elnocpHKCjfa9EER4ObfXzLJ4eEOIUdOWNfA4bIrC3flCooIuwPp1d0avp229C+cCniq Almg== 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=Ubhi8JjLTaKqDgQw0eXa6RdGk6ZY1OFBk8x7D/CxjjQ=; b=mwBRmvRYQej8suWRmSk8TESTQzYT6c/ANu8G63HEudvPAZ+d3YICSWvdb3eEbHGOSv 7iGcn83Jm/wU5S1f0592PJBYY+mw4txEYzEMZ4ORdpul21qicLniFMIhgGw5+hqoERge b4aRevFhmUjCLAKSu8klJSGgloG3ObaJGKRJhc2D9a4tc9fGh2TBhrUsrRsN+4Jt+9YL b7+tIxSgH7j5ddxNVOF0ZSNJskTJYRxMM3iPL1jMeT0jNopzecybNZuF0mhQBZDgE/LA cpaosYViyanuked6myBy+40rbdXMxdCmDD/QRous46+OJiFVwxI1n3XcLjzmfa+f4OEZ fIiw== MIME-Version: 1.0 X-Received: by 10.180.75.110 with SMTP id b14mr13104407wiw.21.1360796021356; Wed, 13 Feb 2013 14:53:41 -0800 (PST) Received: by 10.194.234.228 with HTTP; Wed, 13 Feb 2013 14:53:41 -0800 (PST) Date: Wed, 13 Feb 2013 14:53:41 -0800 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=f46d043be22876f99b04d5a303b7 X-Gm-Message-State: ALoCoQkkQr9m5Tu+LiZJH3WMNjBN58MxfA5t5DHuzxSMhjvwGqDMMM15NzC0UZAabYC14d32XO7USwTOwHCc/IXV6DynwRBnA8IhgoE1rjTax2/4AWl4sMfXI1gFeJS+OtjP32Vp+FzxoQRMnNot4kXkdRvoEs1e/S/VnQzPmPOkGRwRHUnIzxUVQbQGaAZ8hvaoKIqGXput Subject: [paws] Uploaded: draft-ietf-paws-protocol-03 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 Feb 2013 22:54:26 -0000 --f46d043be22876f99b04d5a303b7 Content-Type: text/plain; charset=ISO-8859-1 All, I uploaded version 03 of the draft to address the following: - Add timestamp field to the data models for AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP to address the time-skew issue raised by Chris Lowe. As discussed, the Device may use this as a reference to interpret the event times in the response. - Fixed typos in the JSON encoding section, primarily adding missing commas (Thanks to Kalle Kuismanen) -- -vince --f46d043be22876f99b04d5a303b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

I uploaded version 03 of the draft= to address the following:

=A0- Add timestamp fiel= d to the data models for AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP = to address the time-skew issue raised by Chris Lowe.
=A0 As discussed, the Device may use this as a reference to interpret = the event times in the response.

=A0- Fixed typos = in the JSON encoding section, primarily adding missing commas
=A0= (Thanks to Kalle Kuismanen)

--
-vince
--f46d043be22876f99b04d5a303b7-- From internet-drafts@ietf.org Thu Feb 14 15:21:21 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 557BE21F896E; Thu, 14 Feb 2013 15:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRQJQQtZuXDa; Thu, 14 Feb 2013 15:21:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E282C21F867A; Thu, 14 Feb 2013 15:21:19 -0800 (PST) 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.40 Message-ID: <20130214232119.14298.3659.idtracker@ietfa.amsl.com> Date: Thu, 14 Feb 2013 15:21:19 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-13.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: Thu, 14 Feb 2013 23:21:21 -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-13.txt Pages : 23 Date : 2013-02-14 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-rq= mts-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From presnick@qti.qualcomm.com Thu Feb 14 20:12:42 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 1C07221F857C for ; Thu, 14 Feb 2013 20:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fiv4uny4dhal for ; Thu, 14 Feb 2013 20:12:41 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5C49921F8484 for ; Thu, 14 Feb 2013 20:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1360901561; x=1392437561; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=lu5QncKVPThtRZpuxQzQ0QUmeohqh3qzTyha0XbsGFg=; b=hdg0nZpaGiGsX1pu6qV3RZCZsxMvLU4ccRMGJLQXwCMCQHRvTcNnx+0q SANLiswz1PrKmzTcQ1syMcvpAd9xArHpN+qQS6xIobm1ur/Y5AiNLzRvx 70NKgF7w68Gu5iftMjGsgtatV3OumsGXXfn0M8ry6mmLZusrehxKSK96k c=; X-IronPort-AV: E=Sophos;i="4.84,670,1355126400"; d="scan'208";a="23024671" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 14 Feb 2013 20:12:40 -0800 X-IronPort-AV: E=Sophos;i="4.84,669,1355126400"; d="scan'208";a="485744542" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Feb 2013 20:12:40 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 14 Feb 2013 20:12:40 -0800 Message-ID: <511DB5B6.4070304@qti.qualcomm.com> Date: Thu, 14 Feb 2013 22:12:38 -0600 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: <20130214232119.14298.3659.idtracker@ietfa.amsl.com> In-Reply-To: <20130214232119.14298.3659.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-13.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: Fri, 15 Feb 2013 04:12:42 -0000 Folks, Many thanks to Tony for working through all of the Last Call comments and posting this new draft. I'm in the process of getting everything ready for it being on next week's IESG Telechat (Feb 21) for evaluation. However, there were a *bunch* of changes between this version (-13) and the last (-12). While I will go ahead with this draft, I'd like folks in the WG to review the changes and make sure everything is still in line with WG consensus. If there are concerns, the chairs can always let me know and I can postpone it for the next telechat (unusually in only 1 additional week due to scheduling weirdnesses, Feb 28). But unless I hear differently, I'm going to assume that this is as desired. The diff tool didn't do a good job of figuring out the differences because Tony re-arranged some parts of section 5 to earlier in the document. I've made a re-arranged copy of -12 that will compare better with -13 and put it on my own web site. To see the diff, try this: http://tools.ietf.org/rfcdiff?url1=http://resnick1.qualcomm.com/draft-ietf-paws-problem-stmt-usecases-rqmts-12-pr.txt&url2=draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt I hope that helps. pr On 2/14/13 5:21 PM, internet-drafts@ietf.org wrote: > 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) : Anthony Mancuso > Scott Probasco > Basavaraj Patil > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt > Pages : 23 > Date : 2013-02-14 > > 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-13 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-problem-stmt-usecases-rqmts-13 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From Gabor.Bajko@nokia.com Fri Feb 15 18:15: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 C8F0921E8043 for ; Fri, 15 Feb 2013 18:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4YHmUX5JMgO for ; Fri, 15 Feb 2013 18:15:42 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id B623721E8039 for ; Fri, 15 Feb 2013 18:15:42 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r1G2FeTv013044; Sat, 16 Feb 2013 04:15:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Feb 2013 04:15:40 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.247]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0318.003; Sat, 16 Feb 2013 02:15:39 +0000 From: To: , Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt Thread-Index: AQHOCzK3MnF9lgVtF0qJNo3rHens8ph7umrw Date: Sat, 16 Feb 2013 02:15:38 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602167B97@008-AM1MPN1-007.mgdnok.nokia.com> References: <20130214232119.14298.3659.idtracker@ietfa.amsl.com> <511DB5B6.4070304@qti.qualcomm.com> In-Reply-To: <511DB5B6.4070304@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IgxuUFp6Z9Y405JF/HD4quGBpfhteGxcxEtiC+JFEpvn50+euLjU92O6yuuFuw3LN8KADjuH1Leg/lLko9qLkERQPbziO6yOC5L0rP84e1AzV0n2Bu4l52jZIgHueUZlO9AqmenriKOyN5hdYZYYlrVmMZNSd+vn3s4WjYoK4izZpNZanUvtOMb5DfKyYTj+0V3+F7bu6mE6FZxl6blsHV7NsOmNSw4IvqCkS0eG2iEwr3a2TiLt2xCGZZVOrtIrSTmiAp7Ie7Rpk62HzJgkaWc= x-headerinfofordlp: None x-originating-ip: [10.163.32.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2013 02:15:40.0276 (UTC) FILETIME=[84280B40:01CE0BEB] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-13.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: Sat, 16 Feb 2013 02:15:43 -0000 I went through the changes in the draft (thanks Pete for posting the diff w= hich helps identifying the changes!), and even though there are a lot of ch= anges, they are mostly rewordings, text rearrangements and removal of redun= dancies. The only one issue I found was with the last paragraph of section 3.2, whic= h after rewording became odd. I would suggest replacing it with "Optionally= , and in place of steps 1-3 above, the master device can be pre-configured = with the address (eg, URI) of one or more trusted databases." This change c= an be done together with any additional resolutions to resolve any iesg com= ments. I would suggest this draft is taken to the iesg on the Feb21 telecha= t. Thanks Pete, Tony and all of you who contributed to it, - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Pete Resnick Sent: Thursday, February 14, 2013 8:13 PM To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts= -13.txt Folks, Many thanks to Tony for working through all of the Last Call comments and p= osting this new draft. I'm in the process of getting everything ready for i= t being on next week's IESG Telechat (Feb 21) for evaluation.=20 However, there were a *bunch* of changes between this version (-13) and the= last (-12). While I will go ahead with this draft, I'd like folks in the W= G to review the changes and make sure everything is still in line with WG c= onsensus. If there are concerns, the chairs can always let me know and I ca= n postpone it for the next telechat (unusually in only 1 additional week du= e to scheduling weirdnesses, Feb 28). But unless I hear differently, I'm go= ing to assume that this is as desired. The diff tool didn't do a good job of figuring out the differences because = Tony re-arranged some parts of section 5 to earlier in the document. I've m= ade a re-arranged copy of -12 that will compare better with -13 and put it = on my own web site. To see the diff, try this: http://tools.ietf.org/rfcdiff?url1=3Dhttp://resnick1.qualcomm.com/draft-iet= f-paws-problem-stmt-usecases-rqmts-12-pr.txt&url2=3Ddraft-ietf-paws-problem= -stmt-usecases-rqmts-13.txt I hope that helps. pr On 2/14/13 5:21 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > 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 Ca= ses and Requirements > Author(s) : Anthony Mancuso > Scott Probasco > Basavaraj Patil > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt > Pages : 23 > Date : 2013-02-14 > > 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 > -13 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases > -rqmts-13 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > =20 -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From amancuso@google.com Sat Feb 16 18:51:28 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 909AF21F86C9 for ; Sat, 16 Feb 2013 18:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.773 X-Spam-Level: X-Spam-Status: No, score=-101.773 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1iFGxoJQjeD for ; Sat, 16 Feb 2013 18:51:27 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CE95521F86AF for ; Sat, 16 Feb 2013 18:51:26 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id eb20so4566517lab.31 for ; Sat, 16 Feb 2013 18:51:25 -0800 (PST) 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=InAKarzO+QY2E4ndSqrzyylwJuPOi7urXNsqHcRZb9s=; b=C1SY9aLCqIoskTYWb3mGu5D/kVQKg5RCdGKC6SxSTkE33UjZDFesV14+v1YXUsYgDK stTgSLnxhnw6ArP37XzLV0fGJQbq24CMncvGf0epC5cLPgqY4rYoLeBSBtRt/mOvhpRq INi50C1VOi/+aP1QS/oRLvBmtKV7Y1IfNzoRkrUAnEuPoAWicUoLPcDmYW98wZZMxreD ASKoXBZZKL1fwGzUGBQF9qHD5gQ3u97n6LhIVjqcGzQQruOoboSBX1xea5qsnIEd09nW 6smQfSpdAxo61toQSSaLSp8AAJpyq/GwcmIeiCIM/sAxJYhLGYFYKKAAgnkti+xdAvAh NGKw== 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=InAKarzO+QY2E4ndSqrzyylwJuPOi7urXNsqHcRZb9s=; b=EznepMXUteaX+H2ytMAmUBf1sQqv85V3b4h9F+lpKlSihzYgmHItLZuBRFgex4vzQp 65l7cyf2ItOJk+48F7apPEx78kD5uhHYHX7tMNRdXFqqPUjpxsP2ON0JbrGu7uZK/eGl wiqCabRmNADqUYk3RvBL10CMpz63roEXATbVKv0Ep3EIsOp2Tp82SvAHJvJWtflcwwHs b8dNBd62odUtmQKiUAH8Npr0RA0vS+2Ayl6oVu/Wf4v1z+Bt/Dcsgy04rLPDac/XoDjS yx42K/IKc3lwXBcqJtR63Va+g1cyAxJ73H6YCaCNyo68tQ9JavHZU4DB4U31/Y1WFu18 g+KQ== MIME-Version: 1.0 X-Received: by 10.112.98.71 with SMTP id eg7mr3924472lbb.133.1361069485397; Sat, 16 Feb 2013 18:51:25 -0800 (PST) Received: by 10.152.22.103 with HTTP; Sat, 16 Feb 2013 18:51:25 -0800 (PST) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47602167B97@008-AM1MPN1-007.mgdnok.nokia.com> References: <20130214232119.14298.3659.idtracker@ietfa.amsl.com> <511DB5B6.4070304@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602167B97@008-AM1MPN1-007.mgdnok.nokia.com> Date: Sat, 16 Feb 2013 18:51:25 -0800 Message-ID: From: Anthony Mancuso To: Gabor Bajko Content-Type: multipart/alternative; boundary=f46d04016a753117ae04d5e2af47 X-Gm-Message-State: ALoCoQlkOrzVAYMZqDBWYjt3lZXFNU3fQV5PmMmEAXzZvWmS2zGPgeZ56aRhskJtssYaMhovfAxgtObZRqMkN4iZ5BZoCD/hhU8NrzonawhliAE/xnUWehbobqZSsZf985nLITefuvfVpD+t3q9HXt7nN6bFZEQE6nKf4Ch5G4W3xrBN9yQPAEw4Va/w9zhd29ipiMf1RIfc Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-13.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: Sun, 17 Feb 2013 02:51:28 -0000 --f46d04016a753117ae04d5e2af47 Content-Type: text/plain; charset=ISO-8859-1 Thanks Gabor. I used your text (but noticed that it should reference preceding steps 1-2, not 1-3, as I originally wrote).: "Optionally, and in place of steps 1-2 above, the master device can be pre-configured with the address (e.g., URI) of one or more trusted databases. The master device can establish contact with one of these trusted databases." I also made a change based on a comment from Pete Resnick. I assume from your email that I should not post a new version 14 (with the two most recent changes) until after the Feb21 telechat? Tony On Fri, Feb 15, 2013 at 6:15 PM, wrote: > I went through the changes in the draft (thanks Pete for posting the diff > which helps identifying the changes!), and even though there are a lot of > changes, they are mostly rewordings, text rearrangements and removal of > redundancies. > The only one issue I found was with the last paragraph of section 3.2, > which after rewording became odd. I would suggest replacing it with > "Optionally, and in place of steps 1-3 above, the master device can be > pre-configured with the address (eg, URI) of one or more trusted > databases." This change can be done together with any additional > resolutions to resolve any iesg comments. I would suggest this draft is > taken to the iesg on the Feb21 telechat. > > Thanks Pete, Tony and all of you who contributed to it, > - Gabor > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > ext Pete Resnick > Sent: Thursday, February 14, 2013 8:13 PM > To: paws@ietf.org > Subject: Re: [paws] I-D Action: > draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt > > Folks, > > Many thanks to Tony for working through all of the Last Call comments and > posting this new draft. I'm in the process of getting everything ready for > it being on next week's IESG Telechat (Feb 21) for evaluation. > However, there were a *bunch* of changes between this version (-13) and > the last (-12). While I will go ahead with this draft, I'd like folks in > the WG to review the changes and make sure everything is still in line with > WG consensus. If there are concerns, the chairs can always let me know and > I can postpone it for the next telechat (unusually in only 1 additional > week due to scheduling weirdnesses, Feb 28). But unless I hear differently, > I'm going to assume that this is as desired. > > The diff tool didn't do a good job of figuring out the differences because > Tony re-arranged some parts of section 5 to earlier in the document. I've > made a re-arranged copy of -12 that will compare better with -13 and put it > on my own web site. To see the diff, try this: > > > http://tools.ietf.org/rfcdiff?url1=http://resnick1.qualcomm.com/draft-ietf-paws-problem-stmt-usecases-rqmts-12-pr.txt&url2=draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt > > I hope that helps. > > pr > > On 2/14/13 5:21 PM, internet-drafts@ietf.org wrote: > > 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) : Anthony Mancuso > > Scott Probasco > > Basavaraj Patil > > Filename : > draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt > > Pages : 23 > > Date : 2013-02-14 > > > > 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 > > -13 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-problem-stmt-usecases > > -rqmts-13 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > --f46d04016a753117ae04d5e2af47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Gabor. I used your text (but noticed that it should= reference preceding steps 1-2, not 1-3, as I originally wrote).:

<= /div>
"Optionally, and in place of steps 1-2 above, the master dev= ice can be pre-configured with the address (e.g., URI) of one or more trust= ed databases. The master device can establish contact with one of these tru= sted databases."

I also made a change based on a comment fro= m Pete Resnick. I assume from your email that I should not post a new versi= on 14 (with the two most recent changes) until after the Feb21 telechat?

Tony
=

On Fri, Feb 15, 2013 at 6:15 PM, <= Gabor.Bajko@nokia.com> wrote:
I went through the changes in the draft (tha= nks Pete for posting the diff which helps identifying the changes!), and ev= en though there are a lot of changes, they are mostly rewordings, text rear= rangements and removal of redundancies.
The only one issue I found was with the last paragraph of section 3.2, whic= h after rewording became odd. I would suggest replacing it with "Optio= nally, and in place of steps 1-3 above, the master device can be pre-config= ured with the address (eg, URI) of one or more trusted databases." Thi= s change can be done together with any additional resolutions to resolve an= y iesg comments. I would suggest this draft is taken to the iesg on the Feb= 21 telechat.

Thanks Pete, Tony and all of you who contributed to it,
- Gabor


-----Original Message-----
From: paws-bounces@ietf.org [m= ailto:paws-bounces@ietf.org] O= n Behalf Of ext Pete Resnick
Sent: Thursday, February 14, 2013 8:13 PM
To: paws@ietf.org
Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts= -13.txt

Folks,

Many thanks to Tony for working through all of the Last Call comments and p= osting this new draft. I'm in the process of getting everything ready f= or it being on next week's IESG Telechat (Feb 21) for evaluation.
However, there were a *bunch* of changes between this version (-13) and the= last (-12). While I will go ahead with this draft, I'd like folks in t= he WG to review the changes and make sure everything is still in line with = WG consensus. If there are concerns, the chairs can always let me know and = I can postpone it for the next telechat (unusually in only 1 additional wee= k due to scheduling weirdnesses, Feb 28). But unless I hear differently, I&= #39;m going to assume that this is as desired.

The diff tool didn't do a good job of figuring out the differences beca= use Tony re-arranged some parts of section 5 to earlier in the document. I&= #39;ve made a re-arranged copy of -12 that will compare better with -13 and= put it on my own web site. To see the diff, try this:

http://tools.= ietf.org/rfcdiff?url1=3Dhttp://resnick1.qualcomm.com/draft-ietf-paws-proble= m-stmt-usecases-rqmts-12-pr.txt&url2=3Ddraft-ietf-paws-problem-stmt-use= cases-rqmts-13.txt

I hope that helps.

pr

On 2/14/13 5:21 PM, internet-dr= afts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> =A0 This draft is a work item of the Protocol to Access WS database Wo= rking Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Protocol to Access White Space= (PAWS) Database: Use Cases and Requirements
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Anthony Mancuso
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Scott Probasco<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Basavaraj Patil=
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-paws-problem-stmt-use= cases-rqmts-13.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 23
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-14
>
> Abstract:
> =A0 =A0 Portions of the radio spectrum that are assigned to a particul= ar use
> =A0 =A0 but are unused or unoccupied at specific locations and times a= re
> =A0 =A0 defined as "white space." =A0The concept of allowing= additional
> =A0 =A0 transmissions (which may or may not be licensed) in white spac= e is a
> =A0 =A0 technique to "unlock" existing spectrum for new use.= =A0This document
> =A0 =A0 includes the problem statement for the development of a protoc= ol to
> =A0 =A0 access a database of whitespace information followed by use ca= ses and
> =A0 =A0 requirements for that protocol. =A0Finally, requirements assoc= iated
> =A0 =A0 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-p= roblem-stmt-usecases-rqmts
> -13
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-paws-problem-stmt-usecases
> -rqmts-13
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listinfo/paws
>

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

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

--f46d04016a753117ae04d5e2af47-- From weixinpeng@huawei.com Sun Feb 17 18:20:27 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 2EE2B21E8054 for ; Sun, 17 Feb 2013 18:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j-rOLC4ySbU for ; Sun, 17 Feb 2013 18:20:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1652B21E803C for ; Sun, 17 Feb 2013 18:20:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APU86648; Mon, 18 Feb 2013 02:20:24 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 18 Feb 2013 02:19:53 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 18 Feb 2013 02:20:21 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.243]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Mon, 18 Feb 2013 10:20:10 +0800 From: Weixinpeng To: "paws@ietf.org" Thread-Topic: [A new PAWS DB Discovery Draft] Thread-Index: Ac4NfnihkQ8JzQAnQoK6ECuRW0SSyg== Date: Mon, 18 Feb 2013 02:20:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43C8F0B41nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Peter McCann Subject: [paws] [A new PAWS DB Discovery Draft] 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 Feb 2013 02:20:27 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43C8F0B41nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, A new draft of DB Discovery has been submitted: http://www.ietf.org/id/draft-wei-paws-database-discovery-00.txt Comments are welcome!! --Xinpeng Wei. --_000_C5C3BB522B1DDF478AA09545169155B43C8F0B41nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

A new draft of DB Discovery has= been submitted:

http://www.ietf.org/id/draft-we= i-paws-database-discovery-00.txt

 

Comments are welcome!!

 

--Xinpeng Wei.

--_000_C5C3BB522B1DDF478AA09545169155B43C8F0B41nkgeml507mbxchi_-- From peter@spectrumbridge.com Mon Feb 18 10:09:18 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 0E2D521F869F for ; Mon, 18 Feb 2013 10:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yqN5BeQfnsy for ; Mon, 18 Feb 2013 10:09:17 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id E549721F853E for ; Mon, 18 Feb 2013 10:09:16 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 18 Feb 2013 13:09:16 -0500 From: Peter Stanforth To: Weixinpeng , "paws@ietf.org" Date: Mon, 18 Feb 2013 13:09:15 -0500 Thread-Topic: [paws] [A new PAWS DB Discovery Draft] Thread-Index: Ac4OAw+MXxxYIfZhQ6qOc0XG9wq8kg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD47D4727CCFpeterspectrumbridgecom_" MIME-Version: 1.0 Cc: Peter McCann Subject: Re: [paws] [A new PAWS DB Discovery Draft] 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 Feb 2013 18:09:18 -0000 --_000_CD47D4727CCFpeterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am Still not a fan of basing DB discovery on the LOST protocol. It seems = to be way to complicated and I would hope someone can explain how to reconc= ile the capability with the need. That said the following comments are independent of the LOST protocol. The introduction should be expanded to identify that there are many ways th= at a device could get access to a database not just the manually programmed= example given. The WSDB DS will very likely be nested. I cannot see Ofcom giving up owners= hip and authority of its DB discovery process for instance. So a WSDB DS wo= uld have to reconcile that a WSD was in the UK regulatory domain and provid= e a reference to the Ofcom DB Management system. Under current US rules there is no concept of a WSDB DS radios are certifie= d against a database. However a device certified in the USA may travel to o= ther countries and then need to use a WSDB DS. So the other case that needs= to be discussed is a device that in some instances has a preconfigured lin= k to a database and the ability to use a WSDB DS in other cases. There may= be a situation (and I am making this up for an example) where a device is = certified in the US along with a database, certified in Canada along with a= database and certified generically in the rest of the world. This device m= ay have a hierarchy where it checks with the US DB first. If it gets denied= (because it is outside the regulatory domain) then it tries Canada and if = that also fails goes to the WSDB DS. This raises a couple of questions. Is the WDSB DS going to return all "cert= ified" databases in a regulatory domain or only the ones that are appropria= te for the device making the query? How is the set of regulatory certified domains mapped to those databases wi= lling to serve the device or the databases the device is willing to go to (= This is a business decision)? Wearing my DB provider hat, I only want to (a= nd only will) serve devices for which I have a business relationship with t= he manufacturer or possibly the owner. Does this process work if the owner of the device is to make the decision r= ather than the device? Did we cover the correct set of responses from a DB to cover this mechanism= ? Although the WSDB DS thinks that the device should be associated with a DB = the DB does not The DB does not want to serve the device even though it is on the WSDB DS l= ist The Device does not want to work with a DB on the list (how does it know if= all it gets is a URL =96 so radio vendor x is won't work with DB provider= y) The device has a preference to work with DB vendor y in as many regulatory = domains as possible It seems many of these can be addressed more easily if the device uses a ma= nufacturer provided discovery process (as it will have knowledge of the bus= iness relationships) rather than some new global entity that will have to b= e created, maintained and supported. Which brings me to my final question = who owns and operates the WSDB DS and who pays for it? Regards, Peter S. From: Weixinpeng > Date: Sunday, February 17, 2013 9:20 PM To: "paws@ietf.org" > Cc: Peter McCann > Subject: [paws] [A new PAWS DB Discovery Draft] Hi all, A new draft of DB Discovery has been submitted: http://www.ietf.org/id/draft-wei-paws-database-discovery-00.txt Comments are welcome!! --Xinpeng Wei. --_000_CD47D4727CCFpeterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I am Still not a fan of basing = DB discovery on the LOST protocol. It seems to be way to complicated and I = would hope someone can explain how to reconcile the capability with the nee= d.
That said the following comments are independent of the LOST p= rotocol.

The introduction should be expanded to id= entify that there are many ways that a device could get access to a databas= e not just the manually programmed example given.

= The WSDB DS will very likely be nested. I cannot see Ofcom giving up owners= hip and authority of its DB discovery process for instance. So a WSDB DS wo= uld have to reconcile that a WSD was in the UK regulatory domain and provid= e a reference to the Ofcom DB Management system.

U= nder current US rules there is no concept of a WSDB DS radios are certified= against a database. However a device certified in the USA may travel to ot= her countries and then need to use a WSDB DS. So the other case that needs = to be discussed is a device that in some instances has a preconfigured link= to a database and the ability to use a WSDB DS in other cases.  There= may be a situation (and I am making this up for an example) where a device= is certified in the US along with a database, certified in Canada along wi= th a database and certified generically in the rest of the world. This devi= ce may have a hierarchy where it checks with the US DB first. If it gets de= nied (because it is outside the regulatory domain) then it tries Canada and= if that also fails goes to the WSDB DS.

This rais= es a couple of questions. Is the WDSB DS going to return all "certifie= d" databases in a regulatory domain or only the ones that are appropri= ate for the device making the query?
How is the set of regulatory= certified domains mapped to those databases willing to serve the device or= the databases the device is willing to go to (This is a business decision)= ? Wearing my DB provider hat, I only want to (and only will) serve devices = for which I have a business relationship with the manufacturer or possibly = the owner.
Does this process work if the owner of the device is t= o make the decision rather than the device?
Did we cover the corr= ect set of responses from a DB to cover this mechanism? 
Although the = WSDB DS thinks that the device should be associated with a DB the DB does n= ot
The DB does not want to serve the device even though it is on the WSDB D= S list
= The Device does not want to work with a DB on the list (how does it = know if all it gets is a URL =96 so radio vendor x is won't work with  = ;DB provider y)
The device has a preference to work with DB vendor y in as = many regulatory domains as possible

It seems many = of these can be addressed more easily if the device uses a manufacturer pro= vided discovery process (as it will have knowledge of the business relation= ships) rather than some new global entity that will have to be created, mai= ntained and supported.  Which brings me to my final question who owns = and operates the WSDB DS and who pays for it?

Rega= rds,
Peter S.


From: Weixinpeng <weixinpeng@huawei.com>
Date: Sunday, February 17, 2013 9:20 PM
To: "paws@ie= tf.org" <paws@ietf.org>=
Cc: Peter McCann <Peter.McCann@huawei.com>
Subject: [paws] [A new PAWS DB Discove= ry Draft]

Hi all,<= /p>

A new draft of DB Discovery = has been submitted:

http://www.ietf.org/id/draft-wei-paws-database-discovery-00.txt=

=  

Comments= are welcome!!

 

--Xinpeng Wei.

 --_000_CD47D4727CCFpeterspectrumbridgecom_-- From Gabor.Bajko@nokia.com Mon Feb 18 11:34:00 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 C870921F8AB1 for ; Mon, 18 Feb 2013 11:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3En-4ZpAUl5 for ; Mon, 18 Feb 2013 11:34:00 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4159921F88DB for ; Mon, 18 Feb 2013 11:34:00 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r1IJX0wD029297 for ; Mon, 18 Feb 2013 21:33:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Feb 2013 21:33:44 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.247]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0318.003; Mon, 18 Feb 2013 19:33:44 +0000 From: To: Thread-Topic: timeslot request for presentation in PAWS@IETF in Orlando Thread-Index: Ac4ODlmU8AStiVohSq+nRopwFrPDqw== Date: Mon, 18 Feb 2013 19:33:43 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760216D3D6@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.5.9.3 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-tituslabs-classificationhash-30: QYoRBtnynnTV/bAp8JVwv+ibm5YfBzVTKqNKIAwlqDzrZfw09BvnmmjXM0xLMCNOcfZZHvKAms3HlIrpFWenEA4PE7zYDyYLw3C+v2rZ++ki2/O1osfng4FRtaeH0ySL2m2e+dZA4k4WXPqUnfWidG7LwmuoHhd5U8+yYa5J2DEP9L4T4dYb1XGvUDgBohBmqUaeY++0v8mYf66E/CXCLBNvOiSqnMxQIZ96DuCnOsTqb6RVv1DbZUZXv/W3G5DEfomzu5FbsSvVknDx66t5Bw== x-headerinfofordlp: None x-originating-ip: [10.163.33.120] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760216D3D6008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 18 Feb 2013 19:33:44.0914 (UTC) FILETIME=[DD851320:01CE0E0E] X-Nokia-AV: Clean Subject: [paws] timeslot request for presentation in PAWS@IETF in Orlando 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 Feb 2013 19:34:00 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760216D3D6008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, PAWS got a 2h slot at the upcoming Orlando F2F, scheduled for Tuesday, Marc= h 12 @1pm-3pm. If you would like to present, please send a slot request to the chairs not = later than the end of this week. Thanks, Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760216D3D6008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

PAWS got a 2h slot at the upcoming Orlando F2F, sche= duled for Tuesday, March 12 @1pm-3pm.

 

If you would like to present, please send a slot req= uest to the chairs not later than the end of this week.

 

Thanks, Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760216D3D6008AM1MPN1007mg_-- From weixinpeng@huawei.com Mon Feb 18 19:53: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 1030E21E803A for ; Mon, 18 Feb 2013 19:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F8OjLooN0e2 for ; Mon, 18 Feb 2013 19:53:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3221F8A9B for ; Mon, 18 Feb 2013 19:53:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOO79218; Tue, 19 Feb 2013 03:53:01 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 03:52:18 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Feb 2013 03:52:58 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.243]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Tue, 19 Feb 2013 11:52:46 +0800 From: Weixinpeng To: Peter Stanforth , "paws@ietf.org" Thread-Topic: [paws] [A new PAWS DB Discovery Draft] Thread-Index: Ac4NfnihkQ8JzQAnQoK6ECuRW0SSygAQYjaAACRVNJA= Date: Tue, 19 Feb 2013 03:52:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43C8F0D04nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Peter McCann Subject: Re: [paws] [A new PAWS DB Discovery Draft] 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 Feb 2013 03:53:17 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43C8F0D04nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your comments. Please see my answers inline. Best Regards, Xinpeng W. From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Tuesday, February 19, 2013 2:09 AM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: Re: [paws] [A new PAWS DB Discovery Draft] I am Still not a fan of basing DB discovery on the LOST protocol. It seems = to be way to complicated and I would hope someone can explain how to reconc= ile the capability with the need. That said the following comments are independent of the LOST protocol. The introduction should be expanded to identify that there are many ways th= at a device could get access to a database not just the manually programmed= example given. [Wei] Yeah, you are right here, I there are many ways for a device getting = access to a database besides manually programmed, and I will describe more = in detail in the later version. The WSDB DS will very likely be nested. I cannot see Ofcom giving up owners= hip and authority of its DB discovery process for instance. So a WSDB DS wo= uld have to reconcile that a WSD was in the UK regulatory domain and provid= e a reference to the Ofcom DB Management system. Under current US rules there is no concept of a WSDB DS radios are certifie= d against a database. However a device certified in the USA may travel to o= ther countries and then need to use a WSDB DS. So the other case that needs= to be discussed is a device that in some instances has a preconfigured lin= k to a database and the ability to use a WSDB DS in other cases. There may= be a situation (and I am making this up for an example) where a device is = certified in the US along with a database, certified in Canada along with a= database and certified generically in the rest of the world. This device m= ay have a hierarchy where it checks with the US DB first. If it gets denied= (because it is outside the regulatory domain) then it tries Canada and if = that also fails goes to the WSDB DS. This raises a couple of questions. Is the WDSB DS going to return all "cert= ified" databases in a regulatory domain or only the ones that are appropria= te for the device making the query? [Wei] Here the databases return from WSDB DS means all the certified databa= ses in a regulatory domain. Whether a database is appropriate is not decide= d in the discovery procedure, but in the following procedure when WSD conne= cts to the database, if the selected database cannot serve the WSD, the WSD= will ignore the database and try another one and so on. How is the set of regulatory certified domains mapped to those databases wi= lling to serve the device or the databases the device is willing to go to (= This is a business decision)? Wearing my DB provider hat, I only want to (a= nd only will) serve devices for which I have a business relationship with t= he manufacturer or possibly the owner. Does this process work if the owner of the device is to make the decision r= ather than the device? Did we cover the correct set of responses from a DB to cover this mechanism= ? Although the WSDB DS thinks that the device should be associated wit= h a DB the DB does not The DB does not want to serve the device even though it is on the WS= DB DS list The Device does not want to work with a DB on the list (how does it = know if all it gets is a URL - so radio vendor x is won't work with DB pro= vider y) The device has a preference to work with DB vendor y in as many regu= latory domains as possible It seems many of these can be addressed more easily if the device uses a ma= nufacturer provided discovery process (as it will have knowledge of the bus= iness relationships) rather than some new global entity that will have to b= e created, maintained and supported. Which brings me to my final question = who owns and operates the WSDB DS and who pays for it? [Wei] The discovery mechanism provided here is an optional method and it ma= y be cooperated with other method to find the appropriate database for WSD. Regards, Peter S. From: Weixinpeng > Date: Sunday, February 17, 2013 9:20 PM To: "paws@ietf.org" > Cc: Peter McCann > Subject: [paws] [A new PAWS DB Discovery Draft] Hi all, A new draft of DB Discovery has been submitted: http://www.ietf.org/id/draft-wei-paws-database-discovery-00.txt Comments are welcome!! --Xinpeng Wei. --_000_C5C3BB522B1DDF478AA09545169155B43C8F0D04nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks = for your comments. Please see my answers inline.

Best Re= gards,

Xinpeng= W.

&n= bsp;

From: Peter Stanfo= rth [mailto:peter@spectrumbridge.com]
Sent: Tuesday, February 19, 2013 2:09 AM
To: Weixinpeng; paws@ietf.org
Cc: Peter McCann
Subject: Re: [paws] [A new PAWS DB Discovery Draft]

 

I am Stil= l not a fan of basing DB discovery on the LOST protocol. It seems to be way= to complicated and I would hope someone can explain how to reconcile the c= apability with the need.

That said= the following comments are independent of the LOST protocol.

&nbs= p;

The intro= duction should be expanded to identify that there are many ways that a devi= ce could get access to a database not just the manually programmed example = given.

[= Wei] Yeah, you are right here, = I there are many ways for a device getting access to a database besides man= ually programmed, and I will describe more in detail in the later version.

&n= bsp;

The WSDB = DS will very likely be nested. I cannot see Ofcom giving up ownership and a= uthority of its DB discovery process for instance. So a WSDB DS would have = to reconcile that a WSD was in the UK regulatory domain and provide a reference to the Ofcom DB Management syste= m.

&nbs= p;

Under cur= rent US rules there is no concept of a WSDB DS radios are certified against= a database. However a device certified in the USA may travel to other coun= tries and then need to use a WSDB DS. So the other case that needs to be discussed is a device that in some inst= ances has a preconfigured link to a database and the ability to use a WSDB = DS in other cases.  There may be a situation (and I am making this up = for an example) where a device is certified in the US along with a database, certified in Canada along with a database= and certified generically in the rest of the world. This device may have a= hierarchy where it checks with the US DB first. If it gets denied (because= it is outside the regulatory domain) then it tries Canada and if that also fails goes to the WSDB DS.

&nbs= p;

This rais= es a couple of questions. Is the WDSB DS going to return all "certifie= d" databases in a regulatory domain or only the ones that are appropri= ate for the device making the query?

[= Wei] Here the databases return from WSDB DS means all the certified databas= es in a regulatory domain. Whether a database is appropriate is not decided= in the discovery procedure, but in the following procedure when WSD connects to the database, if the selected dat= abase cannot serve the WSD, the WSD will ignore the database and try anothe= r one and so on.

&n= bsp;

How is th= e set of regulatory certified domains mapped to those databases willing to = serve the device or the databases the device is willing to go to (This is a= business decision)? Wearing my DB provider hat, I only want to (and only will) serve devices for which I have a busin= ess relationship with the manufacturer or possibly the owner.

Does this= process work if the owner of the device is to make the decision rather tha= n the device?

Did we co= ver the correct set of responses from a DB to cover this mechanism? 

       Although the WSDB = DS thinks that the device should be associated with a DB the DB does not

       The DB does not wa= nt to serve the device even though it is on the WSDB DS list

       The Device does no= t want to work with a DB on the list (how does it know if all it gets is a = URL – so radio vendor x is won't work with  DB provider y)<= /o:p>

       The device has a p= reference to work with DB vendor y in as many regulatory domains as possibl= e

&nbs= p;

It seems = many of these can be addressed more easily if the device uses a manufacture= r provided discovery process (as it will have knowledge of the business rel= ationships) rather than some new global entity that will have to be created, maintained and supported.  Which= brings me to my final question who owns and operates the WSDB DS and who p= ays for it?

[= Wei] The discovery mechanism provided here is an optional method and it may= be cooperated with other method to find the appropriate database for WSD.<= o:p>

&n= bsp;

Regards,<= o:p>

Peter S.<= o:p>

&nbs= p;

&nbs= p;

From: Weix= inpeng <weixinpeng@huawei.com>
Date: Sunday, February 17, 2013 9:20 PM
To: "paws@ietf.org" &= lt;paws@ietf.org>
Cc: Peter McCann <Pete= r.McCann@huawei.com>
Subject: [paws] [A new PAWS DB Discovery Draft]

&nbs= p;

Hi all,

A new dra= ft of DB Discovery has been submitted:

http:/= /www.ietf.org/id/draft-wei-paws-database-discovery-00.txt

 

Comments = are welcome!!

 

--Xinpeng= Wei.

--_000_C5C3BB522B1DDF478AA09545169155B43C8F0D04nkgeml507mbxchi_-- From brian.rosen@neustar.biz Tue Feb 19 11:32:42 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 32FBC21E8090 for ; Tue, 19 Feb 2013 11:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta5CQAbNabMt for ; Tue, 19 Feb 2013 11:32:40 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0D91C21E80AE for ; Tue, 19 Feb 2013 11:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361302529; x=1676653161; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=IFWYsp0LyLicsxQqSzFs87JQ4J9N+ym9Tj6j8Zhgl4s=; b=llJ5BJwoge2JHEiryIY+24f+Gx2w77hKu78fD4O/2hHVQhHusAUXUYNEfzrTag EtCJ6sOsvisF+P1O7+vMgu+Q== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.19968003; Tue, 19 Feb 2013 14:35:28 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 19 Feb 2013 14:32:14 -0500 From: "Rosen, Brian" To: Weixinpeng Date: Tue, 19 Feb 2013 14:32:13 -0500 Thread-Topic: [paws] [A new PAWS DB Discovery Draft] Thread-Index: Ac4O19F5fOphfdInRL+1/JCmj4h6HA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 0IZ/0+vnRuZruNkwplW+gg== Content-Type: multipart/alternative; boundary="_000_FA81D6FB30E444AFA3FB18D40F9E507Eneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] [A new PAWS DB Discovery Draft] 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 Feb 2013 19:32:42 -0000 --_000_FA81D6FB30E444AFA3FB18D40F9E507Eneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As someone who participated in the LoST development, things like this alway= s look complex until you try to build something "simpler". It's just not a= simple problem. You can make it simpler only by changing the problem. Fo= r example, you can require some amount of provisioning before it will work. The way LoST works, the national regulator can control how resolution of th= e LoST servers works. You can have all queries within a country go to a sp= ecific server that then refers or iterates to another server, or you can re= turn a list of servers that can satisfy the response and let the client cho= ose. Brian On Feb 18, 2013, at 10:52 PM, Weixinpeng > wrote: Thanks for your comments. Please see my answers inline. Best Regards, Xinpeng W. From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Tuesday, February 19, 2013 2:09 AM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: Re: [paws] [A new PAWS DB Discovery Draft] I am Still not a fan of basing DB discovery on the LOST protocol. It seems = to be way to complicated and I would hope someone can explain how to reconc= ile the capability with the need. That said the following comments are independent of the LOST protocol. The introduction should be expanded to identify that there are many ways th= at a device could get access to a database not just the manually programmed= example given. [Wei] Yeah, you are right here, I there are many ways for a device getting = access to a database besides manually programmed, and I will describe more = in detail in the later version. The WSDB DS will very likely be nested. I cannot see Ofcom giving up owners= hip and authority of its DB discovery process for instance. So a WSDB DS wo= uld have to reconcile that a WSD was in the UK regulatory domain and provid= e a reference to the Ofcom DB Management system. Under current US rules there is no concept of a WSDB DS radios are certifie= d against a database. However a device certified in the USA may travel to o= ther countries and then need to use a WSDB DS. So the other case that needs= to be discussed is a device that in some instances has a preconfigured lin= k to a database and the ability to use a WSDB DS in other cases. There may= be a situation (and I am making this up for an example) where a device is = certified in the US along with a database, certified in Canada along with a= database and certified generically in the rest of the world. This device m= ay have a hierarchy where it checks with the US DB first. If it gets denied= (because it is outside the regulatory domain) then it tries Canada and if = that also fails goes to the WSDB DS. This raises a couple of questions. Is the WDSB DS going to return all "cert= ified" databases in a regulatory domain or only the ones that are appropria= te for the device making the query? [Wei] Here the databases return from WSDB DS means all the certified databa= ses in a regulatory domain. Whether a database is appropriate is not decide= d in the discovery procedure, but in the following procedure when WSD conne= cts to the database, if the selected database cannot serve the WSD, the WSD= will ignore the database and try another one and so on. How is the set of regulatory certified domains mapped to those databases wi= lling to serve the device or the databases the device is willing to go to (= This is a business decision)? Wearing my DB provider hat, I only want to (a= nd only will) serve devices for which I have a business relationship with t= he manufacturer or possibly the owner. Does this process work if the owner of the device is to make the decision r= ather than the device? Did we cover the correct set of responses from a DB to cover this mechanism= ? Although the WSDB DS thinks that the device should be associated wit= h a DB the DB does not The DB does not want to serve the device even though it is on the WS= DB DS list The Device does not want to work with a DB on the list (how does it = know if all it gets is a URL =96 so radio vendor x is won't work with DB p= rovider y) The device has a preference to work with DB vendor y in as many regu= latory domains as possible It seems many of these can be addressed more easily if the device uses a ma= nufacturer provided discovery process (as it will have knowledge of the bus= iness relationships) rather than some new global entity that will have to b= e created, maintained and supported. Which brings me to my final question = who owns and operates the WSDB DS and who pays for it? [Wei] The discovery mechanism provided here is an optional method and it ma= y be cooperated with other method to find the appropriate database for WSD. Regards, Peter S. From: Weixinpeng > Date: Sunday, February 17, 2013 9:20 PM To: "paws@ietf.org" > Cc: Peter McCann > Subject: [paws] [A new PAWS DB Discovery Draft] Hi all, A new draft of DB Discovery has been submitted: http://www.ietf.org/id/draft-wei-paws-database-discovery-00.txt Comments are welcome!! --Xinpeng Wei. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_FA81D6FB30E444AFA3FB18D40F9E507Eneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As someone who participated in the LoST development, things like th= is always look complex until you try to build something "simpler".  It= 's just not a simple problem.  You can make it simpler only by changin= g the problem.  For example, you can require some amount of provisioni= ng before it will work.  

The way LoST works, the n= ational regulator can control how resolution of the LoST servers works. &nb= sp;You can have all queries within a country go to a specific server that t= hen refers or iterates to another server, or you can return a list of serve= rs that can satisfy the response and let the client choose.

<= /div>
Brian


On Feb 18, 2013= , at 10:52 PM, Weixinpeng <weix= inpeng@huawei.com> wrote:

Thanks f= or your comments. Please see my answers inline.
Best Regards,
Xinpeng W.
 <= /div>
From: Peter Stanforth [mailto:peter@spectrumbri= dge.com] 
Sent:=  Tuesday, February 19= , 2013 2:09 AM
To: Weixinpeng; paws@ietf.org
Cc:&= nbsp;Peter McCann
Subject: Re: [paws] [A new PAWS DB Discovery Draft]
 
I am Still not a fan of basing DB discovery on = the LOST protocol. It seems to be way to complicated and I would hope someo= ne can explain how to reconcile the capability with the need.
That said the following comments are independent of the = LOST protocol.
 
= The introduction should be expanded to identify that there are many ways th= at a device could get access to a database not just the manually programmed= example given.
[Wei] Yeah, you are right he= re, I there are many ways for a device getting access to a database besides= manually programmed, and I will describe more in detail in the later versi= on.
 
The WSDB DS will very likely be nested. I cannot see Ofcom giving up= ownership and authority of its DB discovery process for instance. So a WSD= B DS would have to reconcile that a WSD was in the UK regulatory domain and= provide a reference to the Ofcom DB Management system.
 
Under current US rules there is no= concept of a WSDB DS radios are certified against a database. However a de= vice certified in the USA may travel to other countries and then need to us= e a WSDB DS. So the other case that needs to be discussed is a device that = in some instances has a preconfigured link to a database and the ability to= use a WSDB DS in other cases.  There may be a situation (and I am mak= ing this up for an example) where a device is certified in the US along wit= h a database, certified in Canada along with a database and certified gener= ically in the rest of the world. This device may have a hierarchy where it = checks with the US DB first. If it gets denied (because it is outside the r= egulatory domain) then it tries Canada and if that also fails goes to the W= SDB DS.
 
This ra= ises a couple of questions. Is the WDSB DS going to return all "certified" = databases in a regulatory domain or only the ones that are appropriate for = the device making the query?
[Wei] Here the databases ret= urn from WSDB DS means all the certified databases in a regulatory domain. = Whether a database is appropriate is not decided in the discovery procedure= , but in the following procedure when WSD connects to the database, if the = selected database cannot serve the WSD, the WSD will ignore the database an= d try another one and so on.
 
How is the set of regulatory certified = domains mapped to those databases willing to serve the device or the databa= ses the device is willing to go to (This is a business decision)? Wearing m= y DB provider hat, I only want to (and only will) serve devices for which I= have a business relationship with the manufacturer or possibly the owner.<= o:p>
= Does this process work if the owner of the = device is to make the decision rather than the device?
Did we cover the correct set of responses from a DB to cover th= is mechanism? 
       Although = the WSDB DS thinks that the device should be associated with a DB the DB do= es not
 = ;      = The DB does not want t= o serve the device even though it is on the WSDB DS list<= /div>
     =   The Device does not want to work with a DB on t= he list (how does it know if all it gets is a URL =96 so radio vendor x is = won't work with  DB provider y)
       The device has a preference to work with DB vendor y in as many reg= ulatory domains as possible
 
It seems many of these can be addressed more easily if the dev= ice uses a manufacturer provided discovery process (as it will have knowled= ge of the business relationships) rather than some new global entity that w= ill have to be created, maintained and supported.  Which brings me to = my final question who owns and operates the WSDB DS and who pays for it?
[Wei] The disc= overy mechanism provided here is an optional method and it may be cooperate= d with other method to find the appropriate database for WSD.
 
Regard= s,
Peter S.
 
 
= From: Weixinpeng <weixinpeng@huawei.com<= /a>>
Date: S= unday, February 17, 2013 9:20 PM
To: "paws@ietf.org" <paws@= ietf.org>
Cc: Peter McCann <Peter.McCann@huawei.com>= ;
Subject: [paw= s] [A new PAWS DB Discovery Draft]
 
Hi all,
A new draft of DB Discov= ery has been submitted:
 
Comments= are welcome!!
 
--Xinpeng W= ei.
______________________________= _________________
paws mailing list
= paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

= --_000_FA81D6FB30E444AFA3FB18D40F9E507Eneustarbiz_-- From vchen@google.com Wed Feb 27 17:15:52 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 EB54121F84AE for ; Wed, 27 Feb 2013 17:15:51 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs-vnUpeGv2c for ; Wed, 27 Feb 2013 17:15:49 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 916E921F8D3B for ; Wed, 27 Feb 2013 16:50:25 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so5855047wgh.1 for ; Wed, 27 Feb 2013 16:49:23 -0800 (PST) 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=JjJYdbfuScjy59tJ33DBzvEQjYQY6I7nTjF32DUPfX4=; b=Fl+9bxVlEpJHUxJmFALHT4OcOTDfhgkIM7Uh4Z0OwoIIstFusyWez4VCvtMm0Hh/Wd 6CuN64U1Eca/vmQNV3tnMXS2nsOlU8bmWFV341GwuusxKgPdYoZ5cJxbTOvlSNhoKl+N 1FgnFEct0NfXNi98Sn6PasjHNg+0Ajv38Wd0Q+937U22posUpx8XtNcOZM8eXwmEYXFq OupcAM2JzVFFS3VFLD59YeCw+32SJyl76zUju08ACxR9qc5/ufBqZBOA00aG5fRmfQjp IZ/os6Rk/RnIZmDCEgqYISfHdrp5qYfVz5fKhWpEwEb9EtKBTMmghz3lditXAMiSElAu ggeA== 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=JjJYdbfuScjy59tJ33DBzvEQjYQY6I7nTjF32DUPfX4=; b=doqOrEmEZ9090xYK339FbK1GxIQpLo1dFzV7VygjsZhoxmkJKtJmLEz7SchfzkPIns lyP1o4RTRrDabvDiPjSPEqe0nUnck8ae1ulKpITjHiXUzisdbYejkd4zIMNqgfDg6oH/ /X1GdrbP6V9ikf+OmDL2YySH504ftLXc716FhK3AYXg6l/lzNjmWbjPROxkr2iW++8DE UILOfwWXDUpJqYOUUtZ4zY7h7snYybjbnbqBfdB1eOZnGexNI1T3/Z0nL3AcB/1OAcDv ZzvhRrhRW5sCKXtxerVFVh+4Ro/s8KA3sa1jeQpMb5AbHVqNvSvzsPdm9XD2TVMOSJho Z2Kw== MIME-Version: 1.0 X-Received: by 10.194.157.42 with SMTP id wj10mr7594747wjb.12.1362012557898; Wed, 27 Feb 2013 16:49:17 -0800 (PST) Received: by 10.194.104.200 with HTTP; Wed, 27 Feb 2013 16:49:17 -0800 (PST) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760216D3D6@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760216D3D6@008-AM1MPN1-007.mgdnok.nokia.com> Date: Wed, 27 Feb 2013 16:49:17 -0800 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/alternative; boundary=089e0112c512b301ef04d6be4288 X-Gm-Message-State: ALoCoQnidFNbwDISPjm4xz2gRIhclT2rTyKVPD9N7yaEPm84tqxIIO2VYmTem55hGxmcdnFVBlUePxHb2CkY8u48bunA3GknFBc+1UR/ozX6dVkSqH+n2C+Iq47hAbyR3mSSHKQhCXaQ6CQ6NfmJTpXE/vv+3i9I1paBYtkcEV5i8rwCGpfLZC4rf2AM35yeRIglH33/9pIf Cc: "paws@ietf.org" Subject: Re: [paws] timeslot request for presentation in PAWS@IETF in Orlando 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 Feb 2013 01:15:52 -0000 --089e0112c512b301ef04d6be4288 Content-Type: text/plain; charset=ISO-8859-1 Gabor, Sorry for the delay. I would like an hour to discuss the protocol doc. - Discuss how comments from the previous F2F were addressed in the latest draft - Discuss any open issues. Thanks. On Mon, Feb 18, 2013 at 11:33 AM, wrote: > Folks,**** > > ** ** > > PAWS got a 2h slot at the upcoming Orlando F2F, scheduled for Tuesday, > March 12 @1pm-3pm.**** > > ** ** > > If you would like to present, please send a slot request to the chairs not > later than the end of this week.**** > > ** ** > > Thanks, Gabor**** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- -vince --089e0112c512b301ef04d6be4288 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gabor,

Sorry for the delay.
I= would like an hour to discuss the protocol doc.
=A0- Discu= ss how comments from the previous F2F were addressed in the latest draft
=A0- Discuss any open issues.

Thanks.


On Mon, Feb 18, 2013 at 11:33 AM, <<= a href=3D"mailto:Gabor.Bajko@nokia.com" target=3D"_blank">Gabor.Bajko@nokia= .com> wrote:

Folks,

=A0

PAWS got a 2h slot at the upcoming Orlando F2F, sche= duled for Tuesday, March 12 @1pm-3pm.

=A0

If you would like to present, please send a slot req= uest to the chairs not later than the end of this week.

=A0

Thanks, Gabor


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




--
-vince
--089e0112c512b301ef04d6be4288--