From nobody Tue Sep 2 03:29:12 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1CF1A000B for ; Tue, 2 Sep 2014 03:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.069 X-Spam-Level: X-Spam-Status: No, score=-3.069 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ3FJRsheIZk for ; Tue, 2 Sep 2014 03:29:09 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2381A0009 for ; Tue, 2 Sep 2014 03:29:08 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=Oiz1LteVhXNNTX2WnNRsrCO8bT7zeMqpzuOxGI4VM2oOxi+peN00el2L tkBSQ62eVbUdfY3qt0qFkxoLMz7u+CFru1fhc+88TGFkZ3LrBRo2nCA+q EA5nlf5enR7pX0iqVyERQzDELBX03w68JfFJ4mr8CQ6UEXsbQf9jKQhl9 IlV5EHBPh67ttj3pwHH2eIHFtZ6ZEO1uOGtoGLSUQ9PZK+wMAae5hfN5O AgLqX+jcSQE1CeLkqpQ1cGpsPx2y1; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1409653749; x=1441189749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dFy6B3zdoaAD1xZqcRahO3S1JxMyYqb141Joubv3gBA=; b=VR/Hkq9ty6otaNgtQZBGDlcT5D2LPqppKoX6YbbHgH2qjjAvzasNNsn0 3NvmtLSGl8TmUeFoXSI9Xel5zf4Qx5sC13/wVax+NG2eQJ5ETRen7m1jW GHcZ4KdhYc5ADLU3w/8RLlo2+1Pidk86wOGOLm26PsOsrcXYtIlNoOF9G 7pRiHeTDfNv5EnIYXFYAxIHSz7eNrU/gQzkXijb84+1BumUexWqS9SAiD wVp5UThu5/GO2up1TSzlq5iv4kz+/; X-IronPort-AV: E=Sophos;i="5.04,447,1406588400"; d="scan'208";a="12047995" X-IPAS-Result: AhsFAM6aBVTV+MWR/2dsb2JhbABZgmojgSoEz1QBgQ8Wd4QEAQQBOhkmBQsCAQg2EDIlAgQOBYg6CQO6DQEXjxozB4MvgR0FqHWJBYIbgUZsgUiBBwEBAQ Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 02 Sep 2014 11:29:07 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Tue, 2 Sep 2014 11:29:07 +0100 From: Ray Bellis To: Stephen Farrell Thread-Topic: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) Thread-Index: AQHPvLpCqLffAolOpUC/MItyIJZCM5vatvffgAAvHICAADSNAIAAJRgAgAAmpwCAAAGTAIASP0aA Date: Tue, 2 Sep 2014 10:29:05 +0000 Message-ID: <15D47237-9517-45B2-A14A-25DDA47162D2@nominet.org.uk> References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> <53F64D64.8050002@cs.tcd.ie> In-Reply-To: <53F64D64.8050002@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <5581AFA2C39E04428D0714F6F1243326@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/HUjeTTDzgXU1IoTsQwMztPzT5SI Cc: "paws@ietf.org" , Kathleen Moriarty , Pete Resnick Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2014 10:29:11 -0000 On 21 Aug 2014, at 20:49, Stephen Farrell wrote= : > Nothing really to do with IESG processing of this but I'm > curious... >=20 > Is the full DB information really considered public? My > impression was rather that trying to extract the full DB > of information via repeated queries would be frowned upon. [apologies for the late reply to the thread - I've been on vacation] That's certainly the case with OFCOM in the UK. DB operators are supposed = to prevent large scale mining of the database even if the result of an indi= vidual query might be considered "public". In particular the 100m DTT pixe= l data is derived from Arqiva's TV transmission information and they consid= er that commercially sensitive. [In some respects this is somewhat like my employer's domain business - the= "whois" for an individual domain is publicly available, but we come down v= ery hard on anybody caught attempting to mine the entire database]. Ray From nobody Tue Sep 2 10:39:37 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD71A87E2 for ; Tue, 2 Sep 2014 10:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFaDoLTvSiCz for ; Tue, 2 Sep 2014 10:36:15 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935A41A87D9 for ; Tue, 2 Sep 2014 10:36:15 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id i50so7027716qgf.10 for ; Tue, 02 Sep 2014 10:36:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=i6Y3qac0BYnvHE7E1RXir9AKePDv4Yr1QOse/4q5XjI=; b=ThssZ2xG4Ob24Kj07o0ySDKDAKZV0jdZso0qluMPqz653+qAdSGpMdfV0FrELcC9X8 wvnNNZHyVWYWzkGvKHNHyyrWjMrrXq/sws0uuqg9NsgFaIQJxeV6iGzYz/cQMfx8US7C qHBidNZJLEdf00TteLzj/itbUNJy3+rQnKTHWhZHCGhSPweQFdVnIBBo+3khIlCGYj1K K3hp+FrSn/gFGRvnz638jt8kUK9xhKEKTBzXIZM/skOCg6TRwI/SgcP0AoKTMyKD1y/B 6NOFxwImZmA1uQ/l679vfGIoViaAn8qJBpHM7pz/Vw9r4lggifYGFtcGzR69uARrpxCa qBSw== X-Gm-Message-State: ALoCoQnGGly83vNAbN8/z1r5cr5uY+Xg3melLhLlX1Z6MKYP12Az7a60v6pFaxJ71sBereblqNDI X-Received: by 10.140.36.118 with SMTP id o109mr53157497qgo.25.1409679374740; Tue, 02 Sep 2014 10:36:14 -0700 (PDT) Received: from [10.33.192.86] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 75sm5750536qgg.25.2014.09.02.10.36.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 10:36:14 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_CE15FE31-2DF5-44C8-ADDE-DB4C068B7D4D" Message-Id: <7C7F87D0-25E5-4396-B6AF-2C3907933B77@brianrosen.net> Date: Tue, 2 Sep 2014 13:36:11 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/paws/b8FPbB_5uarRODnZeqchviAhSqc X-Mailman-Approved-At: Tue, 02 Sep 2014 10:39:35 -0700 Subject: [paws] Minutes Posted X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2014 17:36:17 -0000 --Apple-Mail=_CE15FE31-2DF5-44C8-ADDE-DB4C068B7D4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry for the delay. Minutes from the meeting at IETF90 have been = posted. Please look them over and send any corrections. http://www.ietf.org/proceedings/90/minutes/minutes-90-paws Brian= --Apple-Mail=_CE15FE31-2DF5-44C8-ADDE-DB4C068B7D4D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Sorry for the delay.  Minutes from the meeting at IETF90 have been posted.  Please look them over and send any corrections. --Apple-Mail=_CE15FE31-2DF5-44C8-ADDE-DB4C068B7D4D-- From nobody Tue Sep 2 19:27:04 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124FB1A897E; Tue, 2 Sep 2014 19:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJZMWf2KFvwT; Tue, 2 Sep 2014 19:27:00 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9C51A896F; Tue, 2 Sep 2014 19:27:00 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EF7A81B85BF; Tue, 2 Sep 2014 19:26:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A0D7053E073; Tue, 2 Sep 2014 19:26:59 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Sep 2014 19:26:59 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2D25CF45-7C93-4894-B8F1-17D92E0F273E" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> Date: Tue, 2 Sep 2014 22:26:27 -0400 Message-ID: <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> To: Vincent Chen X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/yBDPoZcMcYXYFH-aLTPdbtHSgRs Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 02:27:04 -0000 --Apple-Mail=_2D25CF45-7C93-4894-B8F1-17D92E0F273E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" Pete pinged me on this last Thursday, and I finally had time to go = through and check each of the points I raised to see if they had been = addressed. Most of them have been, but there are a few that remain = (highlighted in alternating colors; I'm keeping all the points here for = my convenience, so don't feel you need to look at anything but the = colorful stuff.) --Ted-- 4.1 says "Some regulatory domains may have specific rules regarding how long the spectrum data remains valid in these cases." It might be worth adding that in such cases the initialization procedure is required. This is addressed to some extent in section 4.3, but I'm not sure it's completely addressed. The potential problem I see is that a device might be used in a regulatory regime where this is required, but might have pre-configured values for some other regulatory regime. If these values are not valid in the regime that applies for its current location, it might have a too-long refresh interval configured, fail to detect that this is the case, and as a result accidentally break the law. Can a scenario like this occur in practice? --Vincent-- It should not occur in practice for well-behaved devices. When it is preconfigured, there must be a preconfigured value for each ruleset. Of course, a device may choose to use preconfigured values for only a subset of the rulesets it supports. Note that, in practice, a device needs to be certified for each "ruleset" by whatever process is defined by each applicable regulatory body, so that any preconfigured values will be certified to be compliant. --Ted-- If this is how it works, shouldn't the document say so? Or was that in the requirements document? I admit it's been a while since I read it. :) --Vincent-- I'll clarify the text some. Note, however, that INIT_RESP return these values as part of a RulesetInfo structure, so that it is implied that preconfiguration also must be on a per-ruleset basis. --Ted-- To be clear, what I was suggesting ought to be documented is that the information has to be preconfigured and certified by the regulatory authority. If this is already mentioned in the requirements document, there's no need to mention it here, although a reference to the previous document might be helpful for neophytes like me. I don't really know what the mental context of a reader of this document would be, so please forgive me if I'm being ridiculous here. --STATUS-- Addressed in -14. --Ted-- Section 5.2 says that the manufacturer ID and model ID are optional, but may be required by some rulesets. Section 4.3.1 does not say what error is returned when a deviceDesc that does not contain one or both of these parameters is sent to the server, but the matching ruleset requires either parameter. I suspect the answer is straightforward, but I think it needs to be stated explicitly in 4.3.1. E.g., if the optional but required parameters are accepted in the initialization but rejected in the registration, it would be good to say so explicitly. --Vincent-- OK. In these cases, the Database should return the MISSING error, with additional data specifying the missing fields. --STATUS-- There has been no change to the document that I can find that addresses this point. --Ted-- In 4.4.2, I think that if none of the rulesets are accepted, the intent is that the database should return a REGISTRATION_RESP with the error element, and will not return a rulesetInfos list. However, the specification does not make an exception for this case when it says "A RulesetInfo list MUST be included" and "The list MUST contain at least one entry". I can't think of another valid interpretation, but you've stated a MUST, so you need to say that it doesn't apply in the case of the error. --Vincent-- Ah, right. There is language from INIT_RESP that needs to be repeated = here. --Ted-- The problem I have with this text actually stems from the first paragraph of the section: The registration response message acknowledges successful registration by including a RulesetInfo message for each ruleset in which the registration is accepted. If the Database does not accept the registration for any of the rulesets it supports, the Database MUST return the NOT_REGISTERED error (See Error Codes (Section 5.17)). In reviewing this just now, I realized that I may have completely misinterpreted the second sentence. It probably means either: If the database does not accept the registration for any single ruleset it supports, the database MUST return the NOT_REGISTERED error. Or: If none of the rulesets being registered are accepted by the database, the database MUST return the NOT_REGISTERED error. Right now, your use of "any" could be interpreted either way. And then, what I was asking you to change in this DISCUSS item was this: rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in the response. Each entry corresponds to a ruleset for which the registration was accepted. The list MUST contain at least one entry. [If an error is being returned, this list MUST be omitted.] The text in brackets is what I am proposing that you should add. Otherwise you are giving the implementor conflicting instructions--a MUST is a MUST, and has to be followed, but of course it can't be followed if no rulesets match. I'm just asking you to make that explicit so that nobody gets confused. Anyway, it sounds like we're converging. Let me know if what I'm saying still doesn't make sense. --STATUS-- It looks like Vincent made the change he suggested, but did not follow up on what I said in my last response, above (nobody replied to that message). I think this is an open issue that should be addressed. --Ted-- In 4.5: If some locations within a batch request are outside the regulatory domain supported by the Database, the Database MAY return an OK response with available spectrum for only the valid locations; otherwise, if all locations within a batch request are outside the regulatory domain, the Database MUST respond with an OUTSIDE_COVERAGE error. What should the database do if it doesn't follow the MAY? Should it return an OUTSIDE_COVERAGE error? It seems to me that this MAY is = going to require some unclear heuristics on the side of the master device. =20 Why isn't this a MUST? I think if this were a MUST, it would be clear how implementations should behave; by making it a MAY, there's a big gap that I think will lead to interoperability problems as different implementors make different choices about how to treat this situation. --Vincent-- If it does not follow MAY, the assumption is that it would return OUTSIDE_COVERAGE error. I take your point about it being harder to use for the device. I don't think there would be objections to changing this to a MUST. --Ted-- That would certainly satisfy my concern! :) --STATUS-- The proposed change has not been made to the document. --Ted-- Section 3 describes spectrum-usage messages as purely informational. =20 Section 4.5 says that the database can require that such messages be sent. Which is it: is it sometimes required, or always purely informational? Or does "purely informational" just mean that the protocol provides no mechanism for tracking such notifications? It = would be helpful if this were clearer. --Vincent-- "purely informational" means that the it's just notifying the Database what spectrum it intends to use and is not a request to the Database to get permission to use that spectrum. Some regulators require this notification. I'll try to clarify the text. --Ted-- Ah, that explains it. Thanks. Adding some text pretty much like what you just wrote would address this comment nicely. --Vincent-- Will do. --STATUS-- Addressed in -15. --Ted-- In 4.1, the database URI change spec seems incomplete. Is there a time when a database starts announcing its URI change after which it need no longer provide service on the old URI? I see Alissa asked a similar question, so I imagine you could address both questions together. --Vincent-- Yes, specifying a time is reasonable. --STATUS-- Addressed in -15. --Ted-- In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be somewhat fluid. I think you intend for it to mean one specific thing, which might imply one of several other things. But you don't say the one thing that it means: instead you mention possible implications. It would be helpful to try to make this more explicit. I think Stephen noticed this same problem, but to be clear, it appears that section 4.5 says that when the master is sending a request on = behalf of a slave, it sends its own location. But section 4.5.1 says that the master sends the slave's location. It appears that there are two parameters, one being the master location, which is required, and the other being the slave location, which is optional. However, this is never really stated explicitly; it might be helpful if it were. --Vincent-- OK. UNSUPPORTED means that the Database does not support the device (based on it type, model, etc.) or any rulesets indicated by the Device. I'll update both. --STATUS-- Addressed in -15. --Ted-- In 4.6.1, it would help to have text that explains what it means to validate a device. It's certainly not required for interoperability, but might be helpful for implementors of database servers. --Vincent-- This is explained in the first paragraph of 4.6, I think. A Slave Device needs a Master Device to ask the Database on its behalf for available spectrum. Depending on the ruleset, the Master Device also must validate with the Database that the Slave Device is permitted to operate. ... --Ted-- Ah, okay. The problem is that "validate the device" isn't obviously connected to "validate with the database that the ..." I see the connection now, but it would help to make it clearer. --Vincent-- Will do. --STATUS-- Addressed in -15. --Ted-- In 5.3, it's a little puzzling that antenna direction, radiation = pattern, gain and polarization aren't defined, because they seem like properties that should have universal applicability, even if they are not required in all cases. Is this being left as future work, or is there some more subtle reason why these haven't been defined explicitly? --Vincent-- This is for future extension, rather than defining a whole set of things = that won't get used. Note that for mobile devices, = direction/pattern/polarization changes all the time and would be "crazy" to define rules based on these characteristics.=20 --Ted-- Right, just checking. --STATUS-- addressed --Ted-- In 5.11, power is expressed in dbm, which leads me to wonder if this is the product of the antenna gain and the input power to the output amplifier, or whether it's just the input power to the amplifier, or whether it's being left intentionally ambiguous. --Vincent-- Great question. I believe this was left intentionally ambiguous, since each regulator may choose to define the power in a different way. Typically, it's the radiated power at the antenna, over some bandwidth, averaged over some period of time (defined by the regulator). Perhaps I should add the "Typically" statement to Section 5.11 that describes Spectrum. --Ted-- The problem with this is that if the meaning of the unit is different depending on the regulatory regime, it might make life really difficult for the maker of a device that has to operate in different regimes. I suppose makers of devices like this are used to this problem, so maybe it's not really a problem in practice, but it would certainly be nice to talk a bit about this in the document. --Vincent-- I'll add it to the doc. --STATUS-- I don't see a change to the document to address this point. --Apple-Mail=_2D25CF45-7C93-4894-B8F1-17D92E0F273E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" Pete pinged me on this last = Thursday, and I finally had time to go through and check each of the = points I raised to see if they had been addressed.   Most of them = have been, but there are a few that remain (highlighted in alternating = colors; I'm keeping all the points here for my convenience, so don't = feel you need to look at anything but the colorful = stuff.)

--Ted--
4.1 says "Some regulatory domains = may have specific rules regarding
how long the spectrum data remains = valid in these cases."  It might be
worth adding that in such = cases the initialization procedure is
required.  This is = addressed to some extent in section 4.3, but I'm
not sure it's = completely addressed.  The potential problem I see is
that a = device might be used in a regulatory regime where this is
required, = but might have pre-configured values for some other
regulatory = regime.  If these values are not valid in the regime = that
applies for its current location, it might have a too-long = refresh
interval configured, fail to detect that this is the case, = and as a
result accidentally break the law.  Can a scenario like = this occur in
practice?

--Vincent--
It should not occur in = practice for well-behaved devices.

When it is preconfigured, = there must be a preconfigured value for each
ruleset.  Of = course, a device may choose to use preconfigured values
for only a = subset of the rulesets it supports.

Note that, in practice, a = device needs to be certified for each
"ruleset" by whatever process = is defined by each applicable regulatory
body, so that any = preconfigured values will be certified to = be
compliant.

--Ted--

If this is how it works, = shouldn't the document say so?  Or was that
in the requirements = document?  I admit it's been a while since I read
it. = :)

--Vincent--

I'll clarify the text some. Note, however, = that INIT_RESP return these
values as part of a RulesetInfo = structure, so that it is implied that
preconfiguration also must be = on a per-ruleset basis.

--Ted--
To be clear, what I was = suggesting ought to be documented is that the
information has to be = preconfigured and certified by the regulatory
authority.  If = this is already mentioned in the requirements document,
there's no = need to mention it here, although a reference to the
previous = document might be helpful for neophytes like me.  I don't
really = know what the mental context of a reader of this document would
be, = so please forgive me if I'm being ridiculous = here.

--STATUS--

Addressed in -14.

--Ted--
Section 5.2 says that the manufacturer ID = and model ID are optional,
but may be required by some rulesets. =  Section 4.3.1 does not say what
error is returned when a = deviceDesc that does not contain one or both
of these parameters is = sent to the server, but the matching ruleset
requires either = parameter.  I suspect the answer is straightforward,
but I think = it needs to be stated explicitly in 4.3.1.  E.g., if = the
optional but required parameters are accepted in the = initialization
but rejected in the registration, it would be good to = say so
explicitly.

--Vincent--
OK. In these cases, the = Database should return the MISSING error, with
additional data = specifying the missing fields.

--STATUS--

There has been = no change to the document that I can find that
addresses this = point.

--Ted--
In 4.4.2, I = think that if none of the rulesets are accepted, the intent
is that = the database should return a REGISTRATION_RESP with the = error
element, and will not return a rulesetInfos list.   = However, the
specification does not make an exception for this case = when it says "A
RulesetInfo list MUST be included" and  "The = list MUST contain at least
one entry".   I can't think of = another valid interpretation, but you've
stated a MUST, so you need = to say that it doesn't apply in the case of
the = error.

--Vincent--
Ah, right. There is language from INIT_RESP = that needs to be repeated here.

--Ted--
The problem I have = with this text actually stems from the first
paragraph of the = section:

  The registration response message acknowledges = successful
  registration by including a RulesetInfo message for = each ruleset in
  which the registration is accepted.  If = the Database does not accept
  the registration for any of the = rulesets it supports, the Database
  MUST return the = NOT_REGISTERED error (See Error Codes
  (Section = 5.17)).

In reviewing this just now, I realized that I may have = completely
misinterpreted the second sentence.  It probably = means either:

 If the database does not accept the = registration for any single
 ruleset it supports, the database = MUST return the = NOT_REGISTERED
 error.

Or:

 If none of the = rulesets being registered are accepted by the
 database, the = database MUST return the NOT_REGISTERED error.

Right now, your = use of "any" could be interpreted either way.

And then, what I = was asking you to change in this DISCUSS item was this:

  = rulesetInfos:  A RulesetInfo (Section 5.6) list MUST be included = in
     the response.  Each entry corresponds to = a ruleset for which the
     registration was = accepted.  The list MUST contain at least one
    =  entry.   [If an error is being returned, this list MUST = be
     omitted.]

The text in brackets is what = I am proposing that you should add.
Otherwise you are giving the = implementor conflicting instructions--a
MUST is a MUST, and has to be = followed, but of course it can't be
followed if no rulesets match. =  I'm just asking you to make that
explicit so that nobody gets = confused.

Anyway, it sounds like we're converging.  Let me = know if what I'm
saying still doesn't make = sense.

--STATUS--

It looks like Vincent made the change he = suggested, but did not follow
up on what I said in my last response, = above (nobody replied to that
message).

I think this is an = open issue that should be addressed.

--Ted--
In 4.5:

      If = some
      locations within a batch request are = outside the regulatory
      domain supported by the = Database, the Database MAY return an OK
      response = with available spectrum for only the valid locations;
    =   otherwise, if all locations within a batch request are = outside
      the regulatory domain, the Database MUST = respond with an
      OUTSIDE_COVERAGE = error.

What should the database do if it doesn't follow the MAY? =   Should it
return an OUTSIDE_COVERAGE error?   It seems to = me that this MAY is going
to require some unclear heuristics on the = side of the master device.  
Why isn't this a MUST?   = I think if this were a MUST, it would be clear
how implementations = should behave; by making it a MAY, there's a big gap
that I think = will lead to interoperability problems as different
implementors make = different choices about how to treat this = situation.

--Vincent--
If it does not follow MAY, the = assumption is that it would return
OUTSIDE_COVERAGE error.  I = take your point about it being harder to
use for the device.

I = don't think there would be objections to changing this to a = MUST.

--Ted--

That would certainly satisfy my concern! =   :)

--STATUS--

The proposed change has not been made = to the document.

--Ted--
Section 3 describes = spectrum-usage messages as purely informational.  
Section = 4.5 says that the database can require that such messages be
sent. =   Which is it: is it sometimes required, or always = purely
informational?   Or does "purely informational" just mean = that the
protocol provides no mechanism for tracking such = notifications?  It would
be helpful if this were = clearer.

--Vincent--
"purely informational" means that the = it's just notifying the Database
what spectrum it intends to use and = is not a request to the Database
to get permission to use that = spectrum. Some regulators require this
notification.

I'll try = to clarify the text.

--Ted--
Ah, that explains it. =  Thanks.  Adding some text pretty much like what
you just = wrote would address this comment nicely.

--Vincent--
Will = do.

--STATUS--

Addressed in -15.

--Ted--
In 4.1, = the database URI change spec seems incomplete.   Is there a = time
when a database starts announcing its URI change after which it = need no
longer provide service on the old URI?   I see Alissa = asked a similar
question, so I imagine you could address both = questions together.

--Vincent--
Yes, specifying a time is = reasonable.

--STATUS--

Addressed in = -15.

--Ted--
In 4.1 and 5.17, the meaning described for = UNSUPPORTED appears to be
somewhat fluid.   I think you intend = for it to mean one specific thing,
which might imply one of several = other things.   But you don't say the
one thing that it means: = instead you mention possible implications.   It
would be helpful = to try to make this more explicit.

I think Stephen noticed this = same problem, but to be clear, it appears
that section 4.5 says that = when the master is sending a request on behalf
of a slave, it sends = its own location.   But section 4.5.1 says that the
master sends = the slave's location.   It appears that there are = two
parameters, one being the master location, which is required, and = the
other being the slave location, which is optional.   = However, this is
never really stated explicitly; it might be helpful = if it were.

--Vincent--
OK. UNSUPPORTED means that the = Database does not support the device
(based on it type, model, etc.) = or any rulesets indicated by the
Device. I'll update = both.

--STATUS--

Addressed in -15.

--Ted--
In = 4.6.1, it would help to have text that explains what it means = to
validate a device.   It's certainly not required for = interoperability,
but might be helpful for implementors of database = servers.

--Vincent--
This is explained in the first paragraph = of 4.6, I think.

   A Slave Device needs a Master = Device to ask the Database on its
   behalf for available = spectrum.  Depending on the ruleset, the Master
  =  Device also must validate with the Database that the Slave Device = is
   permitted to operate. ...

--Ted--
Ah, okay. =  The problem is that "validate the device" isn't = obviously
connected to "validate with the database that the ..." =  I see the
connection now, but it would help to make it = clearer.

--Vincent--

Will = do.

--STATUS--

Addressed in -15.

--Ted--
In 5.3, = it's a little puzzling that antenna direction, radiation = pattern,
gain and polarization aren't defined, because they seem like = properties
that should have universal applicability, even if they are = not required
in all cases.   Is this being left as future work, = or is there some more
subtle reason why these haven't been defined = explicitly?

--Vincent--
This is for future extension, rather = than defining a whole set of things that
won't get used. Note that = for mobile devices, direction/pattern/polarization
changes all the = time and would be "crazy" to define rules based on = these
characteristics. 

--Ted--
Right, just = checking.

--STATUS--

addressed

--Ted--

In 5.11, power is expressed in dbm, = which leads me to wonder if this is
the product of the antenna gain = and the input power to the output
amplifier, or whether it's just the = input power to the amplifier, or
whether it's being left = intentionally ambiguous.

--Vincent--
Great question.

I = believe this was left intentionally ambiguous, since each = regulator
may choose to define the power in a different way. = Typically, it's the
radiated power at the antenna, over some = bandwidth, averaged over some
period of time (defined by the = regulator).

Perhaps I should add the "Typically" statement to = Section 5.11 that
describes Spectrum.

--Ted--

The = problem with this is that if the meaning of the unit is = different
depending on the regulatory regime, it might make life = really
difficult for the maker of a device that has to operate in = different
regimes.  I suppose makers of devices like this are = used to this
problem, so maybe it's not really a problem in practice, = but it would
certainly be nice to talk a bit about this in the = document.

--Vincent--
I'll add it to the = doc.

--STATUS--

I don't see a change to the document to = address this point.


= --Apple-Mail=_2D25CF45-7C93-4894-B8F1-17D92E0F273E-- From nobody Tue Sep 2 22:27:30 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF2C1A8A13 for ; Tue, 2 Sep 2014 22:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGpIeaqNHdcd for ; Tue, 2 Sep 2014 22:27:17 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E141A8A1E for ; Tue, 2 Sep 2014 22:27:16 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id im17so8331320vcb.13 for ; Tue, 02 Sep 2014 22:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BGBci3X9ovHv7v5YKFkRqhGY1Px+PmIAl6UkLq/b0y0=; b=B93xdkWIxj4avsQ0C9KSngfe4thhEVzwfEJ0rp39fbzBqnwy/J1qOC6viJYHdEe72R Elhg1QbTHUsgW13eYmS9PYGcXUThOwb937YY7yRwKu7eNUnqakRJiTGFgBByyHlZVVny 3GoonA08lyw4JsRywSbp4lWlquqJCgJQJjeWPVkOrKUzdsNDBJwIFiblYzjEqyK1qMiO bcr7jgQZ32uIMWX6EB7RQtSxjo7IFirlbfck5r8digaSn9lFoqUIgFTlcrv9062zBnPi pObOCV4lwJX1GIHWP1qvOeH1A+IKXC8YEgacO1KYjgFbLk76GVv9x02Y8ABgvnqxqmhR I4hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BGBci3X9ovHv7v5YKFkRqhGY1Px+PmIAl6UkLq/b0y0=; b=OWWql/qko59vAnhNpbiBFVupw2IhnuqVeT8g9jqhjTnO6TvgsdMJQyaA+vl2xIpf8r Wf8VIw+KryKHRbicf5LWr+lnLU8bGxg/A2hmq213D1b/KvPpYRGXiTPDS11riMxO2fBN e10ob5oKMxmNdZC78Fgenp72C7N0jc9iVQmql7Zv+FdxT4puldYr5LVnjgokmHaok8iu fKxV5DrMgKFsYIIu30uihRR9Hn5E6p1rO3dd4dtx1sC99j7h0y6gBpU6k2hwhUCsks+Y yQWT2FzZAXe7KxeHfVkhD9HlnKr9MGCbdX1WQivUOuD08n14vty8B1sOtQD2stiGsA2e LuGQ== X-Gm-Message-State: ALoCoQn0VkDZH1DlyUho7+C7fh2+o9DBPQnE1Wt0979ElibgkxpG6zNy2/k4qeFIiUyMz/AWW+PL MIME-Version: 1.0 X-Received: by 10.52.170.211 with SMTP id ao19mr27985258vdc.23.1409722035504; Tue, 02 Sep 2014 22:27:15 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Tue, 2 Sep 2014 22:27:15 -0700 (PDT) In-Reply-To: <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> Date: Tue, 2 Sep 2014 22:27:15 -0700 Message-ID: From: Vincent Chen To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b86f58a28acb00502227dbc Archived-At: http://mailarchive.ietf.org/arch/msg/paws/hayGpTIPXdD_6_DjOouvnioeC80 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 05:27:21 -0000 --047d7b86f58a28acb00502227dbc Content-Type: text/plain; charset=UTF-8 Ted, Sorry, I did let one go unaddressed. Please see answers to the other discuss points (in blue). -vince On Tue, Sep 2, 2014 at 7:26 PM, Ted Lemon wrote: > Pete pinged me on this last Thursday, and I finally had time to go through > and check each of the points I raised to see if they had been addressed. > Most of them have been, but there are a few that remain (highlighted in > alternating colors; I'm keeping all the points here for my convenience, so > don't feel you need to look at anything but the colorful stuff.) > > --Ted-- > 4.1 says "Some regulatory domains may have specific rules regarding > how long the spectrum data remains valid in these cases." It might be > worth adding that in such cases the initialization procedure is > required. This is addressed to some extent in section 4.3, but I'm > not sure it's completely addressed. The potential problem I see is > that a device might be used in a regulatory regime where this is > required, but might have pre-configured values for some other > regulatory regime. If these values are not valid in the regime that > applies for its current location, it might have a too-long refresh > interval configured, fail to detect that this is the case, and as a > result accidentally break the law. Can a scenario like this occur in > practice? > > --Vincent-- > It should not occur in practice for well-behaved devices. > > When it is preconfigured, there must be a preconfigured value for each > ruleset. Of course, a device may choose to use preconfigured values > for only a subset of the rulesets it supports. > > Note that, in practice, a device needs to be certified for each > "ruleset" by whatever process is defined by each applicable regulatory > body, so that any preconfigured values will be certified to be > compliant. > > --Ted-- > > If this is how it works, shouldn't the document say so? Or was that > in the requirements document? I admit it's been a while since I read > it. :) > > --Vincent-- > > I'll clarify the text some. Note, however, that INIT_RESP return these > values as part of a RulesetInfo structure, so that it is implied that > preconfiguration also must be on a per-ruleset basis. > > --Ted-- > To be clear, what I was suggesting ought to be documented is that the > information has to be preconfigured and certified by the regulatory > authority. If this is already mentioned in the requirements document, > there's no need to mention it here, although a reference to the > previous document might be helpful for neophytes like me. I don't > really know what the mental context of a reader of this document would > be, so please forgive me if I'm being ridiculous here. > --Vincent-- I added clarification to section 4.3 that preconfiguration is on a per-ruleset basis and a value for one cannot be used for another. I believe that addressed your original concern. I did not add text about certification, since that's not PAWS, that's up to the regulatory domain to decide whether it needs to certify. > --STATUS-- > > Addressed in -14. > > --Ted-- > Section 5.2 says that the manufacturer ID and model ID are optional, > but may be required by some rulesets. Section 4.3.1 does not say what > error is returned when a deviceDesc that does not contain one or both > of these parameters is sent to the server, but the matching ruleset > requires either parameter. I suspect the answer is straightforward, > but I think it needs to be stated explicitly in 4.3.1. E.g., if the > optional but required parameters are accepted in the initialization > but rejected in the registration, it would be good to say so > explicitly. > > --Vincent-- > OK. In these cases, the Database should return the MISSING error, with > additional data specifying the missing fields. > > --STATUS-- > > There has been no change to the document that I can find that > addresses this point. > --Vincent-- End of Section 4 (before 4.1) has the following asa global statement: In some cases, specific rulesets may place additional requirements on message parameters. These additional requirements will be documented in the IANA PAWS Ruleset ID Registry. (Section 9.1). When a request message sent to the Database has missing parameters, whether they are required by PAWS or the applicable ruleset, the Database returns the MISSING (Section 5.17.3) error, along with data indicating the missing parameters. > --Ted-- > In 4.4.2, I think that if none of the rulesets are accepted, the intent > is that the database should return a REGISTRATION_RESP with the error > element, and will not return a rulesetInfos list. However, the > specification does not make an exception for this case when it says "A > RulesetInfo list MUST be included" and "The list MUST contain at least > one entry". I can't think of another valid interpretation, but you've > stated a MUST, so you need to say that it doesn't apply in the case of > the error. > > --Vincent-- > Ah, right. There is language from INIT_RESP that needs to be repeated here. > > --Ted-- > > The problem I have with this text actually stems from the first > paragraph of the section: > > The registration response message acknowledges successful > registration by including a RulesetInfo message for each ruleset in > which the registration is accepted. If the Database does not accept > the registration for any of the rulesets it supports, the Database > MUST return the NOT_REGISTERED error (See Error Codes > (Section 5.17)). > > In reviewing this just now, I realized that I may have completely > misinterpreted the second sentence. It probably means either: > > If the database does not accept the registration for any single > ruleset it supports, the database MUST return the NOT_REGISTERED > error. > > Or: > > If none of the rulesets being registered are accepted by the > database, the database MUST return the NOT_REGISTERED error. > > Right now, your use of "any" could be interpreted either way. > --Vincent-- This was a change recently, because my original wording using "none" was deemed confusing. I'll try your wording. > > And then, what I was asking you to change in this DISCUSS item was this: > > rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in > the response. Each entry corresponds to a ruleset for which the > registration was accepted. The list MUST contain at least one > entry. [If an error is being returned, this list MUST be > omitted.] > > The text in brackets is what I am proposing that you should add. > Otherwise you are giving the implementor conflicting instructions--a > MUST is a MUST, and has to be followed, but of course it can't be > followed if no rulesets match. I'm just asking you to make that > explicit so that nobody gets confused. > > Anyway, it sounds like we're converging. Let me know if what I'm > saying still doesn't make sense. > > --STATUS-- > > It looks like Vincent made the change he suggested, but did not follow > up on what I said in my last response, above (nobody replied to that > message). > > I think this is an open issue that should be addressed. > --Vincent-- The issue is that this message is not used when there is an error. This message is returned only when there is no error, so, by definition, there must be at least one entry in the message. I've added the following, where "instead" is supposed to indicate that it's a different message that is returned when there is an error: If the Database does not support the device or any of the rulesets specified in the DeviceDescriptor, it MUST instead return an error with the UNSUPPORTED (Table 1) code in the error response. > > --Ted-- > In 4.5: > > If some > locations within a batch request are outside the regulatory > domain supported by the Database, the Database MAY return an OK > response with available spectrum for only the valid locations; > otherwise, if all locations within a batch request are outside > the regulatory domain, the Database MUST respond with an > OUTSIDE_COVERAGE error. > > What should the database do if it doesn't follow the MAY? Should it > return an OUTSIDE_COVERAGE error? It seems to me that this MAY is going > to require some unclear heuristics on the side of the master device. > Why isn't this a MUST? I think if this were a MUST, it would be clear > how implementations should behave; by making it a MAY, there's a big gap > that I think will lead to interoperability problems as different > implementors make different choices about how to treat this situation. > > --Vincent-- > If it does not follow MAY, the assumption is that it would return > OUTSIDE_COVERAGE error. I take your point about it being harder to > use for the device. > > I don't think there would be objections to changing this to a MUST. > > --Ted-- > > That would certainly satisfy my concern! :) > > --STATUS-- > > The proposed change has not been made to the document. > --Vincent-- Sorry. I let this slip. Modifying to: ...If some*, but not all,* locations within a batch request are outside the regulatory domain supported by the Database, the Database *MUST* return an OK response with available spectrum for only the valid locations; > > > --Ted-- > Section 3 describes spectrum-usage messages as purely informational. > Section 4.5 says that the database can require that such messages be > sent. Which is it: is it sometimes required, or always purely > informational? Or does "purely informational" just mean that the > protocol provides no mechanism for tracking such notifications? It would > be helpful if this were clearer. > > --Vincent-- > "purely informational" means that the it's just notifying the Database > what spectrum it intends to use and is not a request to the Database > to get permission to use that spectrum. Some regulators require this > notification. > > I'll try to clarify the text. > > --Ted-- > Ah, that explains it. Thanks. Adding some text pretty much like what > you just wrote would address this comment nicely. > > --Vincent-- > Will do. > > --STATUS-- > > Addressed in -15. > > --Ted-- > In 4.1, the database URI change spec seems incomplete. Is there a time > when a database starts announcing its URI change after which it need no > longer provide service on the old URI? I see Alissa asked a similar > question, so I imagine you could address both questions together. > > --Vincent-- > Yes, specifying a time is reasonable. > > --STATUS-- > > Addressed in -15. > > --Ted-- > In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be > somewhat fluid. I think you intend for it to mean one specific thing, > which might imply one of several other things. But you don't say the > one thing that it means: instead you mention possible implications. It > would be helpful to try to make this more explicit. > > I think Stephen noticed this same problem, but to be clear, it appears > that section 4.5 says that when the master is sending a request on behalf > of a slave, it sends its own location. But section 4.5.1 says that the > master sends the slave's location. It appears that there are two > parameters, one being the master location, which is required, and the > other being the slave location, which is optional. However, this is > never really stated explicitly; it might be helpful if it were. > > --Vincent-- > OK. UNSUPPORTED means that the Database does not support the device > (based on it type, model, etc.) or any rulesets indicated by the > Device. I'll update both. > > --STATUS-- > > Addressed in -15. > > --Ted-- > In 4.6.1, it would help to have text that explains what it means to > validate a device. It's certainly not required for interoperability, > but might be helpful for implementors of database servers. > > --Vincent-- > This is explained in the first paragraph of 4.6, I think. > > A Slave Device needs a Master Device to ask the Database on its > behalf for available spectrum. Depending on the ruleset, the Master > Device also must validate with the Database that the Slave Device is > permitted to operate. ... > > --Ted-- > Ah, okay. The problem is that "validate the device" isn't obviously > connected to "validate with the database that the ..." I see the > connection now, but it would help to make it clearer. > > --Vincent-- > > Will do. > > --STATUS-- > > Addressed in -15. > > --Ted-- > In 5.3, it's a little puzzling that antenna direction, radiation pattern, > gain and polarization aren't defined, because they seem like properties > that should have universal applicability, even if they are not required > in all cases. Is this being left as future work, or is there some more > subtle reason why these haven't been defined explicitly? > > --Vincent-- > This is for future extension, rather than defining a whole set of things > that > won't get used. Note that for mobile devices, > direction/pattern/polarization > changes all the time and would be "crazy" to define rules based on these > characteristics. > > --Ted-- > Right, just checking. > > --STATUS-- > > addressed > > --Ted-- > > In 5.11, power is expressed in dbm, which leads me to wonder if this is > the product of the antenna gain and the input power to the output > amplifier, or whether it's just the input power to the amplifier, or > whether it's being left intentionally ambiguous. > > --Vincent-- > Great question. > > I believe this was left intentionally ambiguous, since each regulator > may choose to define the power in a different way. Typically, it's the > radiated power at the antenna, over some bandwidth, averaged over some > period of time (defined by the regulator). > > Perhaps I should add the "Typically" statement to Section 5.11 that > describes Spectrum. > > --Ted-- > > The problem with this is that if the meaning of the unit is different > depending on the regulatory regime, it might make life really > difficult for the maker of a device that has to operate in different > regimes. I suppose makers of devices like this are used to this > problem, so maybe it's not really a problem in practice, but it would > certainly be nice to talk a bit about this in the document. > > --Vincent-- > I'll add it to the doc. > > --STATUS-- > > I don't see a change to the document to address this point. > > > --Vincent-- Added the following text to Section 4.5.2 as a "global" statement: o Each spectrum schedule specifies permissible power level for a duration defined by a pair of start and stop times. The power levels typically refer to permissible EIRP over a resolution bandwidth. --047d7b86f58a28acb00502227dbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,

Sorry, I did let one go unaddresse= d. Please see answers to the other discuss points (in blue).

=
-vince


On Tue, Sep 2, 2014 at 7:26 PM, Ted Lemon <<= a href=3D"mailto:Ted.Lemon@nominum.com" target=3D"_blank">Ted.Lemon@nominum= .com> wrote:
Pete pinged me on this last Thursday, and I finally had time to go = through and check each of the points I raised to see if they had been addre= ssed. =C2=A0 Most of them have been, but there are a few that remain (highl= ighted in alternating colors; I'm keeping all the points here for my co= nvenience, so don't feel you need to look at anything but the colorful = stuff.)

--Ted--
4.1 says "Some = regulatory domains may have specific rules regarding
how long the spectr= um data remains valid in these cases." =C2=A0It might be
worth addi= ng that in such cases the initialization procedure is
required. =C2=A0Th= is is addressed to some extent in section 4.3, but I'm
not sure it&#= 39;s completely addressed. =C2=A0The potential problem I see is
that a d= evice might be used in a regulatory regime where this is
required, but m= ight have pre-configured values for some other
regulatory regime. =C2=A0= If these values are not valid in the regime that
applies for its current= location, it might have a too-long refresh
interval configured, fail to= detect that this is the case, and as a
result accidentally break the la= w. =C2=A0Can a scenario like this occur in
practice?

--Vin= cent--
It should not occur in practice for well-behaved= devices.

When it is preconfigured, there must be a preconfigured va= lue for each
ruleset. =C2=A0Of course, a device may choose to use precon= figured values
for only a subset of the rulesets it supports.

Not= e that, in practice, a device needs to be certified for each
"rules= et" by whatever process is defined by each applicable regulatory
bo= dy, so that any preconfigured values will be certified to be
compliant.<= br>
--Ted--

If this is how it works, shou= ldn't the document say so? =C2=A0Or was that
in the requirements doc= ument? =C2=A0I admit it's been a while since I read
it. :)

--Vincent--

I'll clarify the text some. No= te, however, that INIT_RESP return these
values as part of a RulesetInfo= structure, so that it is implied that
preconfiguration also must be on = a per-ruleset basis.

--Ted--
To be clear,= what I was suggesting ought to be documented is that the
information ha= s to be preconfigured and certified by the regulatory
authority. =C2=A0I= f this is already mentioned in the requirements document,
there's no= need to mention it here, although a reference to the
previous document = might be helpful for neophytes like me. =C2=A0I don't
really know wh= at the mental context of a reader of this document would
be, so please f= orgive me if I'm being ridiculous here.

--Vincent--
I added clarification to section 4.3 that preconf= iguration is on a per-ruleset
basi= s and a value for one cannot be used for another. I believe that addressed<= /font>
your original concern.

I did not add text about=C2=A0ce= rtification, since that's not PAWS, that's up to the
regulatory domain to decide whether i= t needs to certify.

--STATUS--

Addressed in -14.

--Ted--
Section 5.2 says that the manu= facturer ID and model ID are optional,
but may be required by some rules= ets. =C2=A0Section 4.3.1 does not say what
error is returned when a devi= ceDesc that does not contain one or both
of these parameters is sent to = the server, but the matching ruleset
requires either parameter. =C2=A0I = suspect the answer is straightforward,
but I think it needs to be stated= explicitly in 4.3.1. =C2=A0E.g., if the
optional but required parameter= s are accepted in the initialization
but rejected in the registration, i= t would be good to say so
explicitly.

--Vincent--
OK. In these cases, the Database should return the MISSING erro= r, with
additional data specifying the missing fields.

--S= TATUS--

There has been no change to the document that I can find tha= t
addresses this point.

--Vincent--
End of Section 4 (before 4.1) has the following asa global stateme= nt:

=C2=A0 =C2=A0In some cases, specific rulesets may place add= itional requirements on
=C2=A0 =C2= =A0message parameters. =C2=A0These additional requirements will be document= ed
=C2=A0 =C2=A0in the IANA PAWS R= uleset ID Registry. =C2=A0(Section 9.1). =C2=A0When a request
<= div>=C2=A0 =C2=A0message sent to the Database has m= issing parameters, whether they are
=C2=A0 =C2=A0required by PAWS or the applicable ruleset, the Database ret= urns the
=C2=A0 =C2=A0MISSING (Sec= tion 5.17.3) error, along with data indicating the
=C2=A0 =C2=A0missing parameters.=C2=A0



--Ted-= -
In 4.4.2, I think that if none of the rulesets are ac= cepted, the intent
is that the database should return a REGISTRATION_RES= P with the error
element, and will not return a rulesetInfos list. =C2= =A0 However, the
specification does not make an exception for this case = when it says "A
RulesetInfo list MUST be included" and =C2=A0&= quot;The list MUST contain at least
one entry". =C2=A0 I can't = think of another valid interpretation, but you've
stated a MUST, so = you need to say that it doesn't apply in the case of
the error.
<= br>--Vincent--
Ah, right. There is language from= INIT_RESP that needs to be repeated here.

--Ted--

The problem I have with this text actually stems from the f= irst
paragraph of the section:

=C2=A0 The registration response m= essage acknowledges successful
=C2=A0 registration by including a Rulese= tInfo message for each ruleset in
=C2=A0 which the registration is accep= ted. =C2=A0If the Database does not accept
=C2=A0 the registration for a= ny of the rulesets it supports, the Database
=C2=A0 MUST return the NOT_= REGISTERED error (See Error Codes
=C2=A0 (Section 5.17)).

In revi= ewing this just now, I realized that I may have completely
misinterprete= d the second sentence. =C2=A0It probably means either:

=C2=A0If the = database does not accept the registration for any single
=C2=A0ruleset i= t supports, the database MUST return the NOT_REGISTERED
=C2=A0error.
=
Or:

=C2=A0If none of the rulesets being registered are accepted = by the
=C2=A0database, the database MUST return the NOT_REGISTERED error= .

Right now, your use of "any" could be interpreted either= way.

--Vincent--
= This was a change recently, because my original wording using "none&qu= ot; was deemed
confusing. I'll= try your wording.
=C2=A0

And then, what I was asking you to change in this DISCUSS item was t= his:

=C2=A0 rulesetInfos: =C2=A0A RulesetInfo (Section 5.6) list MUS= T be included in
=C2=A0 =C2=A0 =C2=A0the response. =C2=A0Each entry corr= esponds to a ruleset for which the
=C2=A0 =C2=A0 =C2=A0registration was = accepted. =C2=A0The list MUST contain at least one
=C2=A0 =C2=A0 =C2=A0e= ntry. =C2=A0 [If an error is being returned, this list MUST be
=C2=A0 = =C2=A0 =C2=A0omitted.]

The text in brackets is what I am proposing t= hat you should add.
Otherwise you are giving the implementor conflicting= instructions--a
MUST is a MUST, and has to be followed, but of course i= t can't be
followed if no rulesets match. =C2=A0I'm just asking = you to make that
explicit so that nobody gets confused.

Anyway, i= t sounds like we're converging. =C2=A0Let me know if what I'm
sa= ying still doesn't make sense.

--STATUS--

It = looks like Vincent made the change he suggested, but did not follow
up o= n what I said in my last response, above (nobody replied to that
message= ).

I think this is an open issue that should be addressed.

--Vin= cent--
The issue is that this mess= age is not used when there is an error. This message
is returned only when there is no error, so, by definiti= on, there must be at least
one ent= ry in the message.

I've added the following, where "in= stead" is supposed to indicate that
it's a different message that is returned when there is an error= :

=C2=A0 =C2=A0 =C2=A0 If the Database does not support th= e device or any of the rulesets
= =C2=A0 =C2=A0 =C2=A0 specified in the DeviceDescriptor, it MUST instead ret= urn an error
=C2=A0 =C2=A0 =C2=A0 = with the UNSUPPORTED (Table 1) code in the error response.

=C2=A0

--Ted--
In 4.5:

=C2=A0 =C2=A0 =C2=A0 If some<= br>=C2=A0 =C2=A0 =C2=A0 locations within a batch request are outside the re= gulatory
=C2=A0 =C2=A0 =C2=A0 domain supported by the Database, the Data= base MAY return an OK
=C2=A0 =C2=A0 =C2=A0 response with available spect= rum for only the valid locations;
=C2=A0 =C2=A0 =C2=A0 otherwise, if all= locations within a batch request are outside
=C2=A0 =C2=A0 =C2=A0 the r= egulatory domain, the Database MUST respond with an
=C2=A0 =C2=A0 =C2=A0= OUTSIDE_COVERAGE error.

What should the database do if it doesn'= ;t follow the MAY? =C2=A0 Should it
return an OUTSIDE_COVERAGE error? = =C2=A0 It seems to me that this MAY is going
to require some unclear heu= ristics on the side of the master device.=C2=A0=C2=A0
Why isn't this= a MUST? =C2=A0 I think if this were a MUST, it would be clear
how imple= mentations should behave; by making it a MAY, there's a big gap
that= I think will lead to interoperability problems as different
implementor= s make different choices about how to treat this situation.

-= -Vincent--
If it does not follow MAY, the assumption is= that it would return
OUTSIDE_COVERAGE error. =C2=A0I take your point ab= out it being harder to
use for the device.

I don't think ther= e would be objections to changing this to a MUST.

--Ted--

That would certainly satisfy my concern! =C2=A0 :)
=
--STATUS--

The proposed change has not been made to the d= ocument.

--Vincent--
Sorry. I let = this slip. Modifying to:

=C2=A0 =C2=A0 =C2=A0 =C2=A0...If = some, but not all,=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0locati= ons within a batch request are outside the regulatory
=C2=A0 =C2= =A0 =C2=A0 =C2=A0domain supported by the Database, the Database MUST= return an OK
=C2=A0 =C2=A0 =C2=A0 =C2=A0response with available = spectrum for only the valid locations;
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">


--Ted--
Section 3 describes spectrum-usage messages as purely inf= ormational.=C2=A0=C2=A0
Section 4.5 says that the database can require t= hat such messages be
sent. =C2=A0 Which is it: is it sometimes required,= or always purely
informational? =C2=A0 Or does "purely information= al" just mean that the
protocol provides no mechanism for tracking = such notifications? =C2=A0It would
be helpful if this were clearer.
<= br>--Vincent--
"purely informational" = means that the it's just notifying the Database
what spectrum it int= ends to use and is not a request to the Database
to get permission to us= e that spectrum. Some regulators require this
notification.

I'= ;ll try to clarify the text.

--Ted--
Ah, = that explains it. =C2=A0Thanks. =C2=A0Adding some text pretty much like wha= t
you just wrote would address this comment nicely.

--Vinc= ent--
Will do.

--STATUS--

Addressed in -15.

--Ted--=
In 4.1, the database URI change spec seems incomplete.= =C2=A0 Is there a time
when a database starts announcing its URI change= after which it need no
longer provide service on the old URI? =C2=A0 I = see Alissa asked a similar
question, so I imagine you could address both= questions together.

--Vincent--
Yes, spe= cifying a time is reasonable.

--STATUS--

Addressed in = -15.

--Ted--
In 4.1 and 5.17, the meaning descri= bed for UNSUPPORTED appears to be
somewhat fluid. =C2=A0 I think you int= end for it to mean one specific thing,
which might imply one of several = other things. =C2=A0 But you don't say the
one thing that it means: = instead you mention possible implications. =C2=A0 It
would be helpful to= try to make this more explicit.

I think Ste= phen noticed this same problem, but to be clear, it appears
that section= 4.5 says that when the master is sending a request on behalf
of a slave= , it sends its own location. =C2=A0 But section 4.5.1 says that the
mast= er sends the slave's location. =C2=A0 It appears that there are two
= parameters, one being the master location, which is required, and the
ot= her being the slave location, which is optional. =C2=A0 However, this isnever really stated explicitly; it might be helpful if it were.

--Vincent--
OK. UNSUPPORTED means that the Database does not support= the device
(based on it type, model, etc.) or any rule= sets indicated by the
Device. I'll update both.

--STAT= US--

Addressed in -15.

--Ted--
In 4.6.1, = it would help to have text that explains what it means to
validate a dev= ice. =C2=A0 It's certainly not required for interoperability,
but mi= ght be helpful for implementors of database servers.

--Vincen= t--
This is explained in the first paragraph of 4.6, I = think.

=C2=A0 =C2=A0A Slave Device needs a Master Device to ask the = Database on its
=C2=A0 =C2=A0behalf for available spectrum. =C2=A0Depend= ing on the ruleset, the Master
=C2=A0 =C2=A0Device also must validate wi= th the Database that the Slave Device is
=C2=A0 =C2=A0permitted to opera= te. ...

--Ted--
Ah, okay. =C2=A0The probl= em is that "validate the device" isn't obviously
connected= to "validate with the database that the ..." =C2=A0I see the
= connection now, but it would help to make it clearer.

--Vince= nt--

Will do.

--STATUS--

Addressed in -15.

--Te= d--
In 5.3, it's a little puzzling that antenna dir= ection, radiation pattern,
gain and polarization aren't defined, bec= ause they seem like properties
that should have universal applicability,= even if they are not required
in all cases. =C2=A0 Is this being left a= s future work, or is there some more
subtle reason why these haven't= been defined explicitly?

--Vincent--
Thi= s is for future extension, rather than defining a whole set of things that<= br>won't get used. Note that for mobile devices, direction/pattern/pola= rization
changes all the time and would be "crazy" to define r= ules based on these
characteristics.=C2=A0

--Ted--
Righ= t, just checking.

--STATUS--

addressed

--Ted--

In 5.11, power is expressed in dbm= , which leads me to wonder if this is
the product of the antenna gain an= d the input power to the output
amplifier, or whether it's just the = input power to the amplifier, or
whether it's being left intentional= ly ambiguous.

--Vincent--
Great question.=

I believe this was left intentionally ambiguous, since each regulat= or
may choose to define the power in a different way. Typically, it'= s the
radiated power at the antenna, over some bandwidth, averaged over = some
period of time (defined by the regulator).

Perhaps I should = add the "Typically" statement to Section 5.11 that
describes S= pectrum.

--Ted--

The problem with thi= s is that if the meaning of the unit is different
depending on the regul= atory regime, it might make life really
difficult for the maker of a dev= ice that has to operate in different
regimes. =C2=A0I suppose makers of = devices like this are used to this
problem, so maybe it's not really= a problem in practice, but it would
certainly be nice to talk a bit abo= ut this in the document.

--Vincent--
I= 9;ll add it to the doc.

--STATUS--

I don't see a c= hange to the document to address this point.


=
--Vincent--
Added the following text to Section 4.5.2 as a "gl= obal" statement:

<= /div>
=C2=A0 =C2=A0o =C2=A0Each spectrum s= chedule specifies permissible power level for a
=C2=A0 =C2=A0 =C2=A0 duration defined by a pair of start and = stop times. =C2=A0The power
=C2=A0= =C2=A0 =C2=A0 levels typically refer to permissible EIRP over a resolution=
=C2=A0 =C2=A0 =C2=A0 bandwidth.

=C2=A0

--047d7b86f58a28acb00502227dbc-- From nobody Thu Sep 4 09:24:39 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D461A0380; Thu, 4 Sep 2014 09:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn0o2fQJnMVo; Thu, 4 Sep 2014 09:24:37 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C621A034A; Thu, 4 Sep 2014 09:24:37 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 149D71B8915; Thu, 4 Sep 2014 09:24:37 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B959353E074; Thu, 4 Sep 2014 09:24:36 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Sep 2014 09:24:36 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 4 Sep 2014 12:23:32 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> To: Vincent Chen X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/5TuA8juWgbLlwkl-krLHgvf95zI Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 16:24:38 -0000 On Sep 3, 2014, at 1:27 AM, Vincent Chen wrote: > If the Database does not support the device or any of the = rulesets > specified in the DeviceDescriptor, it MUST instead return an = error > with the UNSUPPORTED (Table 1) code in the error response. Okay, thanks. Unfortunately "any" here is ambiguous as with the = previous use. You should either say "supports none of the rulesets" or = "does not support one or more of the rulesets" depending on which you = mean. The other points appear either to have been addressed, or else you've = proposed to address them in the next version, so please go ahead and = spin that when the time is right and I will re-check. Thanks! From nobody Fri Sep 5 09:25:54 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FE21A0ADC for ; Fri, 5 Sep 2014 09:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9NisaExGqJm for ; Fri, 5 Sep 2014 09:25:46 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334031A0AD9 for ; Fri, 5 Sep 2014 09:25:46 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hq11so12807617vcb.0 for ; Fri, 05 Sep 2014 09:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y7woCeLeEDrS1VHhSLy2Cnn9IAbHrO1vYeJk/gFLSvg=; b=W6/wpenVC9ZQYfcRk4ZZNeECu6F7+NavTwre6+khxcXUW86K0C5omgAAS+6Ed+NJNh K0ff6mHOdtYPs1rYSo+yOmuaHxq/aKbKCVFL3xIR8BcumAYe2maXVb11xTvTtwQwYHtF zLzh/TA7kFcuFSRdEQiGJ0PUZAfkV5yJe4FjHgV0AwchLvSJE20MqI6i5jp7j11OnrbM f0aGnaIwMnIkURCX7PXP4+WJxfupaH8ssVUNRbENA+61OMjoSHZ6hoCH9PcLMPTXz7uD O11Mb4FF8fsYHR+R1RBk+xNiZ8vmFS0T9mjSbxvDI6SUVVCp3BfnDQUorGi+IaT4CA8v bicA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y7woCeLeEDrS1VHhSLy2Cnn9IAbHrO1vYeJk/gFLSvg=; b=lQ4SoFPBcB6aU6ia/nkEysz5/A0YTOMP5PQUOSo4DkP0s7zD2K3belhT+fTBRefmAc 7eTbc5IBr4J6tMzB2q2f6rkpNqcA9zhHdhkSmOfpb+DOxuI3ebXFWo3oFubDQ6KOD9tN YHw96TihgJulsiMJhD4YKQzwdHmf4uOulrXx1Yry9NijP1Sn4m2nyzD7100lhqYzsHY7 KiCoXui7CyGQ9Vxl1XuXT09XI5NwfT50H29RcJWRR1uvBEtFCDy4tz/ahBrTqiuoAwDY f1IUzt/CPN2QkW81O9+hZMp/OczZq3610vdDC8FqRVaKVupFrGnNtxF2avPON4vTl7Pi +ksA== X-Gm-Message-State: ALoCoQmLGfKeySVRIEzYMG4lCdWbJ018CveIG/09sV4Ad37lgwgyD6jDHwrIYRWKMcLKNo5fqIW5 MIME-Version: 1.0 X-Received: by 10.221.64.142 with SMTP id xi14mr2905215vcb.31.1409934345233; Fri, 05 Sep 2014 09:25:45 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Fri, 5 Sep 2014 09:25:45 -0700 (PDT) In-Reply-To: <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> Date: Fri, 5 Sep 2014 09:25:45 -0700 Message-ID: From: Vincent Chen To: Ted Lemon Content-Type: multipart/alternative; boundary=001a113312a6ce0273050253eb74 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/qYNheiHIzWHutGu7OqmBit2JEsI Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 16:25:47 -0000 --001a113312a6ce0273050253eb74 Content-Type: text/plain; charset=UTF-8 Ted, Agreed. I'll upload new version shortly. -vince On Thu, Sep 4, 2014 at 9:23 AM, Ted Lemon wrote: > On Sep 3, 2014, at 1:27 AM, Vincent Chen wrote: > > If the Database does not support the device or any of the rulesets > > specified in the DeviceDescriptor, it MUST instead return an error > > with the UNSUPPORTED (Table 1) code in the error response. > > Okay, thanks. Unfortunately "any" here is ambiguous as with the previous > use. You should either say "supports none of the rulesets" or "does not > support one or more of the rulesets" depending on which you mean. > > The other points appear either to have been addressed, or else you've > proposed to address them in the next version, so please go ahead and spin > that when the time is right and I will re-check. > > Thanks! > > -- -vince --001a113312a6ce0273050253eb74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,

Agreed. I'll upload new versio= n shortly.

-vince


On Thu, Sep 4, 2014 at 9:23 AM, Te= d Lemon <Ted.Lemon@nominum.com> wrote:
On Sep 3, 2014, at 1:27 AM, Vincent Chen = <vchen@google.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If the Database does not support the device = or any of the rulesets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0specified in the DeviceDescriptor, it MUST i= nstead return an error
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the UNSUPPORTED (Table 1) code in the e= rror response.

Okay, thanks.=C2=A0 =C2=A0Unfortunately "any" here is ambi= guous as with the previous use.=C2=A0 =C2=A0You should either say "sup= ports none of the rulesets" or "does not support one or more of t= he rulesets" depending on which you mean.

The other points appear either to have been addressed, or else you've p= roposed to address them in the next version, so please go ahead and spin th= at when the time is right and I will re-check.

Thanks!




--
-vince
--001a113312a6ce0273050253eb74-- From nobody Fri Sep 5 13:16:52 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE0E1A01D8; Fri, 5 Sep 2014 13:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaKoxskFj_Rv; Fri, 5 Sep 2014 13:16:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B401A0118; Fri, 5 Sep 2014 13:16:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140905201644.1609.55430.idtracker@ietfa.amsl.com> Date: Fri, 05 Sep 2014 13:16:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/pcY2mD5FbT1CO8AstWekpCazNgY Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-16.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 20:16:46 -0000 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) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-16.txt Pages : 91 Date : 2014-09-05 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 managing 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 (PAWS) Databases". 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 5 13:16:54 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAC31A0243 for ; Fri, 5 Sep 2014 13:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ8wdzfG_Pmz; Fri, 5 Sep 2014 13:16:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4611A010A; Fri, 5 Sep 2014 13:16:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org, paws@ietf.org, presnick@qti.qualcomm.com, ted.lemon@nominum.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140905201644.1609.35241.idtracker@ietfa.amsl.com> Date: Fri, 05 Sep 2014 13:16:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/pkSTr5pVZb4yP-vDqyW0iRyAobE Subject: [paws] New Version Notification - draft-ietf-paws-protocol-16.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 20:16:48 -0000 A new version (-16) has been submitted for draft-ietf-paws-protocol: http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-16.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Sep 5 13:22:12 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B961A0118 for ; Fri, 5 Sep 2014 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtGgNwXE0jYK for ; Fri, 5 Sep 2014 13:22:09 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FE31A00DC for ; Fri, 5 Sep 2014 13:22:09 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id im17so12788039vcb.41 for ; Fri, 05 Sep 2014 13:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wC2J3g4hH4tKGgl9/gq9BykJxTOZhy3OgxjJl0Fynoc=; b=gCSXQ+JoWPxp1Nak8QzJXXL/0MqB9Y/2SmQ+BGAecsw5pDF0r/X6rPobqMSrBIoCJ9 H8a7s9yi+sSKFWPu1iPxeLF8m3cZRKc54zM9kJr4+W7mtWWOIQ10AxvNxx4qgVaVvhDF Tb627m64UcU4uFs5od4BFT3opbP2ts8Pnh/luFz5ozNWi5Q+ebRpCZDBnAiIANX2u5ZY 9TFc4shxubjrt0aHxzygmWPnsJhm/fz96nH+zI0t/hshl+jrufAytlvl/NcHObCphP8x fSQG95xTEncWsTl9tPIiCsa3R6Nemcfv11IU1RAKWZkGnu5b9c+KcUZzrplvQJsagrL+ CR2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wC2J3g4hH4tKGgl9/gq9BykJxTOZhy3OgxjJl0Fynoc=; b=WsJGKP3uXpgvDQ6STdnrYFziv+VqxOVeg6B/D7f1eSOkaZ+NgDzaz01wvP3lfFB0cw ZZWu4aP+CVNVa4Yl+KOezegzO/cfP3TYeppfyJSxNBmO3m73Sd81zqzrOIpeweN3JauR M8r2JrlS35vEa6ZgLlQxxIg2N+t3ZDecaBQ91nUECgzpCLSdjR5G5erQArjJBfGENCaC UxhSOKLCp21Y6t3rHzlfr8qU7WwEzp0xFjxzK71TDhGmURSeWCjUwGdu9QLyC58NJZf4 lXjMW8T9KSCEgHjBBKGRD0v533SydfBzUo9HcVLXXn6PRMRzvcVoS1gS2IYvt9c4bZ3j FQMQ== X-Gm-Message-State: ALoCoQmvC/Idskbvc3Ieg/C7XycW9p3636PvXsJq4LHbCZ7AB7nHsFVV6vVK1sW9hdGRSKFDTuSy MIME-Version: 1.0 X-Received: by 10.220.74.195 with SMTP id v3mr10769893vcj.23.1409948528532; Fri, 05 Sep 2014 13:22:08 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Fri, 5 Sep 2014 13:22:08 -0700 (PDT) In-Reply-To: <20140905201644.1609.35241.idtracker@ietfa.amsl.com> References: <20140905201644.1609.35241.idtracker@ietfa.amsl.com> Date: Fri, 5 Sep 2014 13:22:08 -0700 Message-ID: From: Vincent Chen To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=089e01634bf031fce405025739ee Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ghgVSHH5MEv-NMdd_xGvVR3Dcxc Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , "paws@ietf.org" , Ted Lemon , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] New Version Notification - draft-ietf-paws-protocol-16.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 20:22:11 -0000 --089e01634bf031fce405025739ee Content-Type: text/plain; charset=UTF-8 All, Summary of changes: o More precise language: "supports none of the ruleset" instead of "does not support any ruleset", where it makes sense. o Batch request: Change MAY to MUST when some locations are acceptable o Remove explicit mention of OCSP and leave it up the the TLS best practices draft o Define power levels as EIRP for consistency Thanks! -vince On Fri, Sep 5, 2014 at 1:16 PM, wrote: > > A new version (-16) has been submitted for draft-ietf-paws-protocol: > http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-16.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-16 > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > IETF Secretariat. > > -- -vince --089e01634bf031fce405025739ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Summary of changes:

=
=C2=A0 =C2=A0o =C2=A0More precise language: "supports = none of the ruleset" instead of
=C2=A0 =C2=A0 =C2=A0 "d= oes not support any ruleset", where it makes sense.

=C2=A0 =C2=A0o =C2=A0Batch request: Change MAY to MUST when some loc= ations are
=C2=A0 =C2=A0 =C2=A0 acceptable

=C2=A0 =C2=A0o =C2=A0Remove explicit mention of OCSP and leave it up the= the TLS best
=C2=A0 =C2=A0 =C2=A0 practices draft

=
=C2=A0 =C2=A0o =C2=A0Define power levels as EIRP for consistency=

Thanks!

-vince

On Fri, S= ep 5, 2014 at 1:16 PM, <internet-drafts@ietf.org> wr= ote:

A new version (-16) has been submitted for draft-ietf-paws-protocol:
http://www.ietf.org/internet-drafts/draft-ietf-paws-= protocol-16.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-16

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.




--
-vince
--089e01634bf031fce405025739ee-- From nobody Fri Sep 5 13:23:12 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4981A00DC for ; Fri, 5 Sep 2014 13:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w73g1TlTUkOZ for ; Fri, 5 Sep 2014 13:23:09 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE301A00B8 for ; Fri, 5 Sep 2014 13:23:08 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hq11so13178491vcb.28 for ; Fri, 05 Sep 2014 13:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cc/p9995bnm4w/SJGxmeKfjLzmnSYMh4lswXb99dlNc=; b=PEykjYYlpR+QHOClXWapaijJDuylC6CrPogXp3cmIlWQlCc/2WnF1tYjjMRjhpmM+V jdiN34W8qVlupJpABeKvdlxZF1JQ4Mb93Yw/2o2zfpm60UKB2CMwgciYD+KXvdDwSWfk dGpVQvjC12mSBVWe6xt0gl+0l+n3iR+k9Wd/fCm2M6y11hzlrfgnRgWRzZBv7uIQwoME nV5RWBp8tIfZaF277+qnaqtKFNNmOXwmA2Vtq88l08lhqAWlsluUTyEspFvWYemDM1az qqjztm5DMjx17k7nTgE1VRlfdGQsawtKGtJil0D4trPfLPYeW/lZEuuqARiN3rYwb2dq hqbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cc/p9995bnm4w/SJGxmeKfjLzmnSYMh4lswXb99dlNc=; b=kJk5huBTtsPVAMpSWVEEGSuPvPFsGBsMnHUhKktepnt8wlsey7kvMog2+CLSQSQV+C j0JDjK9OdDrXikQCILOb++SGB7XtFWLgugURICeoQYkPyz43rNVOJk7PB1fY4UvKc6bg VBshCu0tO2rBGQpBpMlwJNRWAkb/ydHSPR+S0q2GanI7Hjaq+rYscrE9lhLrIZLmauW5 R+WVIRgKFVMbriwpWGz9SiR1oLZT0AjFIHKnw5maI9Yued3Qd9K5W3W+KxsBDPsnJsuP 9CAVvu++mbETqgT+Jmq1vYKYIwRIYb8BL55HV5LP2dZGpNKw8RSSezgZm8i4HzM3vlwH WgmA== X-Gm-Message-State: ALoCoQn7+CepbldPFbUuUrIvVu+AMV1IbjT3xFBApFzhTq2dejRuJXpULu8P9rSOUAOPxcR8uFqR MIME-Version: 1.0 X-Received: by 10.52.255.232 with SMTP id at8mr10339106vdd.4.1409948587899; Fri, 05 Sep 2014 13:23:07 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Fri, 5 Sep 2014 13:23:07 -0700 (PDT) In-Reply-To: References: <20140905201644.1609.35241.idtracker@ietfa.amsl.com> Date: Fri, 5 Sep 2014 13:23:07 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=001a1134df90bbd9910502573c4b Archived-At: http://mailarchive.ietf.org/arch/msg/paws/F-pX78VC9HqCjO5jjVO4TydjeNs Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , draft-ietf-paws-protocol@tools.ietf.org, Ted Lemon Subject: Re: [paws] New Version Notification - draft-ietf-paws-protocol-16.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 20:23:10 -0000 --001a1134df90bbd9910502573c4b Content-Type: text/plain; charset=UTF-8 -internet-drafts On Fri, Sep 5, 2014 at 1:22 PM, Vincent Chen wrote: > All, > > Summary of changes: > > o More precise language: "supports none of the ruleset" instead of > "does not support any ruleset", where it makes sense. > > o Batch request: Change MAY to MUST when some locations are > acceptable > > o Remove explicit mention of OCSP and leave it up the the TLS best > practices draft > > o Define power levels as EIRP for consistency > > Thanks! > > -vince > > On Fri, Sep 5, 2014 at 1:16 PM, wrote: > >> >> A new version (-16) has been submitted for draft-ietf-paws-protocol: >> http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-16.txt >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ >> >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-16 >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> IETF Secretariat. >> >> > > > -- > -vince > -- -vince --001a1134df90bbd9910502573c4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-internet-drafts

On Fri, Sep 5, 2014 at 1:22 PM, Vincent Chen <vchen@g= oogle.com> wrote:
All,

Summary of changes:

=C2=A0 =C2=A0o =C2=A0More precise language: "supports none of = the ruleset" instead of
=C2=A0 =C2=A0 =C2=A0 "does not = support any ruleset", where it makes sense.

= =C2=A0 =C2=A0o =C2=A0Batch request: Change MAY to MUST when some locations = are
=C2=A0 =C2=A0 =C2=A0 acceptable

=C2= =A0 =C2=A0o =C2=A0Remove explicit mention of OCSP and leave it up the the T= LS best
=C2=A0 =C2=A0 =C2=A0 practices draft

=
=C2=A0 =C2=A0o =C2=A0Define power levels as EIRP for consistency
=

Thanks!

-vince

On Fri, Sep 5, 2014 at 1:16 PM, <internet-drafts@ietf.org<= /a>> wrote:

A new version (-16) has been submitted for draft-ietf-paws-protocol:
http://www.ietf.org/internet-drafts/draft-ietf-paws-= protocol-16.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-16

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.




--
-vince



--
-vince
--001a1134df90bbd9910502573c4b-- From nobody Sat Sep 6 08:10:20 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1891A0457; Sat, 6 Sep 2014 08:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA8HClpE3VPV; Sat, 6 Sep 2014 08:10:17 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52191A0438; Sat, 6 Sep 2014 08:10:17 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 795F91B85D2; Sat, 6 Sep 2014 08:10:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CD4FE53E074; Sat, 6 Sep 2014 08:10:16 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 6 Sep 2014 08:10:16 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Sat, 6 Sep 2014 11:10:06 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> To: Vincent Chen X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/BtvMmeM_Czgod2UgelFNukGygJE Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 06 Sep 2014 15:10:19 -0000 Hm, so the new text in 4.4.2 is actually a bit broken: If the Database accepts none the registration for its supported rulesets, the Database MUST return the NOT_REGISTERED error (See Error Codes (Section 5.17)). I think what you mean to say is this: If the Database accepts the registration for none of the specified rulesets, the Database MUST return the NOT_REGISTERED error (See Error Codes (Section 5.17)). Aside from this one nit (sorry!) I think you have addressed all the = points I raised. I'm going to clear my DISCUSS, but please do address = this one last nit! From nobody Sun Sep 7 22:38:03 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394A61A6EFF for ; Sun, 7 Sep 2014 22:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgvbr81TJ1_7 for ; Sun, 7 Sep 2014 22:37:54 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6911B1A6F05 for ; Sun, 7 Sep 2014 22:37:54 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hy4so321392vcb.1 for ; Sun, 07 Sep 2014 22:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tDHZUEbijqCmUb9G73UF06Od32TSwRQEERIg+RB+M/I=; b=ExBDFN+ijt4Ktk3hbr99bf8N0wadNSH7lmuNbY1g9pal28ehygiNFls/GKHnILfLo1 Z/j25VKiokDfj5xuksWM40S+tYsQ9vXglIpvZrFJ/DIrfm9pu2wIklSDH9QpGcDtX2S/ soRrMHF33ZYUbAItyG5GzPTPogcAOAy0PCqP3vRmjicwOz3TDI6sa1G3gk0pUasYSMk2 Yo/p9tvd0QSE0KvxSsL4MnC5KMzyF3IjiiiQ87fJrtBgzeaDJCT3IhTFXF8MiseotAQg dVtQuem79MAAG9M/xGf12Q1HcTCtMt7mKBj3kFFMEhxCCtaUleNEdZ3op3dK2vgXMM1D xV0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tDHZUEbijqCmUb9G73UF06Od32TSwRQEERIg+RB+M/I=; b=lHZGbJqTIYWDv+DHQfI4Bu28lOhcPzJhRNFtYDw9hiwGaV2FFvAs9+EEgdkHcxOg9U 1VDUEP6sRYeXQHxhZPDCLPWocAGbP06FwF2YlRcH/bWs1vzpwye6EjytidroUc/n3IIf Z3tnDT6IwLEQSYwSQGZ4iDxICmCZzfkTr5ujvSA0HKOPvp+n4syI3NouH9Uk6IA52SFt hFMjtIrkrL2frZAiLuMlhCtnu2Efiv/Z2UqTL5l7k4X+ziXpTc3we7MM1XVJxeQ2y/At yXGoLm14aMYy6zMaA9UL6H0zwm/pXIq3vqa9bjAQQbagXtLUqLuXBQriF69Iv6Tyix5S 3tEw== X-Gm-Message-State: ALoCoQmfXcw/pD7v7d9GQkipm0GFp3jMiBlDD0C/+qmH4t2JseTNb5t+V39GRdAqQkYG1LwkrryS MIME-Version: 1.0 X-Received: by 10.52.160.10 with SMTP id xg10mr19878086vdb.1.1410154672431; Sun, 07 Sep 2014 22:37:52 -0700 (PDT) Received: by 10.52.236.232 with HTTP; Sun, 7 Sep 2014 22:37:52 -0700 (PDT) In-Reply-To: <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> Date: Sun, 7 Sep 2014 22:37:52 -0700 Message-ID: From: Vincent Chen To: Ted Lemon Content-Type: multipart/alternative; boundary=089e013cb7b654474605028738cd Archived-At: http://mailarchive.ietf.org/arch/msg/paws/kN38vn4mGz7q7q8RoIa8FKBxXhg Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 05:37:55 -0000 --089e013cb7b654474605028738cd Content-Type: text/plain; charset=UTF-8 Ted, On Sat, Sep 6, 2014 at 8:10 AM, Ted Lemon wrote: > Hm, so the new text in 4.4.2 is actually a bit broken: > > If the Database accepts none the > registration for its supported rulesets, the Database MUST return the > NOT_REGISTERED error (See Error Codes (Section 5.17)). > > I think what you mean to say is this: > > If the Database accepts the registration for none of the > specified rulesets, the Database MUST return the > NOT_REGISTERED error (See Error Codes (Section 5.17)). > LOL. That was the exact wording in Draft 12, but one of the ADs found it confusing and suggested rewording. > > Aside from this one nit (sorry!) I think you have addressed all the points > I raised. I'm going to clear my DISCUSS, but please do address this one > last nit! > > -- -vince --089e013cb7b654474605028738cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,


On Sat, Sep 6, 2014 at 8:10 AM, Ted Lemon <Ted.Lemo= n@nominum.com> wrote:
Hm, s= o the new text in 4.4.2 is actually a bit broken:

=C2=A0 =C2=A0If the Database accepts none the
=C2=A0 =C2=A0registration for its supported rulesets, the Database MUST ret= urn the
=C2=A0 =C2=A0NOT_REGISTERED error (See Error Codes (Sectio= n 5.17)).

I think what you mean to say is this:

=C2=A0 =C2=A0If the Database accepts the registration for none of the
=C2=A0 =C2=A0specified rulesets, the Database MUST return the
=C2=A0 =C2=A0NOT_REGISTERED error (See Error Codes (Sectio= n 5.17)).

LOL. That was the exac= t wording in Draft 12, but one of the ADs found it confusing and suggested = rewording.
=C2=A0

Aside from this one nit (sorry!) I think you have addressed all the = points I raised.=C2=A0 =C2=A0I'm going to clear my DISCUSS, but please = do address this one last nit!




--
-vince
--089e013cb7b654474605028738cd-- From nobody Sun Sep 7 22:47:16 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7B01A0063; Sun, 7 Sep 2014 22:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SwS3hXUr4No; Sun, 7 Sep 2014 22:47:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5CE1A6F0E; Sun, 7 Sep 2014 22:47:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140908054709.32738.56081.idtracker@ietfa.amsl.com> Date: Sun, 07 Sep 2014 22:47:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/5zyh4u3ROV1hf6PkMG6_nAAOV2A Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-17.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 05:47:11 -0000 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) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-17.txt Pages : 91 Date : 2014-09-07 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 managing 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 (PAWS) Databases". 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-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 7 22:47:18 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC031A6F0E for ; Sun, 7 Sep 2014 22:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaUa63xFT7Qc; Sun, 7 Sep 2014 22:47:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BA11A6F12; Sun, 7 Sep 2014 22:47:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org, paws@ietf.org, presnick@qti.qualcomm.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140908054709.32738.59442.idtracker@ietfa.amsl.com> Date: Sun, 07 Sep 2014 22:47:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/dyB-MVfa3H5R9vErwud0MrN2zaQ Subject: [paws] New Version Notification - draft-ietf-paws-protocol-17.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 05:47:12 -0000 A new version (-17) has been submitted for draft-ietf-paws-protocol: http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-17.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Sun Sep 7 22:52:00 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C371A6F11 for ; Sun, 7 Sep 2014 22:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTnSKc46-dOQ for ; Sun, 7 Sep 2014 22:51:53 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0151A6F10 for ; Sun, 7 Sep 2014 22:51:53 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hy10so1291658vcb.31 for ; Sun, 07 Sep 2014 22:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vEFBNbqMLayifRTq19D2QbUqh6xGDOZcaR5SAJu94vE=; b=o0vJ1oWv+RE+FxFw/QswqUsVfJes6fgT6LXVGdnkR2U3x26NzXykTNOppvibzca7F0 54d69w2Rt9u9YDOU55Bsag71hU99Q5koPkLzoLd4I1hfvfrSJIiEHfxffU8hLV4sSlgZ a+3GFgkty4yYXPRD8UvU0J57mUypn5Qh6QYLvK9Ba8qsz31JHIl18l8Vx3FTJapTnAzR yRAmOHr43AFauliE/7eKXsYe8jiRjDk1tUMiajAE8VBkIOGF1cWHGUA1xijvAzKxV3KG PFopne58Q4lpZQtS2O6TvJdudzevJ8lckmUeBCw3B0mh4xMlYrjJ1k5SXVohwXb1lmnE BNKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vEFBNbqMLayifRTq19D2QbUqh6xGDOZcaR5SAJu94vE=; b=j9cCF9mWRYqPF/NzZEP/OJdIDI2TQ8XkPVC/2TE8Qsu3AR+BXsqZ7w4qRa8VgzyHDE r2Ov/4yNfO5bL540N5LF7Ya5pSD4iFKOs6JWi20LqMrMRMGkHhSP93shStj5IPk+AIqG PCCD4c0/f3GPpn8zD//ATaMD4o9ggO+bOwzd0BKXhXrIZe3+BATnxf6uBP6ugjGUVTXE 5C53EwR0WrmTC9jkb9T2QtyLJ1ZAnT6fFRdXFYW/pFfej4jA9B59wEM1PVNGZTWbX92V i8NamQUYh//hWS4DIsJNE88LdQd0OaBhQcQ4lNlbMRWY2xRS1hjNLFQYsql5ZbK7uhq4 To6g== X-Gm-Message-State: ALoCoQmCcdZ314cGjuuT5ejNcsadTaFhAFRfBD+zZjVl7c4oUpZdEusArA4HVXRGMjEQAcYRwnCM MIME-Version: 1.0 X-Received: by 10.52.83.227 with SMTP id t3mr18882316vdy.20.1410155512210; Sun, 07 Sep 2014 22:51:52 -0700 (PDT) Received: by 10.52.236.232 with HTTP; Sun, 7 Sep 2014 22:51:52 -0700 (PDT) In-Reply-To: References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> Date: Sun, 7 Sep 2014 22:51:52 -0700 Message-ID: From: Vincent Chen To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11368e8062490f0502876a72 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/LYkjU8GErcsxXq0XuOPdXEzyte4 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 05:51:54 -0000 --001a11368e8062490f0502876a72 Content-Type: text/plain; charset=UTF-8 Ted, Uploaded with your suggested text. Thanks! -vince On Sun, Sep 7, 2014 at 10:37 PM, Vincent Chen wrote: > Ted, > > > On Sat, Sep 6, 2014 at 8:10 AM, Ted Lemon wrote: > >> Hm, so the new text in 4.4.2 is actually a bit broken: >> >> If the Database accepts none the >> registration for its supported rulesets, the Database MUST return the >> NOT_REGISTERED error (See Error Codes (Section 5.17)). >> >> I think what you mean to say is this: >> >> If the Database accepts the registration for none of the >> specified rulesets, the Database MUST return the >> NOT_REGISTERED error (See Error Codes (Section 5.17)). >> > > LOL. That was the exact wording in Draft 12, but one of the ADs found it > confusing and suggested rewording. > > >> >> Aside from this one nit (sorry!) I think you have addressed all the >> points I raised. I'm going to clear my DISCUSS, but please do address >> this one last nit! >> >> > > > -- > -vince > -- -vince --001a11368e8062490f0502876a72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,

Uploaded with your suggested text.= Thanks!

-vince

On Sun, Sep 7, 2014 at 10:37 PM, Vincent= Chen <vchen@google.com> wrote:
Ted,


On Sat, Sep 6, 2014 at 8:10 AM, Te= d Lemon <Ted.Lemon@nominum.com> wrote:
Hm, so the new text in 4.4.2 is actually a bit broken:

=C2=A0 =C2=A0If the Database accepts none the
=C2=A0 =C2=A0registration for its supported rulesets, the Database MUST ret= urn the
=C2=A0 =C2=A0NOT_REGISTERED error (See Error Codes (Section 5.17)).
I think what you mean to say is this:

=C2=A0 =C2=A0If the Database accepts the registration for none of the
=C2=A0 =C2=A0specified rulesets, the Database MUST return the
=C2=A0 =C2=A0NOT_REGISTERED error (See Error Codes (Section 5.17)).

LOL. That was the exact wo= rding in Draft 12, but one of the ADs found it confusing and suggested rewo= rding.
=C2=A0


--
-vince



--
-vince
--001a11368e8062490f0502876a72-- From nobody Sun Sep 7 22:55:56 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B34F1A6F10 for ; Sun, 7 Sep 2014 22:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epDJC6q7YU0K for ; Sun, 7 Sep 2014 22:55:53 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD781A6F0E for ; Sun, 7 Sep 2014 22:55:52 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id lf12so14786580vcb.39 for ; Sun, 07 Sep 2014 22:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sOU8ifvdiUPRvEVacEZsLE8TIgr2t+5pA2P/6Pd+By4=; b=eu6ml7RZqBAVz5Dhkz6lNBkSrXh3UhksK0NLqRATlHSUaOSmoaOVPnUcKJsRp0wCVt z0dWhCLA8OQtqcyoS4Ql3fHHD49Va09dhlH1ohuFXOpYo7HknvurZH625qQISX2BJnCW 9h+/sQbhPazlzikpwKS+Ka07Eqk4ocXX3m1+roxq/OUHBI6p5Lx28tawnTv+r8bVewbH dAO6+7eWzN5e02yOZSJ/kOvgQECzuhI1/rKYeH8BhI+ozRFAyro2patkMBEIJzETG45n STdnDgq9ZWfZjOP6BYielbNzilGdJJ8EIURiSd84CHM7hka7PWC2Wp/IFW6ATcBKQkSj T8nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sOU8ifvdiUPRvEVacEZsLE8TIgr2t+5pA2P/6Pd+By4=; b=GgrKsnJmXtyEYE2LO/kg++8ybvdG3Uf4l971UMB4oEv+Icm3RPkv6UTLZxpKzaky1q lDupPobVSxzGkvrDlPjrhNQhp7LptXgYPMDnOG56R2nNT0MF0347bfTSAhVG0oDhYr2y TwOvYDJ85AsQAZ2qFrP0ChJFR6NCgJidzy5lAkMWOgToP5BxSzBt86+P/kGXF/J6v1RV PelQN49948qTp+blzuqmG5wd6CqehTgx3xhSuvy6biRhMVOmiCB8iaQkw7vonnYLp4cc wd7qFqw2G9fyDQ1Upvo77DD5qc9lKqCxOCvxmDi6YvdeFX3GD7e10KoJimvZzpuAuZp5 zxxw== X-Gm-Message-State: ALoCoQloNMScbLZ6Hl7SriLFRNv9pIa42dn5VaEjyGuUZDC1soY3dYt5qfDKEInPtsX1wWotWHQI MIME-Version: 1.0 X-Received: by 10.220.168.74 with SMTP id t10mr4787259vcy.35.1410155752022; Sun, 07 Sep 2014 22:55:52 -0700 (PDT) Received: by 10.52.236.232 with HTTP; Sun, 7 Sep 2014 22:55:51 -0700 (PDT) In-Reply-To: <20140908054709.32738.59442.idtracker@ietfa.amsl.com> References: <20140908054709.32738.59442.idtracker@ietfa.amsl.com> Date: Sun, 7 Sep 2014 22:55:51 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2bb1ead9a960502877860 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/vcPymiCY6X-rrP7Apm7hhxCaQ_Q Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] New Version Notification - draft-ietf-paws-protocol-17.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 05:55:54 -0000 --001a11c2bb1ead9a960502877860 Content-Type: text/plain; charset=UTF-8 All, Minor change to update wording for NOT_REGISTERED error. Thanks! -vince On Sun, Sep 7, 2014 at 10:47 PM, wrote: > > A new version (-17) has been submitted for draft-ietf-paws-protocol: > http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-17.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-17 > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > IETF Secretariat. > > -- -vince --001a11c2bb1ead9a960502877860 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Minor change to update wording for= NOT_REGISTERED error.

Thanks!

-vince

On Sun, Sep 7, 2014 at 10:47 PM, <internet-drafts@ietf.org<= /a>> wrote:

A new version (-17) has been submitted for draft-ietf-paws-protocol:
http://www.ietf.org/internet-drafts/draft-ietf-paws-= protocol-17.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-17

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.




--
-vince
--001a11c2bb1ead9a960502877860-- From nobody Mon Sep 8 06:44:59 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2736D1A880E; Mon, 8 Sep 2014 06:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3us0EOEg75oD; Mon, 8 Sep 2014 06:44:56 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB721A8829; Mon, 8 Sep 2014 06:44:42 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AF9EF1B8638; Mon, 8 Sep 2014 06:44:42 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7DD0A53E074; Mon, 8 Sep 2014 06:44:42 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Sep 2014 06:44:42 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 8 Sep 2014 09:44:38 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <83BA02F0-4D05-4626-9DB1-57DB530BB815@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> To: Vincent Chen X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/T2TI7-hByudmutSZuHBxM3rGSFY Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 13:44:57 -0000 On Sep 8, 2014, at 1:37 AM, Vincent Chen wrote: > LOL. That was the exact wording in Draft 12, but one of the ADs found = it confusing and suggested rewording. I agree that it's not ideal, but the new wording was actually ambiguous, = whereas the wording I offered is merely confusing. :) How about: If the Database examines the registration for each ruleset and can find no ruleset for which it can accept registration, the Database MUST return the NOT_REGISTERED error (See Error Codes (Section 5.17)). I think this is less confusing, but lacks the ambiguity of the new text = that the other AD proposed. :) From nobody Mon Sep 8 09:51:30 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1D41A88FF; Mon, 8 Sep 2014 09:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO7c8VgE4JVd; Mon, 8 Sep 2014 09:51:25 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9AC1A88FE; Mon, 8 Sep 2014 09:51:24 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id p9so4504085lbv.24 for ; Mon, 08 Sep 2014 09:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yOGipddKgOmep3dxkOHYo0Okk1C6Fyftqmu08Uxcd7Q=; b=08bM+/4ppj7wFPwlxdwf+Uugf3H1l2CX+w8heFImYP/HYAhiE/Xo+naAR00ZqoZtfR uuRn6V8qoCaQK/z6KVFOMR6rGFv5u+ND6VrG9nJPZF5YGQn0UlZUELz2EwNO/72EGinM 2aHRXeIFX5bkX2ceF0xI8bjljaJ4jfYvHku83bo7aLZbn8EL+KSzii0sFNHR3i5QwTCX WkDpa5wJu/ajmeseIJbO/XYozN06bEBvn5t2z0k6RTw9JtTN9J04Aq4y4Ly4VlFf0qw5 SUBgjMMG5hc0/3pdPQNxC3hEPbgI7AMua2hvm42NXIsYzxkbz14C2q9wjUTlJ8Jvgz39 PM5A== MIME-Version: 1.0 X-Received: by 10.152.18.165 with SMTP id x5mr11619527lad.42.1410195082980; Mon, 08 Sep 2014 09:51:22 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.1.193 with HTTP; Mon, 8 Sep 2014 09:51:22 -0700 (PDT) In-Reply-To: <83BA02F0-4D05-4626-9DB1-57DB530BB815@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> <83BA02F0-4D05-4626-9DB1-57DB530BB815@nominum.com> Date: Mon, 8 Sep 2014 19:51:22 +0300 X-Google-Sender-Auth: TWi6-IyP4eq5OGvMRI4hcK7luB0 Message-ID: From: Barry Leiba To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/KCkJNZCFqWAkSMrRsaJT5vc5ly8 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 16:51:26 -0000 > If the Database examines the registration for each > ruleset and can find no ruleset for which it can > accept registration, the Database MUST return the > NOT_REGISTERED error (See Error Codes (Section 5.17)). > > I think this is less confusing, but lacks the ambiguity of the new > text that the other AD proposed. :) The other AD had actually proposed "If the database fails to accept the registration for all rulesets..." -- Other AD From nobody Mon Sep 8 10:02:41 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EA81A8907; Mon, 8 Sep 2014 10:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld2-9HOv4VS5; Mon, 8 Sep 2014 10:02:34 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4711A8919; Mon, 8 Sep 2014 10:02:33 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9EE5C1B8709; Mon, 8 Sep 2014 10:02:33 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7F16F53E074; Mon, 8 Sep 2014 10:02:33 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Sep 2014 10:02:33 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 8 Sep 2014 13:02:27 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> <83BA02F0-4D05-4626-9DB1-57DB530BB815@nominum.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ad_cKPdYvysYUxvlWWP092uIUeg Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 17:02:35 -0000 On Sep 8, 2014, at 12:51 PM, Barry Leiba = wrote: > The other AD had actually proposed "If the database fails to accept > the registration for all rulesets..." Ah, which isn't what the authors appear to have intended, hence the = change to "any". Sigh. Math is hard. :) From nobody Mon Sep 8 10:12:26 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2B81A8982 for ; Mon, 8 Sep 2014 10:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDVPIk0rp55b for ; Mon, 8 Sep 2014 10:12:06 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D921A894A for ; Mon, 8 Sep 2014 10:09:58 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id le20so1725537vcb.32 for ; Mon, 08 Sep 2014 10:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=svSz+VIfknJndWgs2z6jy9SBByC/3dYhyyCQRlc9zY8=; b=dSvZj3nYUZvvogTJHy19l8h+Jt+/Epz7vmNP7rEKcefbT/CPX9DYHe0FOLfd7bHZ+p 4ewzwMdaEZHKLPFJPj7hbjI41B7ZfSyw4NHQGiwYGiumZyu1fhFwFTSTciaMkNwZph57 sYEurcdy1Jg1fxnSXMts7V5YP/NVzOy+L9TiHMtvpsFNyH/lz5J+1/phyYPhNGYsWsAW boty9dCvrzMNBhb1TYa9XPntW9zxJqCwYrxG30n2dVwOLevG8a1ecjddO6dN60l8A7Ly Cv9V+jICmtGjdvAZ8wOW6WmlxDKwDn0tfPusTbVCkAg3gMC9MVqGpbo7sTchCT+vlKPt BYmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=svSz+VIfknJndWgs2z6jy9SBByC/3dYhyyCQRlc9zY8=; b=h2oiVeav5jFG9avFUwUO8j/yXx4FE/+z51mFZxaEb+psLYi1n8RXSKoq0AZDPDP+wp r+WVfWFIc5I9CjF2dgJ3nEn8VbaJTqRDrHi7a0mS/hzMOVxiUAnEW5bsdsxRsl893tSD 9GlY/aZEOnBl1V9ccU/LjF3lz2dRE8098nKQciWpHBHVJnLUDi4vxg3ftr77cw5psje7 bi94PI9R4dB9SG7LXK7A7fWpvVIdHeEp3/X0CTx9dB5y+doXAGCIh++/Qf5hSzRauchc dqcD0FrXUqyEmSvJouNglA5aMsWJFmP6BF6DZeRazg6Xt0J0rEVZSGjR6/hKvyFqXnUE /wPA== X-Gm-Message-State: ALoCoQnxBCX4MmEDpaoDPudgRMHhQQj+dZWtF3R91Je4ehpLEN7itVLSfceXmCxpvv7UQz6dHZiF MIME-Version: 1.0 X-Received: by 10.52.248.211 with SMTP id yo19mr947834vdc.67.1410196197775; Mon, 08 Sep 2014 10:09:57 -0700 (PDT) Received: by 10.52.236.232 with HTTP; Mon, 8 Sep 2014 10:09:57 -0700 (PDT) In-Reply-To: References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> <83BA02F0-4D05-4626-9DB1-57DB530BB815@nominum.com> Date: Mon, 8 Sep 2014 10:09:57 -0700 Message-ID: From: Vincent Chen To: Ted Lemon Content-Type: multipart/alternative; boundary=089e013c5b7c6eb12c050290e31d Archived-At: http://mailarchive.ietf.org/arch/msg/paws/_Npw5sBIqKmfInY_qL4G81VdHrI Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , Barry Leiba , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 17:12:12 -0000 --089e013c5b7c6eb12c050290e31d Content-Type: text/plain; charset=UTF-8 Barry, Ted, Ouch....I must have remembered wrong. I do mean that if registration fails for all.... Please take a look at draft 17 wording and see if I should adjust again. Thanks. -vince On Mon, Sep 8, 2014 at 10:02 AM, Ted Lemon wrote: > On Sep 8, 2014, at 12:51 PM, Barry Leiba wrote: > > The other AD had actually proposed "If the database fails to accept > > the registration for all rulesets..." > > Ah, which isn't what the authors appear to have intended, hence the change > to "any". Sigh. Math is hard. :) > > -- -vince --089e013c5b7c6eb12c050290e31d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry, Ted,

Ouch....I must have remembe= red wrong.
I do mean that if registration fails for all....
=

Please take a look at draft 17 wording and see if I sho= uld adjust again.

Thanks.

-vince


On Mon, Sep 8, 2014 at 10:02 AM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
On Sep 8, 2014, at 12:51 PM, Barry Leiba <barryleiba@computer.org> wrote:
> The other AD had actually proposed "If the database fails to acce= pt
> the registration for all rulesets..."

Ah, which isn't what the authors appear to have intended, hence = the change to "any".=C2=A0 =C2=A0Sigh.=C2=A0 =C2=A0Math is hard.= =C2=A0 =C2=A0:)




--
-vince
--089e013c5b7c6eb12c050290e31d-- From nobody Mon Sep 8 10:34:11 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289441A0087; Mon, 8 Sep 2014 10:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFSUhvDznFVl; Mon, 8 Sep 2014 10:34:09 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7741A003A; Mon, 8 Sep 2014 10:34:09 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2B82C1B8707; Mon, 8 Sep 2014 10:34:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 064DB53E074; Mon, 8 Sep 2014 10:34:09 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Sep 2014 10:34:09 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 8 Sep 2014 13:34:02 -0400 Content-Transfer-Encoding: 7bit Message-ID: References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> <2AB0D28E-27E3-455C-AF2D-9352A8D649C3@nominum.com> <3DEACA43-3605-4C6D-98FE-232D2B8644DD@nominum.com> <853D364C-8382-4467-BEC6-EEC5E9E7F2A5@nominum.com> <83BA02F0-4D05-4626-9DB1-57DB530BB815@nominum.com> To: Vincent Chen X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/PBLJyzIzgYdf2OPbgJ-LseuPPrA Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , Barry Leiba , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 17:34:10 -0000 The new text seems good to me, and better than what I proposed. Thanks! From nobody Fri Sep 12 09:04:03 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679CD1A03FE for ; Fri, 12 Sep 2014 09:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3olt0m2HK6s for ; Fri, 12 Sep 2014 09:03:52 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4B11A02BE for ; Fri, 12 Sep 2014 09:03:52 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id 92D212054D for ; Fri, 12 Sep 2014 12:03:51 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 12 Sep 2014 12:03:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type; s=mesmtp; bh=XCGBenqrxYg4B4ezeajN6AY 9cWM=; b=F55e0WcXRguxvATtu1pesiHa9nTW7mGCDhBEkFKCK0Rn2E1Tl5MAdg5 Uw09O6b2A9RVPopruNikWE8fB/h+fhYTBSglh9ml3xMnxRWOR7AoMBOcSs++2VBm NL1MV8BONUdPjFtFW7SFqZWk1DnDcOx5e5qr/8EuZG1cvWDoDjEY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type; s=smtpout; bh=XCGBenqrxYg4B4ezeajN6AY9cWM=; b=ZwbDObfYqsuyzSjrek0bT32EdCG5 G7ViIf/XXZ94kKf+RZG8hL83cejGEddXcgSBO3x5IKXiYmvJbtvlQkoh6hDCUjBh gwOhuCga9oNnZ7gu2ljccTKWiE7Cfn9kNkoIWg0BD9lFT10zYDwTXUTPUpDR2hRl NMzrzEIsaYiHzpI= X-Sasl-enc: DqgWc7HnQHW7Xo3kk0jgUhBQTwLA6buQNH1YoHz0k08g 1410537830 Received: from [10.150.9.107] (unknown [64.102.254.34]) by mail.messagingengine.com (Postfix) with ESMTPA id D0456C008FC; Fri, 12 Sep 2014 12:03:48 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Fri, 12 Sep 2014 12:03:44 -0400 From: Alissa Cooper To: Vincent Chen Message-ID: Thread-Topic: Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3493368231_34316078" Archived-At: http://mailarchive.ietf.org/arch/msg/paws/QoVYfPRbUR9C2rTdePKK4Uq185w Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 12 Sep 2014 16:03:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3493368231_34316078 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Vincent, I=E2=80=99ve taken a look at the =E2=80=9317. Thanks for accommodating many of my DISCU= SS points. I have a one response below on a couple of remaining issues. On 8/21/14, 12:59 AM, "Vincent Chen" wrote: >=20 >>=20 >> =3D Section 5.1 =3D >> I'd like to discuss why the single point location format needs to be >> supported here. Is it really the case that a portion of whitespace >> spectrum will ever be available only at a single point, as opposed to a >> region? If not, it seems like sending a point (and, moreover, allowing >> region to be unsupported but not point) divulges more precise informatio= n >> about the requesting device than is ever actually necessary to fulfill >> the goals of this protocol. Do regulators require a single point? Why? >=20 > The resulting spectrum is valid for 100m (typically) radius around that p= oint. >=20 > Computation of available spectrum for a region is actually complex and no= t > well defined... > =20 >>=20 >> =3D Section 5.2 =3D >> I'd like to discuss why the device serial number needs to be included in >> the device descriptor, rather than some (perhaps persistent) randomly >> generated device identifier that is used only in the context of this >> protocol (which would better protect the privacy of the user of the >> device, since the whitespaces database administrator wouldn't be able to >> correlate the device's spectrum requests with other activities linked to >> the serial number). It's not really clear why serial number is collected >> since both this document and RFC 6953 note the protocol does not defend >> against abuse or mis-use of spectrum. >=20 > The regulator want to have the ability to black list ranges of serial num= bers, > if it > determines that a series was defective. The Databases must use the serial > number > to determine it can return available spectrum. > =20 >>=20 >> I'm asking the above two questions in light of requirement P.7 from RFC >> 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of >> device-provided data where such protection is feasible, allowed, and >> desired." >>=20 >> A separate interesting question that does not seem to be addressed >> anywhere in the draft is whether a device can be fingerprinted by the >> database operator by virtue of the collection of elements it sends >> (rulesetIds, manufacturer, model, antenna characteristics, device >> capabilities, etc.) even if it doesn't send a serial number or device >> owner information that uniquely identify it. That seems worth discussion >> in Section 10. >=20 > What should the discussion say? Just that it is possible? or does it need > to have a solution? Now that the document is clear that Slave device location and serial number are optional (unless required by a ruleset), I think the remaining task on the above three points is to add a bit of text to Section 10 to explain the potential privacy threats from authorized databases, perhaps as a short paragraph or two at the end of Section 10. Something along these lines (jus= t a suggestion, feel free to reject this entirely or use bits that you like): "In addition to the privacy risks described above, in some cases, users of Master or Slave devices may open themselves up to privacy risks related to the secondary use of PAWS-related information by a database administrator. For example, in situations where rulesets require that Master or Slave devices uniquely identify themselves (via the DeviceDescriptor or DeviceOwner parameters), database administrators may be able to use that information to track connectivity activity over time, or they may share suc= h tracking information with third parties. Where Master or Slave devices choose to provide or are required to provide geolocation information in conjunction with unique device identifiers, this capability may further extent to location tracking. Even where a device does not provide a specifi= c unique identifier, a database administrator may be able to uniquely fingerprint a device based on the combination of other information provided in DeviceDescriptor or DeviceCapabilities parameters. In cases where devices have a choice to not send device-identifying information or geolocation, or to send less granular geolocation (i.e., a region rather than a point), PAWS implementations can reduce the risks associated with secondary use by not sending that information. Where rulesets require this information to be sent, these risks require out-of-band mitigation (e.g., public statements or contractual terms preventing secondary use).=E2=80=9D Thanks, Alissa > =20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> =3D Shepherd write-up=3D >> "An in-depth review by a JSON expert might be useful." >>=20 >> Did that happen? >=20 > Tim Bray had looked at it before final call. > =20 >>=20 >> =3D Section 1 =3D >> "It opens the door for innovations in spectrum >> management that can incorporate a variety of parameters, including >> user location and time. In the future, it also can include other >> parameters, such as user priority, time, signal type and power, >> spectrum supply and demand, payment or micro-auction bidding, and >> more." >>=20 >> Time seems to be listed both as a current parameter and a future one, >> which is confusing. >=20 > Agreed. The second "time" should be removed. > =20 >>=20 >> =3D Section 4.4 =3D >> "FCC rules, for example, require that a 'Fixed Device' >> register its owner and operator contact information, its device >> identifier, its location, and its antenna height." >>=20 >> It would be nice to have a citation for the rules referenced here. >=20 > OK. > =20 >>=20 >> =3D Section 5.1 =3D >> Feel free to ignore this if it's completely misguided, but does altitude >> really not matter? Are we sure this protocol won't be re-used for device= s >> on airplanes trying to find available spectrum? (I note that in RFC 6953= , >> requirement D.1 specifies that the data model must support "the height >> and its uncertainty" -- I have no idea what "the height" means or if it >> is related to altitude.) >=20 > See Section 5.3 on "height" of the antenna. It's separated out, from the > "latitude, longitude" specification > of GeoLocation. It allows specification with respect to ground level or m= ean > sea level, and is intended > for Fixed devices, rather than mobile devices. >=20 > From the current regulator's perspective, the allowed power for mobile de= vices > is low enough that > height does not matter. >=20 > =20 >>=20 >> =3D Section 10 =3D >> I agree with Stephen that the database operator should be considered as = a >> potential adversary from the standpoint of potentially being able to >> create a fine-grained database that tracks the locations and spectrum us= e >> patterns of individual devices. That data could certainly be abused. >>=20 >=20 > So just listing that as a potential threat and declare that fixing this a= s out > of scope is sufficient? >=20 > Or do we need to state that Databases MUST not track? I can see how anony= mized > tracking > can be useful for spectrum management in the future, much like anonymized > tracking of car locations > provide valuable traffic information for navigation systems. >=20 > --=20 > -vince=20 --B_3493368231_34316078 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Vincent,

I’ve taken a look at the –17. Thanks for accommodating m= any of my DISCUSS points. I have a one response below on a couple of remaini= ng issues.

On = 8/21/14, 12:59 AM, "Vincent Chen" <vche= n@google.com> wrote:



=3D Section 5.1 =3D
I'd like to discuss why the single point location format needs to be
supported here. Is it really the case that a portion of whitespace
spectrum will ever be available only at a single point, as opposed to a
= region? If not, it seems like sending a point (and, moreover, allowing
region to be unsupported but not point) divulges more precise information about the requesting device than is ever actually necessary to fulfill
the goals of this protocol. Do regulators require a single point? Why?
<= /blockquote>

The resulting spectrum is valid for 100m (ty= pically) radius around that point.

Computation of a= vailable spectrum for a region is actually complex and not well defined...
 

=3D Section 5.2 =3D
I'd like to discuss why the device serial number needs to be included in the device descriptor, rather than some (perhaps persistent) randomly
generated device identifier that is used only in the context of this
protocol (which would better protect the privacy of the user of the
device, since the whitespaces database administrator wouldn't be able to correlate the device's spectrum requests with other activities linked to the serial number). It's not really clear why serial number is collected since both this document and RFC 6953 note the protocol does not defend
= against abuse or mis-use of spectrum.

T= he regulator want to have the ability to black list ranges of serial numbers= , if it
determines that a series was defective. The Databases must= use the serial number
to determine it can return available spectr= um.
 

I'm asking the above two questions in light of requirement P.7 from RFC
= 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of
device-provided data where such protection is feasible, allowed, and
desired."

A separate interesting question that does not seem to be addressed
anywhere in the draft is whether a device can be fingerprinted by the
database operator by virtue of the collection of elements it sends
(rulesetIds, manufacturer, model, antenna characteristics, device
capabilities, etc.) even if it doesn't send a serial number or device
owner information that uniquely identify it. That seems worth discussion in Section 10.

What should the discussi= on say? Just that it is possible? or does it need
to have a soluti= on?

Now that = the document is clear that Slave device location and serial number are optio= nal (unless required by a ruleset), I think the remaining task on the above = three points is to add a bit of text to Section 10 to explain the potential = privacy threats from authorized databases, perhaps as a short paragraph or t= wo at the end of Section 10. Something along these lines (just a suggestion,= feel free to reject this entirely or use bits that you like):
"In addition to the privacy risks described above, in some cases= , users of Master or Slave devices may open themselves up to privacy risks r= elated to the secondary use of PAWS-related information by a database admini= strator. For example, in situations where rulesets require that Master or Sl= ave devices uniquely identify themselves (via the DeviceDescriptor or Device= Owner parameters), database administrators may be able to use that informati= on to track connectivity activity over time, or they may share such tracking= information with third parties. Where Master or Slave devices choose to pro= vide or are required to provide geolocation information in conjunction with = unique device identifiers, this capability may further extent to location tr= acking. Even where a device does not provide a specific unique identifier, a= database administrator may be able to uniquely fingerprint a device based o= n the combination of other information provided in DeviceDescriptor or Devic= eCapabilities parameters. 

In cases where devi= ces have a choice to not send device-identifying information or geolocation,= or to send less granular geolocation (i.e., a region rather than a point), = PAWS implementations can reduce the risks associated with secondary use by n= ot sending that information. Where rulesets require this information to be s= ent, these risks require out-of-band mitigation (e.g., public statements or = contractual terms preventing secondary use).”

Thanks,
Alissa

 


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
<= br> =3D Shepherd write-up=3D
"An in-depth review by a JSON expert might be useful."

Did that happen?

Tim Bray had looked at= it before final call.
 

=3D Section 1 =3D
"It opens the door for innovations in spectrum
   management that can incorporate a variety of parameters, inclu= ding
   user location and time.  In the future, it also can inclu= de other
   parameters, such as user priority, time, signal type and power= ,
   spectrum supply and demand, payment or micro-auction bidding, = and
   more."

Time seems to be listed both as a current parameter and a future one,
which is confusing.

Agreed. The second = "time" should be removed.
 
=3D Section 4.4 =3D
"FCC rules, for example, require that a 'Fixed Device'
   register its owner and operator contact information, its devic= e
   identifier, its location, and its antenna height."

It would be nice to have a citation for the rules referenced here.

OK.
 

=3D Section 5.1 =3D
Feel free to ignore this if it's completely misguided, but does altitude really not matter? Are we sure this protocol won't be re-used for devices on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height
and its uncertainty" -- I have no idea what "the height" means or if it
= is related to altitude.)

See Section 5.= 3 on "height" of the antenna. It's separated out, from the "latitude, longit= ude" specification
of GeoLocation. It allows specification with re= spect to ground level or mean sea level, and is intended
for Fixed= devices, rather than mobile devices.

From the curr= ent regulator's perspective, the allowed power for mobile devices is low eno= ugh that
height does not matter.

 

=3D Section 10 =3D
I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to
create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused.

So just listing that as a potential threat= and declare that fixing this as out of scope is sufficient? 

Or do we need to state that Databases MUST not track? I can see how an= onymized tracking
can be useful for spectrum m= anagement in the future, much like anonymized tracking of car locations
provide valuable traffic information for navigatio= n systems.

--
-vince
--B_3493368231_34316078-- From nobody Fri Sep 12 09:05:11 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969081A0706 for ; Fri, 12 Sep 2014 09:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ9t685HntOE for ; Fri, 12 Sep 2014 09:05:06 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0921A00A3 for ; Fri, 12 Sep 2014 09:05:06 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id C9A1620BAA for ; Fri, 12 Sep 2014 12:05:05 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 12 Sep 2014 12:05:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type; s=mesmtp; bh=TVN62stJ+l1TUpjBV2ouACB SvcU=; b=xNw2DAdF8MKgHfTjjjwQr/JzsHuqhCg13u/NYbkWBtp69EJioiUSSON fWznR4atLac8K9Vf/ItFx6tv3kxZ9pJk/6IZ0MCrsXq+zMR+8v3rBc1WgqhZUNIj U7Am7APeScRLOwAJmD/GY/1Catr/KphHgvycUT19mJRy7A3lfn5A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type; s=smtpout; bh=TVN62stJ+l1TUpjBV2ouACBSvcU=; b=SYy/vYMQhyOr5TgofS+wR7YG/Q0x LGpufZeepX9FUFCdMOB9g4zQNFwFbhOHgZCKLWL+XT6rjYkrhVs8YVxQaetez3sC qloe3ehW9CDE1Oz0TlGF3KNmFzNqlCHnCsFNUdFkqc7HZZFBm0bEbkXYeXKIHWy3 i5dw9nOwqJiQmgo= X-Sasl-enc: 170oD0PQDfWgoDoAX5rxn856AV+2InBA+XmBEhPjhRah 1410537904 Received: from [10.150.9.107] (unknown [64.102.254.33]) by mail.messagingengine.com (Postfix) with ESMTPA id F3909C00915; Fri, 12 Sep 2014 12:05:01 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Fri, 12 Sep 2014 12:04:56 -0400 From: Alissa Cooper To: Gabor Bajko Message-ID: Thread-Topic: Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3493368304_34318196" Archived-At: http://mailarchive.ietf.org/arch/msg/paws/NRxhtPBCKhFKejC8MOqVdjvH6DI Cc: "paws@ietf.org" , paws-chairs@tools.ietf.org, The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 12 Sep 2014 16:05:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3493368304_34318196 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 8/21/14, 4:32 PM, "Gabor Bajko" wrote: >=20 >=20 >=20 > On Wed, Aug 20, 2014 at 9:52 AM, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-paws-protocol-14: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> I'm glad this work is being done in the IETF, thanks for all your >> effort. >>=20 >> A couple of my points below have overlaps with some of Stephen's points. >>=20 >> =3D Shepherd write-up =3D >> "Yes, there were 2 IPR disclosures filed that reference this document. >> They were discussed in the WG, and nobody came forward to say that they'= d >> like to change anything in the document because of the disclosures." >>=20 >> But there are 3 IPR disclosures in the tracker, not 2. Were all three >> discussed in the WG? >>=20 > This 3rd IPR disclosure seems to have surfaced 2 months after the shephe= rd > write-up, that is why it is not mentioned in the write-up. > I think the best we can do now is to consult the WG about this disclosure= in > parallel with the iesg evaluations. I saw Pete=E2=80=99s note to the mailing list about the third IPR disclosure but haven=E2=80=99t seen any responses (right?). What is the status? Thanks, Alissa > Gabor --B_3493368304_34318196 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
On 8/21/14, 4:32 PM, "Gabor B= ajko" <gaborbajko@gmail.com>= wrote:


<= br>
On Wed, Aug 20, 2014 at 9:52 AM, Alissa Coop= er <al= issa@cooperw.in> wrote:
Alissa Co= oper has entered the following ballot position for
draft-ietf-paws-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
<= br> I'm glad this work is being done in the IETF, thanks for all your
effort.

A couple of my points below have overlaps with some of Stephen's points.
=3D Shepherd write-up =3D
"Yes, there were 2 IPR disclosures filed that reference this document.
They were discussed in the WG, and nobody came forward to say that they'd like to change anything in the document because of the disclosures."
But there are 3 IPR disclosures in the tracker, not 2. Were all three
discussed in the WG?

This  3rd IPR disclosure= seems to have surfaced 2 months after the shepherd write-up, that is why it= is not mentioned in the write-up.
I think the best we can do now = is to consult the WG about this disclosure in parallel with the iesg evaluat= ions.

I saw P= ete’s note to the mailing list about the third IPR disclosure but have= n’t seen any responses (right?). What is the status?

Thanks,
Alissa

Gabor
 --B_3493368304_34318196-- From nobody Thu Sep 18 00:16:21 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A47B1A700B for ; Thu, 18 Sep 2014 00:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhNWIFKIo4mi for ; Thu, 18 Sep 2014 00:16:16 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8471D1A6F9E for ; Thu, 18 Sep 2014 00:16:15 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Importance:X-Priority: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=mbvN/YCcEaB+E/ftMukczgdGW63Zke6Z90/ghC/V1KsXRNOqxkUeC1So CoTNzMSfghV6loFxxVev0uTea0+VmfS5fYPNu+51Of3FlZbjO0mk/6JOC e+Dk+r3z0jIdDb5fG8OC0jLtkCxsFNmuOBKReYdwsbRSmO6QgIr/NT4OZ cQc7+i/na79XycTHFce/AiG4Ilneu5yFiQzS1FCcS8h3uzQugpSC0iq05 KWdxZHJZ2k/qhcuYR+04IJTRM2WDM; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1411024576; x=1442560576; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s+wqk/0HcX7iI25hanCuQqTgsqmIqxhmCO8Jz/ID1vs=; b=pYrqWaLdSqVb7cVad8HYL8Q7LENPWZyueF69JrbT1nNfV/rjRiTkcyev Y561GmP2DXCfKzlRYd2D3RxdFe4Fo1DqZe8GYKN0kQTnPhogJIAiDOshI g2H4vnD8tMzjxoThdPVPJGewpt9eFdbMmmqeIiGd4aSo/mql0iJE5/Kl3 WnJAm/BtnIMqIUIfzp4cFNCUHO83JmME/yuEwPJs3HTgY8s45oNMFuAX0 lnwPuRQL3rPvE8K57hwB1NgROFRew; X-IronPort-AV: E=Sophos;i="5.04,545,1406588400"; d="scan'208";a="12408388" X-IPAS-Result: AgsFAFaFGlTV+MWR/2dsb2JhbABhgmojU1cEyRWHUQGBChYBAXiEBAEBAwEpKiYFCwIBAgYOODIlAgQOBYg2CQMJwAABEwSPRDMHgy6BHQWWBZxPg15sgUiBAgEBAQ Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 18 Sep 2014 08:16:14 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Thu, 18 Sep 2014 08:16:13 +0100 From: Ray Bellis To: Pete Resnick Thread-Topic: [paws] Please review IPR disclosure https://datatracker.ietf.org/ipr/2340/ Thread-Index: AQHPvU/d1j5UJH/q2EGfEzSD8y5lTZwGlXYA Importance: high X-Priority: 1 Date: Thu, 18 Sep 2014 07:16:12 +0000 Message-ID: <34C30BB8-CCC1-45FD-9BD8-7DAF9EDEF36C@nominet.org.uk> References: <53F60830.3020506@qti.qualcomm.com> In-Reply-To: <53F60830.3020506@qti.qualcomm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/0HnaLJet5vLOjqJqewisr6OVEF0 Cc: "paws@ietf.org" Subject: Re: [paws] Please review IPR disclosure https://datatracker.ietf.org/ipr/2340/ X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2014 07:16:19 -0000 On 21 Aug 2014, at 15:54, Pete Resnick wrote: > PAWS participants: >=20 > Somehow an IPR disclosure was filed on the PAWS protocol document for whi= ch we did not see an announcement: >=20 > https://datatracker.ietf.org/ipr/2340/ >=20 > As far as I can tell from the title (given that the referenced IP is an a= s-yet-unpublished patent), this applies to the database discovery portion o= f the protocol. Since we have removed much of that discussion, we expect mo= stly pre-configuration, and we have yet to (and may never) complete the act= ual database discovery work, I think this may have no effect on folks imple= menting the protocol. But I do need to confirm that the WG is aware of this= and still thinks it's OK to move forward with the protocol document. >=20 > If there are any objections to moving forward, I need to hear that immedi= ately. >=20 > However, I would like to hear an overt, "Yes, understood, and it's fine t= o move forward" from some folks who might be implementing the protocol. I=92m unable to find the text of the Nokia application, so it=92s difficult= to assess. I note that they=92ve quoted an application date of 29 April 2013, I=92d be= amazed if there isn=92t some prior work relating to database discovery (e.= g. the OFCOM spec, or ETSI EN 301 598) although that does depend on exactly= what mechanism it is they=92re claiming. Given the WG's de-emphasis on DB discovery I see no reason to change course= based on this. Ray From nobody Thu Sep 18 05:46:02 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13B61A00F5 for ; Thu, 18 Sep 2014 05:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_skhFtdLaAb for ; Thu, 18 Sep 2014 05:45:56 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2BE1A02D5 for ; Thu, 18 Sep 2014 05:45:55 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id i13so971463qae.24 for ; Thu, 18 Sep 2014 05:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rIXTz1WRoiuY3id9l0ZolWKDfrDY+j2N58Y8rvpN8g4=; b=t0/1rb1zRCZup55t+9tSZfMKwh4/fRMnTzDlyzQcZ80gYDUWNXr2L6YevCJxq2TLXf 4Ku0NQLFbLk9kGaAmV5pDsPPbiUL3HT/fvuEx+hnlIaGYomrDEj7cZMv9wAUJqJfFXyb KumAfCUPJVpLN3iqrv9SCFi8LiJMhxiQITX6B8coUilJiCtmYu8ryXD85cvDc/B5weIw qHt11p+CViutLB0zhl/x7+R3/WHxW8Uek2OKnhehYnC0rNtE4pLKI1g0iyocCyNNtI+2 fIKDdgiKZkkk05wAlRid5l68EWqZaHR9kjzpvYCqIaNJwI1J4wdCPNUJb1ku0dFsQoQK JdCw== MIME-Version: 1.0 X-Received: by 10.224.28.201 with SMTP id n9mr8233836qac.81.1411044354977; Thu, 18 Sep 2014 05:45:54 -0700 (PDT) Received: by 10.96.174.199 with HTTP; Thu, 18 Sep 2014 05:45:54 -0700 (PDT) In-Reply-To: <34C30BB8-CCC1-45FD-9BD8-7DAF9EDEF36C@nominet.org.uk> References: <53F60830.3020506@qti.qualcomm.com> <34C30BB8-CCC1-45FD-9BD8-7DAF9EDEF36C@nominet.org.uk> Date: Thu, 18 Sep 2014 08:45:54 -0400 Message-ID: From: Don Joslyn To: Ray Bellis Content-Type: multipart/alternative; boundary=001a11c35ab08a78040503565dec Archived-At: http://mailarchive.ietf.org/arch/msg/paws/H5i4j90oDWDOTvqURJs3iJWo-PU Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] Please review IPR disclosure https://datatracker.ietf.org/ipr/2340/ X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2014 12:45:59 -0000 --001a11c35ab08a78040503565dec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Try this link: http://appft.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=3D1= &u=3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&co1=3DAND&d=3D= PG01&s1=3D%22White+Space+database+discovery%22&OS=3D%22White+Space+database= +discovery%22&RS=3D%22White+Space+database+discovery%22 Regards, Don On Thu, Sep 18, 2014 at 3:16 AM, Ray Bellis wrote: > > On 21 Aug 2014, at 15:54, Pete Resnick wrote: > > > PAWS participants: > > > > Somehow an IPR disclosure was filed on the PAWS protocol document for > which we did not see an announcement: > > > > https://datatracker.ietf.org/ipr/2340/ > > > > As far as I can tell from the title (given that the referenced IP is an > as-yet-unpublished patent), this applies to the database discovery portio= n > of the protocol. Since we have removed much of that discussion, we expect > mostly pre-configuration, and we have yet to (and may never) complete the > actual database discovery work, I think this may have no effect on folks > implementing the protocol. But I do need to confirm that the WG is aware = of > this and still thinks it's OK to move forward with the protocol document. > > > > If there are any objections to moving forward, I need to hear that > immediately. > > > > However, I would like to hear an overt, "Yes, understood, and it's fine > to move forward" from some folks who might be implementing the protocol. > > I=E2=80=99m unable to find the text of the Nokia application, so it=E2=80= =99s difficult to > assess. > > I note that they=E2=80=99ve quoted an application date of 29 April 2013, = I=E2=80=99d be > amazed if there isn=E2=80=99t some prior work relating to database discov= ery (e.g. > the OFCOM spec, or ETSI EN 301 598) although that does depend on exactly > what mechanism it is they=E2=80=99re claiming. > > Given the WG's de-emphasis on DB discovery I see no reason to change > course based on this. > > Ray > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > --001a11c35ab08a78040503565dec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 18, 2014 at 3:16 AM, Ray Bellis <Ray.= Bellis@nominet.org.uk> wrote:

On 21 Aug 2014, at 15:54, Pete Resnick <presnick@qti.qualcomm.com> wrote:

> PAWS participants:
>
> Somehow an IPR disclosure was filed on the PAWS protocol document for = which we did not see an announcement:
>
> h= ttps://datatracker.ietf.org/ipr/2340/
>
> As far as I can tell from the title (given that the referenced IP is a= n as-yet-unpublished patent), this applies to the database discovery portio= n of the protocol. Since we have removed much of that discussion, we expect= mostly pre-configuration, and we have yet to (and may never) complete the = actual database discovery work, I think this may have no effect on folks im= plementing the protocol. But I do need to confirm that the WG is aware of t= his and still thinks it's OK to move forward with the protocol document= .
>
> If there are any objections to moving forward, I need to hear that imm= ediately.
>
> However, I would like to hear an overt, "Yes, understood, and it&= #39;s fine to move forward" from some folks who might be implementing = the protocol.

I=E2=80=99m unable to find the text of the Nokia application, so it=E2=80= =99s difficult to assess.

I note that they=E2=80=99ve quoted an application date of 29 April 2013, I= =E2=80=99d be amazed if there isn=E2=80=99t some prior work relating to dat= abase discovery (e.g. the OFCOM spec, or ETSI EN 301 598) although that doe= s depend on exactly what mechanism it is they=E2=80=99re claiming.

Given the WG's de-emphasis on DB discovery I see no reason to change co= urse based on this.

Ray



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

--001a11c35ab08a78040503565dec-- From nobody Thu Sep 18 10:37:14 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBF61A887D for ; Thu, 18 Sep 2014 10:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiKIdt6C6EpH for ; Thu, 18 Sep 2014 10:37:09 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617451A0653 for ; Thu, 18 Sep 2014 10:36:20 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so1797776igd.2 for ; Thu, 18 Sep 2014 10:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=67UhFpMYEvb9N93bzIeG8SxNj4qocM+9EvlYk/50Sfg=; b=j4bNLPGDxqWnhiC7UyjmUK2u4rUInjD8K6F1R2Rj83jzADlcYfYXgBlIX178j+Dq0q Lg4MidSue8U35hGcZTCVIXT/VM7L9ORBRHuF6itCgQpvamfAUTPZJa1HvNJ8YNBeEYcf 8OVTnWmjOrChQRhQQco5iuBOe9H/w6XdWE8YwqydxSGiMJD/+b814qapgAcp0CuP2UBO oSBgI6lzrurNfojNopNA+A6lUZBwBp6XgsaTLnEJld2W6hl2xl4+JFI5OaQaSPue+BIH JHQHjZJM3iale4s86/9ZEZ/+s/5cs2iXsHgNYvaSOCKhx57w3v88KOaeUMaBKgW0I6ue xe4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=67UhFpMYEvb9N93bzIeG8SxNj4qocM+9EvlYk/50Sfg=; b=L2huK7VnPObYtmwXs8kAlW63XppR+UR/TYuhESLHFVYwSMu2BBl7PUFtxuIJvoUjg/ Quobd0EvE/2uzor4A8ocHjRQOrgS9w0mgDfV6veIpW3jjrLgT9rlomW6RJH8THoWiD7C lUdgcvrVAPIr8jRASM/idz6NY4uivs5Xzp2FVgwqq3TAj0nlek3ltJopwLx+Iv7elcnl H8QK6C6Mra3i9DSfyYvrTRnKIwXfQoWLJNgW5m2kozZIoYFQDc9yiElawLmLENhTT3Cn BvawA8AlM44wOz2fUJZJqy4QOho4OTs9xguLZ3ajC8daWkbkbZcdOp6i5lawQa1PV1yT BwvA== X-Gm-Message-State: ALoCoQkhotbgtwnP8TiDYD5mZ4Wni4id50rcAD2TVC80fX4zgIsWEP+LPNXoVBEHBP7rF6Yvj6k5 MIME-Version: 1.0 X-Received: by 10.50.117.106 with SMTP id kd10mr1228142igb.5.1411061779654; Thu, 18 Sep 2014 10:36:19 -0700 (PDT) Received: by 10.64.118.67 with HTTP; Thu, 18 Sep 2014 10:36:19 -0700 (PDT) In-Reply-To: References: <53F60830.3020506@qti.qualcomm.com> <34C30BB8-CCC1-45FD-9BD8-7DAF9EDEF36C@nominet.org.uk> Date: Thu, 18 Sep 2014 10:36:19 -0700 Message-ID: From: Anthony Mancuso To: Don Joslyn Content-Type: multipart/alternative; boundary=089e0139fb62220ec505035a6c73 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/JYC3Yr_QXODZPc7h1QKsVw3jo0A Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] Please review IPR disclosure https://datatracker.ietf.org/ipr/2340/ X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2014 17:37:11 -0000 --089e0139fb62220ec505035a6c73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Note that the above Whitespace DB discovery patent application includes a reference to a companion Whitespace *protocol* discovery application: "White space database protocol discovery is further described with reference to U.S. patent application Ser. No. 13/339,036 filed Dec. 28, 2011, which is hereby incorporated by reference herein." Tony On Thu, Sep 18, 2014 at 5:45 AM, Don Joslyn wrote: > Try this link: > > > http://appft.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p= =3D1&u=3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&co1=3DAND&= d=3DPG01&s1=3D%22White+Space+database+discovery%22&OS=3D%22White+Space+data= base+discovery%22&RS=3D%22White+Space+database+discovery%22 > > Regards, > Don > > On Thu, Sep 18, 2014 at 3:16 AM, Ray Bellis > wrote: > >> >> On 21 Aug 2014, at 15:54, Pete Resnick wrote= : >> >> > PAWS participants: >> > >> > Somehow an IPR disclosure was filed on the PAWS protocol document for >> which we did not see an announcement: >> > >> > https://datatracker.ietf.org/ipr/2340/ >> > >> > As far as I can tell from the title (given that the referenced IP is a= n >> as-yet-unpublished patent), this applies to the database discovery porti= on >> of the protocol. Since we have removed much of that discussion, we expec= t >> mostly pre-configuration, and we have yet to (and may never) complete th= e >> actual database discovery work, I think this may have no effect on folks >> implementing the protocol. But I do need to confirm that the WG is aware= of >> this and still thinks it's OK to move forward with the protocol document= . >> > >> > If there are any objections to moving forward, I need to hear that >> immediately. >> > >> > However, I would like to hear an overt, "Yes, understood, and it's fin= e >> to move forward" from some folks who might be implementing the protocol. >> >> I=E2=80=99m unable to find the text of the Nokia application, so it=E2= =80=99s difficult >> to assess. >> >> I note that they=E2=80=99ve quoted an application date of 29 April 2013,= I=E2=80=99d be >> amazed if there isn=E2=80=99t some prior work relating to database disco= very (e.g. >> the OFCOM spec, or ETSI EN 301 598) although that does depend on exactly >> what mechanism it is they=E2=80=99re claiming. >> >> Given the WG's de-emphasis on DB discovery I see no reason to change >> course based on this. >> >> Ray >> >> >> >> _______________________________________________ >> 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 > > --089e0139fb62220ec505035a6c73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note that the above Whitespace DB discovery =C2=A0patent a= pplication includes a reference to a companion Whitespace protocol d= iscovery application:

"White space database protocol discovery= is further described with reference to U.S. patent application Ser. No. 13= /339,036 filed Dec. 28, 2011, which is hereby incorporated by reference her= ein."

Tony

On Thu, Sep 18, 2014 at 5:45 AM, Don Joslyn <dljoslyn@gm= ail.com> wrote:
Don

On Thu, Sep 18,= 2014 at 3:16 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:

On 21 Aug 2014, at 15:54, Pete Resnick <presnick@qti.qualcomm.com> wrote:

> PAWS participants:
>
> Somehow an IPR disclosure was filed on the PAWS protocol document for = which we did not see an announcement:
>
> h= ttps://datatracker.ietf.org/ipr/2340/
>
> As far as I can tell from the title (given that the referenced IP is a= n as-yet-unpublished patent), this applies to the database discovery portio= n of the protocol. Since we have removed much of that discussion, we expect= mostly pre-configuration, and we have yet to (and may never) complete the = actual database discovery work, I think this may have no effect on folks im= plementing the protocol. But I do need to confirm that the WG is aware of t= his and still thinks it's OK to move forward with the protocol document= .
>
> If there are any objections to moving forward, I need to hear that imm= ediately.
>
> However, I would like to hear an overt, "Yes, understood, and it&= #39;s fine to move forward" from some folks who might be implementing = the protocol.

I=E2=80=99m unable to find the text of the Nokia application, so it=E2=80= =99s difficult to assess.

I note that they=E2=80=99ve quoted an application date of 29 April 2013, I= =E2=80=99d be amazed if there isn=E2=80=99t some prior work relating to dat= abase discovery (e.g. the OFCOM spec, or ETSI EN 301 598) although that doe= s depend on exactly what mechanism it is they=E2=80=99re claiming.

Given the WG's de-emphasis on DB discovery I see no reason to change co= urse based on this.

Ray



_______________________________________________
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


--089e0139fb62220ec505035a6c73-- From nobody Thu Sep 18 11:22:04 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE26B1A0696 for ; Thu, 18 Sep 2014 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvnhzX8EPd0K for ; Thu, 18 Sep 2014 11:21:54 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C831A04AC for ; Thu, 18 Sep 2014 11:21:54 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so1871437ier.27 for ; Thu, 18 Sep 2014 11:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8eF1mHMqSQUXp6RcrHFUkgEK7yzOK8ZIV/DH0zGDduk=; b=iGZi1oEhJNfglX4p6Hh8mOAQF5n6/9NW9zsHJ5Uu2JRs16o4VtPeTC2AIfh+DwWMnu NImpOpWF3Ixp4jWlpzN/GSMLsAi2W/6w4HMhg/4WAXzupW0s1cnuJ3QLxyAE3PLW3nhV BToFoZXa0dMjXmDatL2ztcb5+cJHRDJv6xe1e1sc7wNauyw+tjT2t6rOlTnhwAD+DcBP dnAmM/4pP/iCkgUskteOLQWmGX1BOeBbJAbaNDgkj+iRE9Q8B8zVe0IFm86KV79M7nTm JsJZwhb/NqoJPvscIZqoVI7ClVdorYNseOVxx7Ubrhxck3CHAWGp2Hqrc5eGu53vKjq/ YbNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8eF1mHMqSQUXp6RcrHFUkgEK7yzOK8ZIV/DH0zGDduk=; b=XfM4SeV7M4KioJtPezqRVYuzp4MeMiKiIsrDvH0HN+j0LnOxo6QgTBqQiSEDZpSBfI 8Fioa6IR51Q9fl1ZgVsGU9HM5GivncCCqSi5kAAFOa/zes+2r+E8FNs1iCeIJEkdhQwm 77BSqENW9lzY/7K69L9hG3DGactP5UH8ckN90cKUIAm6zRpCxFybku4BR/V1xHx88Bn4 WWGEJ5VcK22Qlp+6HYEL2EF0nihnXrHw2sJBvVzcFPl74k1LCE275Ro7svDacEkormx6 8uwL6sbiuxn6l4+PynXg8yTB/zM9iYjWCcckidck54YzEL3reMEPtowWvS9iEv1gHJsW 9XUQ== X-Gm-Message-State: ALoCoQltYC/xNKJl7W+92pmChbrTFJ2uEFbOg4n6CMFmvG4cKWxrL6BmLadG3FyOOcPebKvB784X MIME-Version: 1.0 X-Received: by 10.50.72.73 with SMTP id b9mr21055393igv.0.1411064512387; Thu, 18 Sep 2014 11:21:52 -0700 (PDT) Received: by 10.64.118.67 with HTTP; Thu, 18 Sep 2014 11:21:52 -0700 (PDT) In-Reply-To: References: <53F60830.3020506@qti.qualcomm.com> <34C30BB8-CCC1-45FD-9BD8-7DAF9EDEF36C@nominet.org.uk> Date: Thu, 18 Sep 2014 11:21:52 -0700 Message-ID: From: Anthony Mancuso To: Don Joslyn Content-Type: multipart/alternative; boundary=047d7bdc1178043c3205035b0fe9 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/hhbClIOzaToFZRNSMeHXJswNO_M Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] Please review IPR disclosure https://datatracker.ietf.org/ipr/2340/ X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2014 18:21:56 -0000 --047d7bdc1178043c3205035b0fe9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As Peter pointed out, it appears the discovery application has been abandoned (I copied the following from the public PAIR -- Patent Application Retrieval System online): Application Number:13/490,187Customer Number:-Filing or 371 (c) Date: 06-06-2012Status:Abandoned -- Failure to Respond to an Office ActionApplica= tion Type:UtilityStatus Date:02-21-2014Examiner Name:SPIELER, WILLIAMLocation: [image: What is a Location?] ELECTRONICGroup Art Unit:2159Location Date:-Confirmation Number:1020Earlies= t Publication No:US 2013-0331117 A1Attorney Docket Number:042933/418872Earlie= st Publication Date:12-12-2013Class / Subclass:707/758Patent Number:-First Named Inventor:Michael Probasco , Bedford, TX (US) all InventorsIssue Date of Patent:-First Named Applicant:-AIA (First Inventor to File):NoEntity Status:Undiscounted ------------------------------ Title of Invention:METHOD AND APPARATUS FOR WHITE SPACE DATABASE DISCOVERY And the related protocol discovery patent application is listed on PAIR as rejected: Application Number:13/339,036Customer Number:-Filing or 371 (c) Date: 12-28-2011Status:Final Rejection MailedApplication Type:UtilityStatus Date: 09-04-2014Examiner Name:SPIELER, WILLIAMLocation: [image: What is a Location?] ELECTRONICGro= up Art Unit:2159Location Date:-Confirmation Number:7184Earliest Publication No= :US 2013-0173651 A1Attorney Docket Number:042933/412230Earliest Publication Date:07-04-2013Class / Subclass:707/769Patent Number:-First Named Inventor:Michael Scott Probasco , Bedford, TX (US) all InventorsIssue Date of Patent:-First Named Applicant:-AIA (First Inventor to File):NoEntity Status:Undiscounted ------------------------------ Title of Invention:METHOD AND APPARATUS FOR REGULATORY DATABASE PROTOCOL DISCOVERY On Thu, Sep 18, 2014 at 10:36 AM, Anthony Mancuso wrote: > Note that the above Whitespace DB discovery patent application includes = a > reference to a companion Whitespace *protocol* discovery application: > > "White space database protocol discovery is further described with > reference to U.S. patent application Ser. No. 13/339,036 filed Dec. 28, > 2011, which is hereby incorporated by reference herein." > > Tony > > On Thu, Sep 18, 2014 at 5:45 AM, Don Joslyn wrote: > >> Try this link: >> >> >> http://appft.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p= =3D1&u=3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&co1=3DAND&= d=3DPG01&s1=3D%22White+Space+database+discovery%22&OS=3D%22White+Space+data= base+discovery%22&RS=3D%22White+Space+database+discovery%22 >> >> Regards, >> Don >> >> On Thu, Sep 18, 2014 at 3:16 AM, Ray Bellis >> wrote: >> >>> >>> On 21 Aug 2014, at 15:54, Pete Resnick >>> wrote: >>> >>> > PAWS participants: >>> > >>> > Somehow an IPR disclosure was filed on the PAWS protocol document for >>> which we did not see an announcement: >>> > >>> > https://datatracker.ietf.org/ipr/2340/ >>> > >>> > As far as I can tell from the title (given that the referenced IP is >>> an as-yet-unpublished patent), this applies to the database discovery >>> portion of the protocol. Since we have removed much of that discussion,= we >>> expect mostly pre-configuration, and we have yet to (and may never) >>> complete the actual database discovery work, I think this may have no >>> effect on folks implementing the protocol. But I do need to confirm tha= t >>> the WG is aware of this and still thinks it's OK to move forward with t= he >>> protocol document. >>> > >>> > If there are any objections to moving forward, I need to hear that >>> immediately. >>> > >>> > However, I would like to hear an overt, "Yes, understood, and it's >>> fine to move forward" from some folks who might be implementing the >>> protocol. >>> >>> I=E2=80=99m unable to find the text of the Nokia application, so it=E2= =80=99s difficult >>> to assess. >>> >>> I note that they=E2=80=99ve quoted an application date of 29 April 2013= , I=E2=80=99d be >>> amazed if there isn=E2=80=99t some prior work relating to database disc= overy (e.g. >>> the OFCOM spec, or ETSI EN 301 598) although that does depend on exactl= y >>> what mechanism it is they=E2=80=99re claiming. >>> >>> Given the WG's de-emphasis on DB discovery I see no reason to change >>> course based on this. >>> >>> Ray >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > --047d7bdc1178043c3205035b0fe9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As Peter pointed out, it appears the discovery application= has been abandoned (I copied the following from the public PAIR -- Patent = Application Retrieval System online):

<= td class=3D"" headers=3D"r2c2" width=3D"263" style=3D"font-family:Verdana,A= rial,Helvetica,sans-serif;font-size:9pt;background-color:rgb(255,255,255)">= Abandoned -- Failure to Respond to an Office Action=
Application Number:13/490,187Custom= er Number:-
Filing or= 371 (c) Date:06-06-2012Status:
Application Type:UtilityStatus Date:02-21-2014
Examiner Name:SPIELER, WILLIAMLocation:=C2=A03D"WhatELECTRONIC
Group Art Unit:2159Location Date:-
Confirmation Number:1020US 2013-0331117 A1
Attorney Docket Number:042933= /418872Earliest Publication Date:12-12-2013
Class / Subclass:707/758Patent Number:-
First Named Inventor:Mich= ael Probasco , Bedford, TX (US)=C2=A0all InventorsIssue Date of Patent:-
First Named Applicant= :-AIA (First Inventor to File):= No
Entity Status:Undiscounted
<= /tbody>
Title of Invention:METHOD AND APPARATUS FOR WHITE SPACE DATABASE DISCOVERY

And the related protocol disc= overy patent application is listed on PAIR as rejected:

<= td align=3D"left" class=3D"" id=3D"r2c2" width=3D"194" style=3D"font-family= :Verdana,Arial,Helvetica,sans-serif;font-size:9pt;background-color:rgb(236,= 236,236)">Status:Examiner Name:=
Application Number:13/339,0= 36Customer Number:-
Filing or 371 (c) Date:12-28-2011Final Rejection Mailed
Application Type:UtilityStatus Date:09-04-2014
SPIELER, WILLIAM3D"WhatELECTRONIC
Group Art Unit:= 2159Location Date:-
Confirmation Number:7184US 2013-0173651 A1
Attorney Docket Number:042933= /412230Earliest Publication Date:07-04-2013
Class / Subclass:707/769Patent Number:-
First Named Inventor:Mich= ael Scott Probasco , Bedford, TX (US)=C2=A0all InventorsIssue Date of Patent:-
First Named Ap= plicant:-AIA (First Inventor t= o File):No
Entity St= atus:Undiscounted
Title of Invention:
METHOD AND APPARATUS FOR REGULATORY DATABASE PROTOCOL DISC= OVERY



On= Thu, Sep 18, 2014 at 10:36 AM, Anthony Mancuso <amancuso@google.com= > wrote:
Note = that the above Whitespace DB discovery =C2=A0patent application includes a = reference to a companion Whitespace protocol discovery application: =

"White space database protocol discovery is further described = with reference to U.S. patent application Ser. No. 13/339,036 filed Dec. 28= , 2011, which is hereby incorporated by reference herein."

Tony=

On Thu, Sep 18, 2014 at 5:45 AM, Don Josly= n <dljoslyn@gmail.com> wrote:
Regards,
Don

On Thu, Sep 18, 2014 at 3:1= 6 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:<= br>

On 21 Aug 2014, at 15:54, Pete Resnick <presnick@qti.qualcomm.com> wrote:

> PAWS participants:
>
> Somehow an IPR disclosure was filed on the PAWS protocol document for = which we did not see an announcement:
>
> h= ttps://datatracker.ietf.org/ipr/2340/
>
> As far as I can tell from the title (given that the referenced IP is a= n as-yet-unpublished patent), this applies to the database discovery portio= n of the protocol. Since we have removed much of that discussion, we expect= mostly pre-configuration, and we have yet to (and may never) complete the = actual database discovery work, I think this may have no effect on folks im= plementing the protocol. But I do need to confirm that the WG is aware of t= his and still thinks it's OK to move forward with the protocol document= .
>
> If there are any objections to moving forward, I need to hear that imm= ediately.
>
> However, I would like to hear an overt, "Yes, understood, and it&= #39;s fine to move forward" from some folks who might be implementing = the protocol.

I=E2=80=99m unable to find the text of the Nokia application, so it=E2=80= =99s difficult to assess.

I note that they=E2=80=99ve quoted an application date of 29 April 2013, I= =E2=80=99d be amazed if there isn=E2=80=99t some prior work relating to dat= abase discovery (e.g. the OFCOM spec, or ETSI EN 301 598) although that doe= s depend on exactly what mechanism it is they=E2=80=99re claiming.

Given the WG's de-emphasis on DB discovery I see no reason to change co= urse based on this.

Ray



_______________________________________________
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



--047d7bdc1178043c3205035b0fe9-- From nobody Mon Sep 22 00:12:57 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AEF1A1A38; Mon, 22 Sep 2014 00:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20x7siSgMjOz; Mon, 22 Sep 2014 00:12:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E81951A1A42; Mon, 22 Sep 2014 00:12:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922071248.18646.80444.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 00:12:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/j7swN6hb2oyrrdJXjMLlgnBGnRQ Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-18.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 07:12:52 -0000 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) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-18.txt Pages : 91 Date : 2014-09-22 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 managing 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 (PAWS) Databases". 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 22 00:12:59 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E43B1A1A42 for ; Mon, 22 Sep 2014 00:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqz5VYiKlMDf; Mon, 22 Sep 2014 00:12:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06E1A1A46; Mon, 22 Sep 2014 00:12:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org, paws@ietf.org, presnick@qti.qualcomm.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922071249.18646.74386.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 00:12:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/obKbmSlZd72xjITRdsHB8b-uq6c Subject: [paws] New Version Notification - draft-ietf-paws-protocol-18.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 07:12:53 -0000 A new version (-18) has been submitted for draft-ietf-paws-protocol: http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-18.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Sep 22 00:17:03 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4041A1A4E for ; Mon, 22 Sep 2014 00:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.536 X-Spam-Level: X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0W4rRIdHkBg for ; Mon, 22 Sep 2014 00:16:57 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519211A1A40 for ; Mon, 22 Sep 2014 00:16:57 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hq11so3748200vcb.39 for ; Mon, 22 Sep 2014 00:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NEiYcABNz2xPX56GVmHUaBzGhVp/troI/fn2fP6iI48=; b=lZU22bqg4vZg5knetTSPbz2CfiwMdGFx9gVvy/KB9ZYL+wxZGTcu+GzhGVwWgwv3Q7 sP8vpkZJerPxbyB++pCVhXVMur14VSBtr4ff3cKa/eV4WxvFFdLi8407bf+LEJfqZV6O Erq7AObELxglOgUyh+1iB5Te/TkatG582ffT4iRu1eAFUKZ7UgNPgpTPq5rLJun6bHXl PLz6H3BV7eeGUf/+M/6pUriCskErf3cV2O66ZmM1re7tbQFyO8WcwqeZy+WTTjDtRZj+ +5vc24AzViSXA+SCEtOOkZKP5JYjTqGC+ydCU8wk7WoqA2v3eMueyWwyQQXVDfSmnwrt F09g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NEiYcABNz2xPX56GVmHUaBzGhVp/troI/fn2fP6iI48=; b=QsIwX6BN923tBE9xrc1at8vEW2U/5UErL0AqNjUlrtzDlp8a62/+IIX7MXapdLcRN0 tP4NQ7InMCAljryFoU8yLN5L853/dsZt5vBPhGuELR8FbpXY7moDRH8d0aEfp5Q5w6kT ZzptUON6EHoyT4mH5HfjsFWykNv3GxTYbULZJbjsrZY4S3FuCfwo0hXHLHD7HSqM51th 6w4S8Fn7sgVi8OohxSpbd0dZmWThlYbZp7Kjcn9r2evP+I/+tkPVIb+RSIhmaVRSxb0S c+8WtJplsZg2hEntJp6fS+PZQC6v5xDrmBtZb/znT+mqEamAqIL7aGqH3iPCgMsSoR12 LMSg== X-Gm-Message-State: ALoCoQmmsNlOSKUgeZSyvmNB1UPhdyVUq1Vho8xtdahiHCmYhjBIor9orlhG8g6eQDKgeQFueWlc MIME-Version: 1.0 X-Received: by 10.220.74.10 with SMTP id s10mr5558596vcj.61.1411370216422; Mon, 22 Sep 2014 00:16:56 -0700 (PDT) Received: by 10.52.236.232 with HTTP; Mon, 22 Sep 2014 00:16:56 -0700 (PDT) In-Reply-To: References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 00:16:56 -0700 Message-ID: From: Vincent Chen To: Alissa Cooper Content-Type: multipart/alternative; boundary=e89a8f64719365946c0503a23c26 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/lu1kddbAebuerQFEwHgh_X6Rxaw Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 22 Sep 2014 07:17:01 -0000 --e89a8f64719365946c0503a23c26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alissa, Sorry for the delayed response. I've uploaded draft 18, incorporating your suggestions. I've simplified the text a bit, but, hopefully, it addresses your concerns. Please let me know what you think. http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-18 Thanks. -vince On Fri, Sep 12, 2014 at 9:03 AM, Alissa Cooper wrote: > Hi Vincent, > > I=E2=80=99ve taken a look at the =E2=80=9317. Thanks for accommodating ma= ny of my DISCUSS > points. I have a one response below on a couple of remaining issues. > > On 8/21/14, 12:59 AM, "Vincent Chen" wrote: > > > >> =3D Section 5.1 =3D >> I'd like to discuss why the single point location format needs to be >> supported here. Is it really the case that a portion of whitespace >> spectrum will ever be available only at a single point, as opposed to a >> region? If not, it seems like sending a point (and, moreover, allowing >> region to be unsupported but not point) divulges more precise informatio= n >> about the requesting device than is ever actually necessary to fulfill >> the goals of this protocol. Do regulators require a single point? Why? >> > > The resulting spectrum is valid for 100m (typically) radius around that > point. > > Computation of available spectrum for a region is actually complex and no= t > well defined... > > >> >> =3D Section 5.2 =3D >> I'd like to discuss why the device serial number needs to be included in >> the device descriptor, rather than some (perhaps persistent) randomly >> generated device identifier that is used only in the context of this >> protocol (which would better protect the privacy of the user of the >> device, since the whitespaces database administrator wouldn't be able to >> correlate the device's spectrum requests with other activities linked to >> the serial number). It's not really clear why serial number is collected >> since both this document and RFC 6953 note the protocol does not defend >> against abuse or mis-use of spectrum. >> > > The regulator want to have the ability to black list ranges of serial > numbers, if it > determines that a series was defective. The Databases must use the serial > number > to determine it can return available spectrum. > > >> >> I'm asking the above two questions in light of requirement P.7 from RFC >> 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of >> device-provided data where such protection is feasible, allowed, and >> desired." >> >> A separate interesting question that does not seem to be addressed >> anywhere in the draft is whether a device can be fingerprinted by the >> database operator by virtue of the collection of elements it sends >> (rulesetIds, manufacturer, model, antenna characteristics, device >> capabilities, etc.) even if it doesn't send a serial number or device >> owner information that uniquely identify it. That seems worth discussion >> in Section 10. >> > > What should the discussion say? Just that it is possible? or does it need > to have a solution? > > > Now that the document is clear that Slave device location and serial > number are optional (unless required by a ruleset), I think the remaining > task on the above three points is to add a bit of text to Section 10 to > explain the potential privacy threats from authorized databases, perhaps = as > a short paragraph or two at the end of Section 10. Something along these > lines (just a suggestion, feel free to reject this entirely or use bits > that you like): > > "In addition to the privacy risks described above, in some cases, users o= f > Master or Slave devices may open themselves up to privacy risks related t= o > the secondary use of PAWS-related information by a database administrator= . > For example, in situations where rulesets require that Master or Slave > devices uniquely identify themselves (via the DeviceDescriptor or > DeviceOwner parameters), database administrators may be able to use that > information to track connectivity activity over time, or they may share > such tracking information with third parties. Where Master or Slave devic= es > choose to provide or are required to provide geolocation information in > conjunction with unique device identifiers, this capability may further > extent to location tracking. Even where a device does not provide a > specific unique identifier, a database administrator may be able to > uniquely fingerprint a device based on the combination of other informati= on > provided in DeviceDescriptor or DeviceCapabilities parameters. > > In cases where devices have a choice to not send device-identifying > information or geolocation, or to send less granular geolocation (i.e., a > region rather than a point), PAWS implementations can reduce the risks > associated with secondary use by not sending that information. Where > rulesets require this information to be sent, these risks require > out-of-band mitigation (e.g., public statements or contractual terms > preventing secondary use).=E2=80=9D > > Thanks, > Alissa > > > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> =3D Shepherd write-up=3D >> "An in-depth review by a JSON expert might be useful." >> >> Did that happen? >> > > Tim Bray had looked at it before final call. > > >> >> =3D Section 1 =3D >> "It opens the door for innovations in spectrum >> management that can incorporate a variety of parameters, including >> user location and time. In the future, it also can include other >> parameters, such as user priority, time, signal type and power, >> spectrum supply and demand, payment or micro-auction bidding, and >> more." >> >> Time seems to be listed both as a current parameter and a future one, >> which is confusing. >> > > Agreed. The second "time" should be removed. > > >> >> =3D Section 4.4 =3D >> "FCC rules, for example, require that a 'Fixed Device' >> register its owner and operator contact information, its device >> identifier, its location, and its antenna height." >> >> It would be nice to have a citation for the rules referenced here. >> > > OK. > > >> >> =3D Section 5.1 =3D >> Feel free to ignore this if it's completely misguided, but does altitude >> really not matter? Are we sure this protocol won't be re-used for device= s >> on airplanes trying to find available spectrum? (I note that in RFC 6953= , >> requirement D.1 specifies that the data model must support "the height >> and its uncertainty" -- I have no idea what "the height" means or if it >> is related to altitude.) >> > > See Section 5.3 on "height" of the antenna. It's separated out, from the > "latitude, longitude" specification > of GeoLocation. It allows specification with respect to ground level or > mean sea level, and is intended > for Fixed devices, rather than mobile devices. > > From the current regulator's perspective, the allowed power for mobile > devices is low enough that > height does not matter. > > > >> >> =3D Section 10 =3D >> I agree with Stephen that the database operator should be considered as = a >> potential adversary from the standpoint of potentially being able to >> create a fine-grained database that tracks the locations and spectrum us= e >> patterns of individual devices. That data could certainly be abused. >> >> > So just listing that as a potential threat and declare that fixing this a= s > out of scope is sufficient? > > Or do we need to state that Databases MUST not track? I can see how > anonymized tracking > can be useful for spectrum management in the future, much like anonymized > tracking of car locations > provide valuable traffic information for navigation systems. > > -- > -vince > > --=20 -vince --e89a8f64719365946c0503a23c26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alissa,

Sorry for the delayed respon= se. I've uploaded draft 18, incorporating your suggestions. I've si= mplified the text a bit, but, hopefully, it addresses your concerns. Please= let me know what you think.


= Thanks.

-vince

On Fri, Sep 12, 2014 at 9:03 AM, Alissa C= ooper <alissa@cooperw.in> wrote:
Hi Vincent,

I= =E2=80=99ve taken a look at the =E2=80=9317. Thanks for accommodating many = of my DISCUSS points. I have a one response below on a couple of remaining = issues.

On 8/21/= 14, 12:59 AM, "Vincent Chen" <vchen@google.com> wrote:

<= /div>


=3D Section 5.1 =3D
I'd like to discuss why the single point location format needs to be supported here. Is it really the case that a portion of whitespace
spectrum will ever be available only at a single point, as opposed to a
region? If not, it seems like sending a point (and, moreover, allowing
region to be unsupported but not point) divulges more precise information about the requesting device than is ever actually necessary to fulfill
the goals of this protocol. Do regulators require a single point? Why?
<= /blockquote>

The resulting spectrum is valid for 100m (t= ypically) radius around that point.

Computation of= available spectrum for a region is actually complex and not well defined..= .
=C2=A0

=3D Section 5.2 =3D
I'd like to discuss why the device serial number needs to be included i= n
the device descriptor, rather than some (perhaps persistent) randomly
generated device identifier that is used only in the context of this
protocol (which would better protect the privacy of the user of the
device, since the whitespaces database administrator wouldn't be able t= o
correlate the device's spectrum requests with other activities linked t= o
the serial number). It's not really clear why serial number is collecte= d
since both this document and RFC 6953 note the protocol does not defend
against abuse or mis-use of spectrum.

T= he regulator want to have the ability to black list ranges of serial number= s, if it
determines that a series was defective. The Databases mu= st use the serial number
to determine it can return available spe= ctrum.
=C2=A0

I'm asking the above two questions in light of requirement P.7 from RFC=
6953, "The PAWS protocol SHOULD support privacy-sensitive handling of<= br> device-provided data where such protection is feasible, allowed, and
desired."

A separate interesting question that does not seem to be addressed
anywhere in the draft is whether a device can be fingerprinted by the
database operator by virtue of the collection of elements it sends
(rulesetIds, manufacturer, model, antenna characteristics, device
capabilities, etc.) even if it doesn't send a serial number or device owner information that uniquely identify it. That seems worth discussion in Section 10.

What should the discussi= on say? Just that it is possible? or does it need
to have a solut= ion?

=
Now that the document is clear that Slave device location and serial n= umber are optional (unless required by a ruleset), I think the remaining ta= sk on the above three points is to add a bit of text to Section 10 to expla= in the potential privacy threats from authorized databases, perhaps as a sh= ort paragraph or two at the end of Section 10. Something along these lines = (just a suggestion, feel free to reject this entirely or use bits that you = like):

"In addition to the privacy risks desc= ribed above, in some cases, users of Master or Slave devices may open thems= elves up to privacy risks related to the secondary use of PAWS-related info= rmation by a database administrator. For example, in situations where rules= ets require that Master or Slave devices uniquely identify themselves (via = the DeviceDescriptor or DeviceOwner parameters), database administrators ma= y be able to use that information to track connectivity activity over time,= or they may share such tracking information with third parties. Where Mast= er or Slave devices choose to provide or are required to provide geolocatio= n information in conjunction with unique device identifiers, this capabilit= y may further extent to location tracking. Even where a device does not pro= vide a specific unique identifier, a database administrator may be able to = uniquely fingerprint a device based on the combination of other information= provided in DeviceDescriptor or DeviceCapabilities parameters.=C2=A0
=

In cases where devices have a choice to not send device= -identifying information or geolocation, or to send less granular geolocati= on (i.e., a region rather than a point), PAWS implementations can reduce th= e risks associated with secondary use by not sending that information. Wher= e rulesets require this information to be sent, these risks require out-of-= band mitigation (e.g., public statements or contractual terms preventing se= condary use).=E2=80=9D

Thanks,
Alissa

=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
<= br> =3D Shepherd write-up=3D
"An in-depth review by a JSON expert might be useful."

Did that happen?

Tim Bray had looked at= it before final call.
=C2=A0

=3D Section 1 =3D
"It opens the door for innovations in spectrum
=C2=A0 =C2=A0management that can incorporate a variety of parameters, inclu= ding
=C2=A0 =C2=A0user location and time.=C2=A0 In the future, it also can inclu= de other
=C2=A0 =C2=A0parameters, such as user priority, time, signal type and power= ,
=C2=A0 =C2=A0spectrum supply and demand, payment or micro-auction bidding, = and
=C2=A0 =C2=A0more."

Time seems to be listed both as a current parameter and a future one,
which is confusing.

Agreed. The second = "time" should be removed.
=C2=A0

=3D Section 4.4 =3D
"FCC rules, for example, require that a 'Fixed Device'
=C2=A0 =C2=A0register its owner and operator contact information, its devic= e
=C2=A0 =C2=A0identifier, its location, and its antenna height."
It would be nice to have a citation for the rules referenced here.

OK.
=C2=A0

=3D Section 5.1 =3D
Feel free to ignore this if it's completely misguided, but does altitud= e
really not matter? Are we sure this protocol won't be re-used for devic= es
on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height=
and its uncertainty" -- I have no idea what "the height" mea= ns or if it
is related to altitude.)

See Section 5.= 3 on "height" of the antenna. It's separated out, from the &q= uot;latitude, longitude" specification
of GeoLocation. It al= lows specification with respect to ground level or mean sea level, and is i= ntended
for Fixed devices, rather than mobile devices.
=
From the current regulator's perspective, the allowed po= wer for mobile devices is low enough that
height does not matter.=

=C2=A0

=3D Section 10 =3D
I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to
create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused.

So just listing that as a potential threa= t and declare that fixing this as out of scope is sufficient?=C2=A0

Or do we need to state that Databases MUST not track? I can see how= anonymized tracking
can be useful for spec= trum management in the future, much like anonymized tracking of car locatio= ns
provide valuable traffic information for= navigation systems.

--
-vince



--
-vince --e89a8f64719365946c0503a23c26-- From nobody Tue Sep 23 13:01:46 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1AC1A88B8 for ; Tue, 23 Sep 2014 13:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEAsvMNfDeMV for ; Tue, 23 Sep 2014 13:01:30 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4191A1BE0 for ; Tue, 23 Sep 2014 13:01:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id 7E9322126E for ; Tue, 23 Sep 2014 16:01:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 23 Sep 2014 16:01:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type; s=mesmtp; bh=y7Tk5PFiFXo9lfRhqO86wOU D/PM=; b=F4U9TwEllTYCrVxwo0HeVW54yzxnZ5AiZSainaFaNEmuw+6dBsTNIqv FzxBSqsq6RsfJjmbVvoJDOjy6GvsD5eXHV3wnGesnJgOUogBbcDjckBmDoTxiMzZ 9QddOxUZ9P0x/1o0S7DLH4I1U7Xc4XPY6Z52PJhC0BsxzZDngd48= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type; s=smtpout; bh=y7Tk5PFiFXo9lfRhqO86wOUD/PM=; b=gsiRuBTXl8NbvsIAQ5/eX6HAWSq4 WOJKIimd/HxwKv53HcwbklmkoIGhh7P7Sfca5S2/mrbR9HWZV9XXMaN9+GimSaTh sm15RjbvLQQIdfGyO9Aj2W8PPsr6dIIyPllhUpeOIoeleO1XrwOQQaIEe4q5r2fq OByyZVeO7Yo5s/8= X-Sasl-enc: xw8n/BGQZfAClmhJUVNDthICsk4dyJK+VW8qfqRbpz9z 1411502481 Received: from [171.68.18.45] (unknown [171.68.18.45]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B3B06801E2; Tue, 23 Sep 2014 16:01:17 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Tue, 23 Sep 2014 13:01:12 -0700 From: Alissa Cooper To: Vincent Chen Message-ID: Thread-Topic: Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3494322081_6454662" Archived-At: http://mailarchive.ietf.org/arch/msg/paws/aP2LC3-2mjwuA3PshELwkJDIRb8 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2014 20:01:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3494322081_6454662 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Vince, Thanks. I like the text you added, but I think the bit about fingerprinting and the caution to implementations about not over-sharing that I had suggested are both important =E2=80=94 any reason not to include them explicitly? Alissa On 9/22/14, 12:16 AM, "Vincent Chen" wrote: > Hi Alissa, >=20 > Sorry for the delayed response. I've uploaded draft 18, incorporating you= r > suggestions. I've simplified the text a bit, but, hopefully, it addresses= your > concerns. Please let me know what you think. >=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-18 >=20 > Thanks. >=20 > -vince >=20 > On Fri, Sep 12, 2014 at 9:03 AM, Alissa Cooper wrote: >> Hi Vincent, >>=20 >> I=E2=80=99ve taken a look at the =E2=80=9317. Thanks for accommodating many of my DI= SCUSS >> points. I have a one response below on a couple of remaining issues. >>=20 >> On 8/21/14, 12:59 AM, "Vincent Chen" wrote: >>=20 >>>=20 >>>>=20 >>>> =3D Section 5.1 =3D >>>> I'd like to discuss why the single point location format needs to be >>>> supported here. Is it really the case that a portion of whitespace >>>> spectrum will ever be available only at a single point, as opposed to = a >>>> region? If not, it seems like sending a point (and, moreover, allowing >>>> region to be unsupported but not point) divulges more precise informat= ion >>>> about the requesting device than is ever actually necessary to fulfill >>>> the goals of this protocol. Do regulators require a single point? Why? >>>=20 >>> The resulting spectrum is valid for 100m (typically) radius around that >>> point. >>>=20 >>> Computation of available spectrum for a region is actually complex and = not >>> well defined... >>> =20 >>>>=20 >>>> =3D Section 5.2 =3D >>>> I'd like to discuss why the device serial number needs to be included = in >>>> the device descriptor, rather than some (perhaps persistent) randomly >>>> generated device identifier that is used only in the context of this >>>> protocol (which would better protect the privacy of the user of the >>>> device, since the whitespaces database administrator wouldn't be able = to >>>> correlate the device's spectrum requests with other activities linked = to >>>> the serial number). It's not really clear why serial number is collect= ed >>>> since both this document and RFC 6953 note the protocol does not defen= d >>>> against abuse or mis-use of spectrum. >>>=20 >>> The regulator want to have the ability to black list ranges of serial >>> numbers, if it >>> determines that a series was defective. The Databases must use the seri= al >>> number >>> to determine it can return available spectrum. >>> =20 >>>>=20 >>>> I'm asking the above two questions in light of requirement P.7 from RF= C >>>> 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of >>>> device-provided data where such protection is feasible, allowed, and >>>> desired." >>>>=20 >>>> A separate interesting question that does not seem to be addressed >>>> anywhere in the draft is whether a device can be fingerprinted by the >>>> database operator by virtue of the collection of elements it sends >>>> (rulesetIds, manufacturer, model, antenna characteristics, device >>>> capabilities, etc.) even if it doesn't send a serial number or device >>>> owner information that uniquely identify it. That seems worth discussi= on >>>> in Section 10. >>>=20 >>> What should the discussion say? Just that it is possible? or does it ne= ed >>> to have a solution? >>=20 >> Now that the document is clear that Slave device location and serial num= ber >> are optional (unless required by a ruleset), I think the remaining task = on >> the above three points is to add a bit of text to Section 10 to explain = the >> potential privacy threats from authorized databases, perhaps as a short >> paragraph or two at the end of Section 10. Something along these lines (= just >> a suggestion, feel free to reject this entirely or use bits that you lik= e): >>=20 >> "In addition to the privacy risks described above, in some cases, users = of >> Master or Slave devices may open themselves up to privacy risks related = to >> the secondary use of PAWS-related information by a database administrato= r. >> For example, in situations where rulesets require that Master or Slave >> devices uniquely identify themselves (via the DeviceDescriptor or Device= Owner >> parameters), database administrators may be able to use that information= to >> track connectivity activity over time, or they may share such tracking >> information with third parties. Where Master or Slave devices choose to >> provide or are required to provide geolocation information in conjunctio= n >> with unique device identifiers, this capability may further extent to >> location tracking. Even where a device does not provide a specific uniqu= e >> identifier, a database administrator may be able to uniquely fingerprint= a >> device based on the combination of other information provided in >> DeviceDescriptor or DeviceCapabilities parameters. >>=20 >> In cases where devices have a choice to not send device-identifying >> information or geolocation, or to send less granular geolocation (i.e., = a >> region rather than a point), PAWS implementations can reduce the risks >> associated with secondary use by not sending that information. Where rul= esets >> require this information to be sent, these risks require out-of-band >> mitigation (e.g., public statements or contractual terms preventing seco= ndary >> use).=E2=80=9D >>=20 >> Thanks, >> Alissa >>=20 >>> =20 >>>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> =3D Shepherd write-up=3D >>>> "An in-depth review by a JSON expert might be useful." >>>>=20 >>>> Did that happen? >>>=20 >>> Tim Bray had looked at it before final call. >>> =20 >>>>=20 >>>> =3D Section 1 =3D >>>> "It opens the door for innovations in spectrum >>>> management that can incorporate a variety of parameters, including >>>> user location and time. In the future, it also can include other >>>> parameters, such as user priority, time, signal type and power, >>>> spectrum supply and demand, payment or micro-auction bidding, and >>>> more." >>>>=20 >>>> Time seems to be listed both as a current parameter and a future one, >>>> which is confusing. >>>=20 >>> Agreed. The second "time" should be removed. >>> =20 >>>>=20 >>>> =3D Section 4.4 =3D >>>> "FCC rules, for example, require that a 'Fixed Device' >>>> register its owner and operator contact information, its device >>>> identifier, its location, and its antenna height." >>>>=20 >>>> It would be nice to have a citation for the rules referenced here. >>>=20 >>> OK. >>> =20 >>>>=20 >>>> =3D Section 5.1 =3D >>>> Feel free to ignore this if it's completely misguided, but does altitu= de >>>> really not matter? Are we sure this protocol won't be re-used for devi= ces >>>> on airplanes trying to find available spectrum? (I note that in RFC 69= 53, >>>> requirement D.1 specifies that the data model must support "the height >>>> and its uncertainty" -- I have no idea what "the height" means or if i= t >>>> is related to altitude.) >>>=20 >>> See Section 5.3 on "height" of the antenna. It's separated out, from th= e >>> "latitude, longitude" specification >>> of GeoLocation. It allows specification with respect to ground level or= mean >>> sea level, and is intended >>> for Fixed devices, rather than mobile devices. >>>=20 >>> From the current regulator's perspective, the allowed power for mobile >>> devices is low enough that >>> height does not matter. >>>=20 >>> =20 >>>>=20 >>>> =3D Section 10 =3D >>>> I agree with Stephen that the database operator should be considered a= s a >>>> potential adversary from the standpoint of potentially being able to >>>> create a fine-grained database that tracks the locations and spectrum = use >>>> patterns of individual devices. That data could certainly be abused. >>>>=20 >>>=20 >>> So just listing that as a potential threat and declare that fixing this= as >>> out of scope is sufficient? >>>=20 >>> Or do we need to state that Databases MUST not track? I can see how >>> anonymized tracking >>> can be useful for spectrum management in the future, much like anonymiz= ed >>> tracking of car locations >>> provide valuable traffic information for navigation systems. >>>=20 >>> --=20 >>> -vince=20 >=20 >=20 >=20 > --=20 > -vince=20 --B_3494322081_6454662 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Vince,

Thanks. I like the text you added, but I think the bit about fingerpri= nting and the caution to implementations about not over-sharing that I had s= uggested are both important — any reason not to include them explicitl= y?

Alissa

On 9/22/14, 12:16 AM, "Vincent Chen" <vchen@google.com> wrote:

Hi Alissa,
Sorry for the delayed response. I've uploaded draft 18, in= corporating your suggestions. I've simplified the text a bit, but, hopefully= , it addresses your concerns. Please let me know what you think.
<= br>

Thanks.

-vince

On Fri, Sep 12, 2014= at 9:03 AM, Alissa Cooper <alissa@cooperw.in> wrote:
Hi Vincent,

I’ve taken a look at the –17. Thanks for accommodating many of= my DISCUSS points. I have a one response below on a couple of remaining iss= ues.

On 8/21/14, 12= :59 AM, "Vincent Chen" <vchen@google.com> wrote:



=3D Section 5.1 =3D
I'd like to discuss why the single point location format needs to be
supported here. Is it really the case that a portion of whitespace
spectrum will ever be available only at a single point, as opposed to a
= region? If not, it seems like sending a point (and, moreover, allowing
region to be unsupported but not point) divulges more precise information about the requesting device than is ever actually necessary to fulfill
the goals of this protocol. Do regulators require a single point? Why?
<= /blockquote>

The resulting spectrum is valid for 100m (ty= pically) radius around that point.

Computation of a= vailable spectrum for a region is actually complex and not well defined...
 

=3D Section 5.2 =3D
I'd like to discuss why the device serial number needs to be included in the device descriptor, rather than some (perhaps persistent) randomly
generated device identifier that is used only in the context of this
protocol (which would better protect the privacy of the user of the
device, since the whitespaces database administrator wouldn't be able to correlate the device's spectrum requests with other activities linked to the serial number). It's not really clear why serial number is collected since both this document and RFC 6953 note the protocol does not defend
= against abuse or mis-use of spectrum.

T= he regulator want to have the ability to black list ranges of serial numbers= , if it
determines that a series was defective. The Databases must= use the serial number
to determine it can return available spectr= um.
 

I'm asking the above two questions in light of requirement P.7 from RFC
= 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of
device-provided data where such protection is feasible, allowed, and
desired."

A separate interesting question that does not seem to be addressed
anywhere in the draft is whether a device can be fingerprinted by the
database operator by virtue of the collection of elements it sends
(rulesetIds, manufacturer, model, antenna characteristics, device
capabilities, etc.) even if it doesn't send a serial number or device
owner information that uniquely identify it. That seems worth discussion in Section 10.

What should the discussi= on say? Just that it is possible? or does it need
to have a soluti= on?

Now that the document is clear that Slave device location and serial numb= er are optional (unless required by a ruleset), I think the remaining task o= n the above three points is to add a bit of text to Section 10 to explain th= e potential privacy threats from authorized databases, perhaps as a short pa= ragraph or two at the end of Section 10. Something along these lines (just a= suggestion, feel free to reject this entirely or use bits that you like):

"In addition to the privacy risks described above, i= n some cases, users of Master or Slave devices may open themselves up to pri= vacy risks related to the secondary use of PAWS-related information by a dat= abase administrator. For example, in situations where rulesets require that = Master or Slave devices uniquely identify themselves (via the DeviceDescript= or or DeviceOwner parameters), database administrators may be able to use th= at information to track connectivity activity over time, or they may share s= uch tracking information with third parties. Where Master or Slave devices c= hoose to provide or are required to provide geolocation information in conju= nction with unique device identifiers, this capability may further extent to= location tracking. Even where a device does not provide a specific unique i= dentifier, a database administrator may be able to uniquely fingerprint a de= vice based on the combination of other information provided in DeviceDescrip= tor or DeviceCapabilities parameters. 

In case= s where devices have a choice to not send device-identifying information or = geolocation, or to send less granular geolocation (i.e., a region rather tha= n a point), PAWS implementations can reduce the risks associated with second= ary use by not sending that information. Where rulesets require this informa= tion to be sent, these risks require out-of-band mitigation (e.g., public st= atements or contractual terms preventing secondary use).”
Thanks,
Alissa

 


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
<= br> =3D Shepherd write-up=3D
"An in-depth review by a JSON expert might be useful."

Did that happen?

Tim Bray had looked at= it before final call.
 

=3D Section 1 =3D
"It opens the door for innovations in spectrum
   management that can incorporate a variety of parameters, inclu= ding
   user location and time.  In the future, it also can inclu= de other
   parameters, such as user priority, time, signal type and power= ,
   spectrum supply and demand, payment or micro-auction bidding, = and
   more."

Time seems to be listed both as a current parameter and a future one,
which is confusing.

Agreed. The second = "time" should be removed.
 
=3D Section 4.4 =3D
"FCC rules, for example, require that a 'Fixed Device'
   register its owner and operator contact information, its devic= e
   identifier, its location, and its antenna height."

It would be nice to have a citation for the rules referenced here.

OK.
 

=3D Section 5.1 =3D
Feel free to ignore this if it's completely misguided, but does altitude really not matter? Are we sure this protocol won't be re-used for devices on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height
and its uncertainty" -- I have no idea what "the height" means or if it
= is related to altitude.)

See Section 5.= 3 on "height" of the antenna. It's separated out, from the "latitude, longit= ude" specification
of GeoLocation. It allows specification with re= spect to ground level or mean sea level, and is intended
for Fixed= devices, rather than mobile devices.

From the curr= ent regulator's perspective, the allowed power for mobile devices is low eno= ugh that
height does not matter.

 

=3D Section 10 =3D
I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to
create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused.

So just listing that as a potential threat= and declare that fixing this as out of scope is sufficient? 

Or do we need to state that Databases MUST not track? I can see how an= onymized tracking
can be useful for spectrum m= anagement in the future, much like anonymized tracking of car locations
provide valuable traffic information for navigatio= n systems.

--
-vince


--
-vince
--B_3494322081_6454662-- From nobody Tue Sep 23 13:08:05 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615ED1A1B0A; Tue, 23 Sep 2014 13:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjD2NtKkShhj; Tue, 23 Sep 2014 13:07:54 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7931A88A6; Tue, 23 Sep 2014 13:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411502852; x=1443038852; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ksdd6qoVoo3iKytI9eUzrMwYPshXbm3iQwuzKCM9/k8=; b=fCrl7XZeBS1IOdc1TyUAjnB1dfebnmrUoOzB/R+DLR/rG+BqbLXYYNCj kOlfQ/0rOOqsJI/8qSyq+JKDCuogmX6afJ2Jxk+atsRad03latkZYp7+V ctzAlZ7re6P1KhGp4UHLwShA2WAyqcaEipLuYi3kX2JPwbD5fZuqPbKkf 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7570"; a="74724515" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Sep 2014 13:07:31 -0700 X-IronPort-AV: E=Sophos;i="5.04,582,1406617200"; d="scan'208";a="810944603" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Sep 2014 13:07:29 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 23 Sep 2014 13:07:29 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 23 Sep 2014 13:07:29 -0700 Message-ID: <5421D2FF.4090509@qti.qualcomm.com> Date: Tue, 23 Sep 2014 15:07:27 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Alissa Cooper References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/paws/VcCUZ5H8CRb24vYM77cDQPKEqvA Cc: paws@ietf.org, paws-chairs@tools.ietf.org, The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2014 20:07:57 -0000 On 8/20/14 11:52 AM, Alissa Cooper wrote: > ...there are 3 IPR disclosures in the tracker, not 2. Were all three > discussed in the WG? > The third IPR disclosure was pointed out to the WG. There was a short discussion, and nobody expressed concerns about this disclosure impacting the work. So I believe this portion of your DISCUSS is addressed. It sounds like you and Vince are winding up the rest of your DISCUSSion. Once you are satisfied, I'll give the document a once-over to make sure that all of the other comments were addressed. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Sep 23 23:57:17 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F861A883F for ; Tue, 23 Sep 2014 23:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkdSEmsiBtp8 for ; Tue, 23 Sep 2014 23:57:09 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9729F1A70FD for ; Tue, 23 Sep 2014 23:57:09 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id id10so5262433vcb.28 for ; Tue, 23 Sep 2014 23:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TPU7srw64+KTEIkI8WeGxjuqo7XmiufjvkUXKthBC0U=; b=O0jJNXl0FSt5Hc5Y9kPGT88jeWl53iHE6YyokIAKQi7N0zDvOWI1uMIJ6FtkSIqxyn HVhf1q6V4lezUF8dhPvUgSzD2zcrfqogpIwi7HjW0fPD9cc0o+MwtzSroBKx/BkhsXc2 iJEI1+g1/iTZh0pB9gNqQlDikARa9zTXLECkFYNXpBV3S6L1sAvuh3UmHuYQRM0DnNC9 qFVm3AgC9cauhQnZMOz5hoxaHSYLEjxQ2Oq4W+v3OEfl2b00jZQ7tqBJK1iLdpzI39nc 6lQN13wiFcc0GRYPRVm5h0PjvXYgbzBf1kN45fqCLZh4cosIBW5pyB1k6Ult2/A7wSMz ANfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TPU7srw64+KTEIkI8WeGxjuqo7XmiufjvkUXKthBC0U=; b=bXqgrHvmqTTrB05Yif8S1fppSBTDn5WTn2F08Gztyf24kiub7DQUTlpL3/3kGu6XsO SIxliYZFQb8m075/J501+0BvsFK0kpxgFqZSHF6Z1Wd2ONarKxQDhPAiOK03n+G4mK+R 7RVH5nTkQE5XczoqB2EHWtIM8PgF/c8jWYZQM3qkFu0MnFFRwJIujnZG001GBaYnL8uh wZJVB8gRSrITJTqZua4P/3HXf05dAOh53EMLjnJmcMVHaWI2cre0egRcysoVIUgvvj6K mGZjqX7ZjfeD9xeWV4P+MUTM0Nlb3WyoQBmIBJ9bfMqAsNASYpEVeoQNKSCmYF+o7bJK HRTQ== X-Gm-Message-State: ALoCoQnPlqs0CyLEIyzNpqOD4U6LMbe/7nq40xU7ABjmEEKpjXOO2AU+pNKlpCC77fdJB+5EqAzq MIME-Version: 1.0 X-Received: by 10.52.175.5 with SMTP id bw5mr3518854vdc.66.1411541828667; Tue, 23 Sep 2014 23:57:08 -0700 (PDT) Received: by 10.52.236.232 with HTTP; Tue, 23 Sep 2014 23:57:08 -0700 (PDT) In-Reply-To: References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 23:57:08 -0700 Message-ID: From: Vincent Chen To: Alissa Cooper Content-Type: multipart/alternative; boundary=20cf3071cebc48c3a10503ca31d1 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/JWg6f-db6A9t52W9uSANWaD3D7o Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 06:57:12 -0000 --20cf3071cebc48c3a10503ca31d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alissa, On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper wrote: > Hi Vince, > > Thanks. I like the text you added, but I think the bit about > fingerprinting and the caution to implementations about not over-sharing > that I had suggested are both important =E2=80=94 any reason not to inclu= de them > explicitly? > Sorry I did not respond directly to these points. Here's my train of thought. 1. The whole point of the White Space Database is to give information about available spectrum at a location. The location has to be precise enough for the information to be valid. So it seems odd for PAWS to recommend that a device give imprecise location. 2. While PAWS does indicate that serial number is optional, it is unlikely that a regulator will make it optional. In any cases I felt the statements indicating risk of tracking covers tracking via explicit information provided by the device and via implicit information derived from fingerprinting. -vince > > >> Now that the document is clear that Slave device location and serial >> number are optional (unless required by a ruleset), I think the remainin= g >> task on the above three points is to add a bit of text to Section 10 to >> explain the potential privacy threats from authorized databases, perhaps= as >> a short paragraph or two at the end of Section 10. Something along these >> lines (just a suggestion, feel free to reject this entirely or use bits >> that you like): >> >> "In addition to the privacy risks described above, in some cases, users >> of Master or Slave devices may open themselves up to privacy risks relat= ed >> to the secondary use of PAWS-related information by a database >> administrator. For example, in situations where rulesets require that >> Master or Slave devices uniquely identify themselves (via the >> DeviceDescriptor or DeviceOwner parameters), database administrators may= be >> able to use that information to track connectivity activity over time, o= r >> they may share such tracking information with third parties. Where Maste= r >> or Slave devices choose to provide or are required to provide geolocatio= n >> information in conjunction with unique device identifiers, this capabili= ty >> may further extent to location tracking. Even where a device does not >> provide a specific unique identifier, a database administrator may be ab= le >> to uniquely fingerprint a device based on the combination of other >> information provided in DeviceDescriptor or DeviceCapabilities parameter= s. >> >> In cases where devices have a choice to not send device-identifying >> information or geolocation, or to send less granular geolocation (i.e., = a >> region rather than a point), PAWS implementations can reduce the risks >> associated with secondary use by not sending that information. Where >> rulesets require this information to be sent, these risks require >> out-of-band mitigation (e.g., public statements or contractual terms >> preventing secondary use).=E2=80=9D >> >> Thanks, >> Alissa >> >> >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> =3D Shepherd write-up=3D >>> "An in-depth review by a JSON expert might be useful." >>> >>> Did that happen? >>> >> >> Tim Bray had looked at it before final call. >> >> >>> >>> =3D Section 1 =3D >>> "It opens the door for innovations in spectrum >>> management that can incorporate a variety of parameters, including >>> user location and time. In the future, it also can include other >>> parameters, such as user priority, time, signal type and power, >>> spectrum supply and demand, payment or micro-auction bidding, and >>> more." >>> >>> Time seems to be listed both as a current parameter and a future one, >>> which is confusing. >>> >> >> Agreed. The second "time" should be removed. >> >> >>> >>> =3D Section 4.4 =3D >>> "FCC rules, for example, require that a 'Fixed Device' >>> register its owner and operator contact information, its device >>> identifier, its location, and its antenna height." >>> >>> It would be nice to have a citation for the rules referenced here. >>> >> >> OK. >> >> >>> >>> =3D Section 5.1 =3D >>> Feel free to ignore this if it's completely misguided, but does altitud= e >>> really not matter? Are we sure this protocol won't be re-used for devic= es >>> on airplanes trying to find available spectrum? (I note that in RFC 695= 3, >>> requirement D.1 specifies that the data model must support "the height >>> and its uncertainty" -- I have no idea what "the height" means or if it >>> is related to altitude.) >>> >> >> See Section 5.3 on "height" of the antenna. It's separated out, from the >> "latitude, longitude" specification >> of GeoLocation. It allows specification with respect to ground level or >> mean sea level, and is intended >> for Fixed devices, rather than mobile devices. >> >> From the current regulator's perspective, the allowed power for mobile >> devices is low enough that >> height does not matter. >> >> >> >>> >>> =3D Section 10 =3D >>> I agree with Stephen that the database operator should be considered as= a >>> potential adversary from the standpoint of potentially being able to >>> create a fine-grained database that tracks the locations and spectrum u= se >>> patterns of individual devices. That data could certainly be abused. >>> >>> >> So just listing that as a potential threat and declare that fixing this >> as out of scope is sufficient? >> >> Or do we need to state that Databases MUST not track? I can see how >> anonymized tracking >> can be useful for spectrum management in the future, much like anonymize= d >> tracking of car locations >> provide valuable traffic information for navigation systems. >> >> -- >> -vince >> >> > > > -- > -vince > > --=20 -vince --20cf3071cebc48c3a10503ca31d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alissa,

On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <alissa@coope= rw.in> wrote:
Hi Vince,

Thanks. I like the text = you added, but I think the bit about fingerprinting and the caution to impl= ementations about not over-sharing that I had suggested are both important = =E2=80=94 any reason not to include them explicitly?

Sorry I did not respond directly to these points. Her= e's my train of thought.

1. The whole point of= the White Space Database is to give information about available spectrum a= t a location. The location has to be precise enough for the information to = be valid. So it seems odd for PAWS to recommend that a device give imprecis= e location.

2. While PAWS does indicate that seria= l number is optional, it is unlikely that a regulator will make it optional= .

In any cases I felt the statements indicating ri= sk of tracking covers tracking via explicit information provided by the dev= ice and via implicit information derived from fingerprinting.
-vince

=C2=A0

<= div class=3D"gmail_extra">

= Now that the document is clear that Slave device location and serial number= are optional (unless required by a ruleset), I think the remaining task on= the above three points is to add a bit of text to Section 10 to explain th= e potential privacy threats from authorized databases, perhaps as a short p= aragraph or two at the end of Section 10. Something along these lines (just= a suggestion, feel free to reject this entirely or use bits that you like)= :

"In addition to the privacy risks described= above, in some cases, users of Master or Slave devices may open themselves= up to privacy risks related to the secondary use of PAWS-related informati= on by a database administrator. For example, in situations where rulesets r= equire that Master or Slave devices uniquely identify themselves (via the D= eviceDescriptor or DeviceOwner parameters), database administrators may be = able to use that information to track connectivity activity over time, or t= hey may share such tracking information with third parties. Where Master or= Slave devices choose to provide or are required to provide geolocation inf= ormation in conjunction with unique device identifiers, this capability may= further extent to location tracking. Even where a device does not provide = a specific unique identifier, a database administrator may be able to uniqu= ely fingerprint a device based on the combination of other information prov= ided in DeviceDescriptor or DeviceCapabilities parameters.=C2=A0
=
In cases where devices have a choice to not send device-iden= tifying information or geolocation, or to send less granular geolocation (i= .e., a region rather than a point), PAWS implementations can reduce the ris= ks associated with secondary use by not sending that information. Where rul= esets require this information to be sent, these risks require out-of-band = mitigation (e.g., public statements or contractual terms preventing seconda= ry use).=E2=80=9D

Thanks,
Alissa

=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
<= br> =3D Shepherd write-up=3D
"An in-depth review by a JSON expert might be useful."

Did that happen?

Tim Bray had looked at= it before final call.
=C2=A0

=3D Section 1 =3D
"It opens the door for innovations in spectrum
=C2=A0 =C2=A0management that can incorporate a variety of parameters, inclu= ding
=C2=A0 =C2=A0user location and time.=C2=A0 In the future, it also can inclu= de other
=C2=A0 =C2=A0parameters, such as user priority, time, signal type and power= ,
=C2=A0 =C2=A0spectrum supply and demand, payment or micro-auction bidding, = and
=C2=A0 =C2=A0more."

Time seems to be listed both as a current parameter and a future one,
which is confusing.

Agreed. The second = "time" should be removed.
=C2=A0

=3D Section 4.4 =3D
"FCC rules, for example, require that a 'Fixed Device'
=C2=A0 =C2=A0register its owner and operator contact information, its devic= e
=C2=A0 =C2=A0identifier, its location, and its antenna height."
It would be nice to have a citation for the rules referenced here.

OK.
=C2=A0

=3D Section 5.1 =3D
Feel free to ignore this if it's completely misguided, but does altitud= e
really not matter? Are we sure this protocol won't be re-used for devic= es
on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height=
and its uncertainty" -- I have no idea what "the height" mea= ns or if it
is related to altitude.)

See Section 5.= 3 on "height" of the antenna. It's separated out, from the &q= uot;latitude, longitude" specification
of GeoLocation. It al= lows specification with respect to ground level or mean sea level, and is i= ntended
for Fixed devices, rather than mobile devices.
=
From the current regulator's perspective, the allowed po= wer for mobile devices is low enough that
height does not matter.=

=C2=A0

=3D Section 10 =3D
I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to
create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused.

So just listing that as a potential threa= t and declare that fixing this as out of scope is sufficient?=C2=A0

Or do we need to state that Databases MUST not track? I can see how= anonymized tracking
can be useful for spec= trum management in the future, much like anonymized tracking of car locatio= ns
provide valuable traffic information for= navigation systems.

--
-vince


--
-vince



--
-vince --20cf3071cebc48c3a10503ca31d1-- From nobody Wed Sep 24 13:28:30 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E317C1A19E8 for ; Wed, 24 Sep 2014 13:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_ZjPWzMsvhy for ; Wed, 24 Sep 2014 13:28:23 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A141A0687 for ; Wed, 24 Sep 2014 13:28:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id 9633F208ED for ; Wed, 24 Sep 2014 16:28:21 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 24 Sep 2014 16:28:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type; s=mesmtp; bh=7CtUwqp53DMaQ+sy+lYX4St LeaY=; b=Np2MOXZTxvHik9QUoZGOQV/Sf2UaXa91yRNjh+oQVSzMVoXwsegYGus JA+CZb6PAKr185SPYtRjoTbqikkmdRmzMcWT8G0b1A+rG0VP5e8zZAy/4GuLVrWF B23V1jS7uQ0+6x0ybx+MKC6d3vYeVQLD0zQALLuX1/0qG/ib4Mj8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type; s=smtpout; bh=7CtUwqp53DMaQ+sy+lYX4StLeaY=; b=q9vjyC5IPLfVhh0K49P+GN1hvn90 60BA0OZkjN2Y1TUG1DQo3Uy7jw7hVpa8A8SHEKgO5OMB2xhGig/fp3nILesRqNVC AMn3D+jC0hqp3BLA/qyydF1tWLuRz62aHuZqdnqjPd4PyUAydV3Bq+JFL2N00kjY /MEYu/oW0JYoR4k= X-Sasl-enc: HxB1J7gcEKHk267st/pgiEPko6bxbkcBL8GJXZhfP74V 1411590500 Received: from [171.68.18.45] (unknown [171.68.18.45]) by mail.messagingengine.com (Postfix) with ESMTPA id 74B31680181; Wed, 24 Sep 2014 16:28:18 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.4.3.140616 Date: Wed, 24 Sep 2014 13:28:13 -0700 From: Alissa Cooper To: Brian Rosen , Vincent Chen Message-ID: Thread-Topic: Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3494410100_9128372" Archived-At: http://mailarchive.ietf.org/arch/msg/paws/yfblTTczUa4jf3H3djn_P7VxSZ4 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 20:28:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3494410100_9128372 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 9/24/14, 6:17 AM, "Brian Rosen" wrote: > On the location issue, this is well traveled ground. >=20 > In many cases, the location of the device is no where near a boundary, an= d > thus can be relatively imprecise. As you get closer to a boundary, you n= eed > more precision in order to know if which side of the boundary you are on.= In > white space, sometimes the regulator specifies the required accuracy of > location, sometimes it doesn=E2=80=99t. >=20 > If you think about a canonical wireless microphone, you want location dow= n to > maybe 100 meters to avoid having problems with the microphone, but allow = use > of the spectrum where there is no problem of interference. I wouldn=E2=80=99t = want us > to specify some default accuracy, but it really does need to be fairly > accurate given current technology. We=E2=80=99re starting to see location > determination systems that could give us less than 2 meter accuracy in so= me > environments, and that=E2=80=99s probably beyond what we need. >=20 > So you both are right. Where the regulator specifies accuracy, that=E2=80=99s = it, you > send that, you need not send more. > When the regulator doesn=E2=80=99t specify, someone has to put out a spec, and = the > clients need not send more accurate location. Maybe we can build off of this and the text that Vince added in the =E2=80=9318 t= o make one additional recommendation, at the end of the new paragraph in Section 10: =E2=80=9CSimilarly, regulators should require, and implementations should provide= , device location at a level of granularity only as precise as necessary to support accurate database responses.=E2=80=9D Or something like that. Re-reading the new text, I agree that the fingerprinting bit is covered. Alissa >=20 > But, we=E2=80=99ve also looked at obfuscation when you want to report location = less > precise than what you have. What we know is that it=E2=80=99s really, really h= ard to > do it. >=20 > Brian >=20 > On Sep 24, 2014, at 2:57 AM, Vincent Chen wrote: >=20 >> Hi Alissa, >>=20 >> On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper wrote= : >>> Hi Vince, >>>=20 >>> Thanks. I like the text you added, but I think the bit about fingerprin= ting >>> and the caution to implementations about not over-sharing that I had >>> suggested are both important =E2=80=94 any reason not to include them explici= tly? >>=20 >> Sorry I did not respond directly to these points. Here's my train of tho= ught. >>=20 >> 1. The whole point of the White Space Database is to give information ab= out >> available spectrum at a location. The location has to be precise enough = for >> the information to be valid. So it seems odd for PAWS to recommend that = a >> device give imprecise location. >>=20 >> 2. While PAWS does indicate that serial number is optional, it is unlike= ly >> that a regulator will make it optional. >>=20 >> In any cases I felt the statements indicating risk of tracking covers >> tracking via explicit information provided by the device and via implici= t >> information derived from fingerprinting. >>=20 >> -vince >>=20 >> =20 >>>=20 >>>>>=20 >>>>> Now that the document is clear that Slave device location and serial >>>>> number are optional (unless required by a ruleset), I think the remai= ning >>>>> task on the above three points is to add a bit of text to Section 10 = to >>>>> explain the potential privacy threats from authorized databases, perh= aps >>>>> as a short paragraph or two at the end of Section 10. Something along >>>>> these lines (just a suggestion, feel free to reject this entirely or = use >>>>> bits that you like): >>>>>=20 >>>>> "In addition to the privacy risks described above, in some cases, use= rs of >>>>> Master or Slave devices may open themselves up to privacy risks relat= ed to >>>>> the secondary use of PAWS-related information by a database administr= ator. >>>>> For example, in situations where rulesets require that Master or Slav= e >>>>> devices uniquely identify themselves (via the DeviceDescriptor or >>>>> DeviceOwner parameters), database administrators may be able to use t= hat >>>>> information to track connectivity activity over time, or they may sha= re >>>>> such tracking information with third parties. Where Master or Slave >>>>> devices choose to provide or are required to provide geolocation >>>>> information in conjunction with unique device identifiers, this capab= ility >>>>> may further extent to location tracking. Even where a device does not >>>>> provide a specific unique identifier, a database administrator may be= able >>>>> to uniquely fingerprint a device based on the combination of other >>>>> information provided in DeviceDescriptor or DeviceCapabilities parame= ters. >>>>>=20 >>>>> In cases where devices have a choice to not send device-identifying >>>>> information or geolocation, or to send less granular geolocation (i.e= ., a >>>>> region rather than a point), PAWS implementations can reduce the risk= s >>>>> associated with secondary use by not sending that information. Where >>>>> rulesets require this information to be sent, these risks require >>>>> out-of-band mitigation (e.g., public statements or contractual terms >>>>> preventing secondary use).=E2=80=9D >>>>>=20 >>>>> Thanks, >>>>> Alissa >>>>>=20 >>>>>> =20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -------------------------------------------------------------------= --- >>>>>>> COMMENT: >>>>>>> -------------------------------------------------------------------= --- >>>>>>>=20 >>>>>>> =3D Shepherd write-up=3D >>>>>>> "An in-depth review by a JSON expert might be useful." >>>>>>>=20 >>>>>>> Did that happen? >>>>>>=20 >>>>>> Tim Bray had looked at it before final call. >>>>>> =20 >>>>>>>=20 >>>>>>> =3D Section 1 =3D >>>>>>> "It opens the door for innovations in spectrum >>>>>>> management that can incorporate a variety of parameters, includi= ng >>>>>>> user location and time. In the future, it also can include othe= r >>>>>>> parameters, such as user priority, time, signal type and power, >>>>>>> spectrum supply and demand, payment or micro-auction bidding, an= d >>>>>>> more." >>>>>>>=20 >>>>>>> Time seems to be listed both as a current parameter and a future on= e, >>>>>>> which is confusing. >>>>>>=20 >>>>>> Agreed. The second "time" should be removed. >>>>>> =20 >>>>>>>=20 >>>>>>> =3D Section 4.4 =3D >>>>>>> "FCC rules, for example, require that a 'Fixed Device' >>>>>>> register its owner and operator contact information, its device >>>>>>> identifier, its location, and its antenna height." >>>>>>>=20 >>>>>>> It would be nice to have a citation for the rules referenced here. >>>>>>=20 >>>>>> OK. >>>>>> =20 >>>>>>>=20 >>>>>>> =3D Section 5.1 =3D >>>>>>> Feel free to ignore this if it's completely misguided, but does alt= itude >>>>>>> really not matter? Are we sure this protocol won't be re-used for >>>>>>> devices >>>>>>> on airplanes trying to find available spectrum? (I note that in RFC >>>>>>> 6953, >>>>>>> requirement D.1 specifies that the data model must support "the hei= ght >>>>>>> and its uncertainty" -- I have no idea what "the height" means or i= f it >>>>>>> is related to altitude.) >>>>>>=20 >>>>>> See Section 5.3 on "height" of the antenna. It's separated out, from= the >>>>>> "latitude, longitude" specification >>>>>> of GeoLocation. It allows specification with respect to ground level= or >>>>>> mean sea level, and is intended >>>>>> for Fixed devices, rather than mobile devices. >>>>>>=20 >>>>>> From the current regulator's perspective, the allowed power for mobi= le >>>>>> devices is low enough that >>>>>> height does not matter. >>>>>>=20 >>>>>> =20 >>>>>>>=20 >>>>>>> =3D Section 10 =3D >>>>>>> I agree with Stephen that the database operator should be considere= d as >>>>>>> a >>>>>>> potential adversary from the standpoint of potentially being able t= o >>>>>>> create a fine-grained database that tracks the locations and spectr= um >>>>>>> use >>>>>>> patterns of individual devices. That data could certainly be abused= . >>>>>>>=20 >>>>>>=20 >>>>>> So just listing that as a potential threat and declare that fixing t= his >>>>>> as out of scope is sufficient? >>>>>>=20 >>>>>> Or do we need to state that Databases MUST not track? I can see how >>>>>> anonymized tracking >>>>>> can be useful for spectrum management in the future, much like anony= mized >>>>>> tracking of car locations >>>>>> provide valuable traffic information for navigation systems. >>>>>>=20 >>>>>> --=20 >>>>>> -vince=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> -vince=20 >>=20 >>=20 >>=20 >> --=20 >> -vince=20 >=20 --B_3494410100_9128372 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
On 9/24/14, 6:17 AM, "Brian R= osen" <br@brianrosen.net> wrote= :

On the location issue, t= his is well traveled ground.

In many cases, the location = of the device is no where near a boundary, and thus can be relatively imprec= ise.  As you get closer to a boundary, you need more precision in order= to know if which side of the boundary you are on.  In white space, som= etimes the regulator specifies the required accuracy of location, sometimes = it doesn’t.

If you think about a canonical wi= reless microphone, you want location down to maybe 100 meters to avoid havin= g problems with the microphone, but allow use of the spectrum where there is= no problem of interference.  I wouldn’t want us to specify some = default accuracy, but it really does need to be fairly accurate given curren= t technology.  We’re starting to see location determination syste= ms that could give us less than 2 meter accuracy in some environments, and t= hat’s probably beyond what we need.

So you bo= th are right.  Where the regulator specifies accuracy, that’s it,= you send that, you need not send more.
When the regulator doesn&#= 8217;t specify, someone has to put out a spec, and the clients need not send= more accurate location.

Maybe we can build off of this and the text that Vince added in the &#= 8211;18 to make one additional recommendation, at the end of the new paragra= ph in Section 10:

“Similarly, regulators shou= ld require, and implementations should provide, device location at a level o= f granularity only as precise as necessary to support accurate database resp= onses.”

Or something like that.
Re-reading the new text, I agree that the fingerprinting bit is = covered.

Alissa


But, we’ve also looked at obfusc= ation when you want to report location less precise than what you have. &nbs= p;What we know is that it’s really, really hard to do it.
Brian

On Sep 24, 2014, at 2:= 57 AM, Vincent Chen <vchen@google.com> wrote:

Hi Alissa,

On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper &= lt;alissa@cooperw.in&= gt; wrote:
Hi Vince,

Thanks. I like the text you added, but I think the bit= about fingerprinting and the caution to implementations about not over-shar= ing that I had suggested are both important — any reason not to includ= e them explicitly?

Sorry I did n= ot respond directly to these points. Here's my train of thought.
<= br>
1. The whole point of the White Space Database is to give info= rmation about available spectrum at a location. The location has to be preci= se enough for the information to be valid. So it seems odd for PAWS to recom= mend that a device give imprecise location.

2. Whil= e PAWS does indicate that serial number is optional, it is unlikely that a r= egulator will make it optional.

In any cases I felt= the statements indicating risk of tracking covers tracking via explicit inf= ormation provided by the device and via implicit information derived from fi= ngerprinting.

-vince

 = ;

<= br>
Now that the document is clear that Slave device location and = serial number are optional (unless required by a ruleset), I think the remai= ning task on the above three points is to add a bit of text to Section 10 to= explain the potential privacy threats from authorized databases, perhaps as= a short paragraph or two at the end of Section 10. Something along these li= nes (just a suggestion, feel free to reject this entirely or use bits that y= ou like):

"In addition to the privacy risks describ= ed above, in some cases, users of Master or Slave devices may open themselve= s up to privacy risks related to the secondary use of PAWS-related informati= on by a database administrator. For example, in situations where rulesets re= quire that Master or Slave devices uniquely identify themselves (via the Dev= iceDescriptor or DeviceOwner parameters), database administrators may be abl= e to use that information to track connectivity activity over time, or they = may share such tracking information with third parties. Where Master or Slav= e devices choose to provide or are required to provide geolocation informati= on in conjunction with unique device identifiers, this capability may furthe= r extent to location tracking. Even where a device does not provide a specif= ic unique identifier, a database administrator may be able to uniquely finge= rprint a device based on the combination of other information provided in De= viceDescriptor or DeviceCapabilities parameters. 

<= div>In cases where devices have a choice to not send device-identifying info= rmation or geolocation, or to send less granular geolocation (i.e., a region= rather than a point), PAWS implementations can reduce the risks associated = with secondary use by not sending that information. Where rulesets require t= his information to be sent, these risks require out-of-band mitigation (e.g.= , public statements or contractual terms preventing secondary use).”

Thanks,
Alissa

 


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
<= br> =3D Shepherd write-up=3D
"An in-depth review by a JSON expert might be useful."

Did that happen?

Tim Bray had looked at= it before final call.
 

=3D Section 1 =3D
"It opens the door for innovations in spectrum
   management that can incorporate a variety of parameters, inclu= ding
   user location and time.  In the future, it also can inclu= de other
   parameters, such as user priority, time, signal type and power= ,
   spectrum supply and demand, payment or micro-auction bidding, = and
   more."

Time seems to be listed both as a current parameter and a future one,
which is confusing.

Agreed. The second = "time" should be removed.
 
=3D Section 4.4 =3D
"FCC rules, for example, require that a 'Fixed Device'
   register its owner and operator contact information, its devic= e
   identifier, its location, and its antenna height."

It would be nice to have a citation for the rules referenced here.

OK.
 

=3D Section 5.1 =3D
Feel free to ignore this if it's completely misguided, but does altitude really not matter? Are we sure this protocol won't be re-used for devices on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height
and its uncertainty" -- I have no idea what "the height" means or if it
= is related to altitude.)

See Section 5.= 3 on "height" of the antenna. It's separated out, from the "latitude, longit= ude" specification
of GeoLocation. It allows specification with re= spect to ground level or mean sea level, and is intended
for Fixed= devices, rather than mobile devices.

From the curr= ent regulator's perspective, the allowed power for mobile devices is low eno= ugh that
height does not matter.

 

=3D Section 10 =3D
I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to
create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused.

So just listing that as a potential threat= and declare that fixing this as out of scope is sufficient? 

Or do we need to state that Databases MUST not track? I can see how an= onymized tracking
can be useful for spectrum m= anagement in the future, much like anonymized tracking of car locations
provide valuable traffic information for navigatio= n systems.

--
-vince



--
-vince



--
-vince

--B_3494410100_9128372-- From nobody Wed Sep 24 14:06:15 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0261A07BC; Wed, 24 Sep 2014 14:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.786 X-Spam-Level: X-Spam-Status: No, score=-7.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnKr_Q3J3dTT; Wed, 24 Sep 2014 14:05:54 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7671A19F9; Wed, 24 Sep 2014 14:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411592754; x=1443128754; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=h7L1vOy9majNAgcSetOobg5fdHfxturNIIspdyOvuZ8=; b=e8A8mOvLvyK3mZQSclb0ssamo83AEhXsyIZQkZyQIs3i0g9Jd9H5mRjW qm4dR5Ntd5uc0nIu7XrM+0pbL+Opyt6fMzdUQjJjiXqQZqtXxKJA5iDO+ NqCSabNu+8tpO3nQfF1GF1MYhYpbUQd8a0iT15kEaO9cc53GAKvT//2ec k=; X-IronPort-AV: E=McAfee;i="5600,1067,7571"; a="161077676" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 24 Sep 2014 14:05:53 -0700 X-IronPort-AV: E=Sophos; i="5.04,591,1406617200"; d="scan'208,217"; a="31384651" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Sep 2014 14:05:52 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 24 Sep 2014 14:05:52 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 24 Sep 2014 14:05:51 -0700 Message-ID: <5423322D.2080902@qti.qualcomm.com> Date: Wed, 24 Sep 2014 16:05:49 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Alissa Cooper References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050908020109050304050001" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/paws/pCOE1XBe4zZZNny9mZ9xS6EMqRk Cc: "paws-chairs@tools.ietf.org" , "paws@ietf.org" , The IESG , Brian Rosen , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 21:05:59 -0000 --------------050908020109050304050001 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit It sounds like we're closing in. Just in case, I've put the document on tomorrow's informal IESG telechat and invited Vince to join us (neither of the chairs can make it). If it resolves before then, great. If not, we'll work it out in real time. Thanks for working on this, all. pr On 9/24/14 3:28 PM, Alissa Cooper wrote: > On 9/24/14, 6:17 AM, "Brian Rosen" > wrote: > > On the location issue, this is well traveled ground. > > In many cases, the location of the device is no where near a > boundary, and thus can be relatively imprecise. As you get closer > to a boundary, you need more precision in order to know if which > side of the boundary you are on. In white space, sometimes the > regulator specifies the required accuracy of location, sometimes > it doesn't. > > If you think about a canonical wireless microphone, you want > location down to maybe 100 meters to avoid having problems with > the microphone, but allow use of the spectrum where there is no > problem of interference. I wouldn't want us to specify some > default accuracy, but it really does need to be fairly accurate > given current technology. We're starting to see location > determination systems that could give us less than 2 meter > accuracy in some environments, and that's probably beyond what we > need. > > So you both are right. Where the regulator specifies accuracy, > that's it, you send that, you need not send more. > When the regulator doesn't specify, someone has to put out a spec, > and the clients need not send more accurate location. > > > Maybe we can build off of this and the text that Vince added in the > --18 to make one additional recommendation, at the end of the new > paragraph in Section 10: > > "Similarly, regulators should require, and implementations should > provide, device location at a level of granularity only as precise as > necessary to support accurate database responses." > > Or something like that. > > Re-reading the new text, I agree that the fingerprinting bit is covered. > > Alissa > > > But, we've also looked at obfuscation when you want to report > location less precise than what you have. What we know is that > it's really, really hard to do it. > > Brian > > On Sep 24, 2014, at 2:57 AM, Vincent Chen > wrote: > >> Hi Alissa, >> >> On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper > > wrote: >> >> Hi Vince, >> >> Thanks. I like the text you added, but I think the bit about >> fingerprinting and the caution to implementations about not >> over-sharing that I had suggested are both important --- any >> reason not to include them explicitly? >> >> >> Sorry I did not respond directly to these points. Here's my train >> of thought. >> >> 1. The whole point of the White Space Database is to give >> information about available spectrum at a location. The location >> has to be precise enough for the information to be valid. So it >> seems odd for PAWS to recommend that a device give imprecise >> location. >> >> 2. While PAWS does indicate that serial number is optional, it is >> unlikely that a regulator will make it optional. >> >> In any cases I felt the statements indicating risk of tracking >> covers tracking via explicit information provided by the device >> and via implicit information derived from fingerprinting. >> >> -vince >> >> >> >> Now that the document is clear that Slave device >> location and serial number are optional (unless >> required by a ruleset), I think the remaining task on >> the above three points is to add a bit of text to >> Section 10 to explain the potential privacy threats >> from authorized databases, perhaps as a short >> paragraph or two at the end of Section 10. Something >> along these lines (just a suggestion, feel free to >> reject this entirely or use bits that you like): >> >> "In addition to the privacy risks described above, in >> some cases, users of Master or Slave devices may open >> themselves up to privacy risks related to the >> secondary use of PAWS-related information by a >> database administrator. For example, in situations >> where rulesets require that Master or Slave devices >> uniquely identify themselves (via the >> DeviceDescriptor or DeviceOwner parameters), database >> administrators may be able to use that information to >> track connectivity activity over time, or they may >> share such tracking information with third parties. >> Where Master or Slave devices choose to provide or >> are required to provide geolocation information in >> conjunction with unique device identifiers, this >> capability may further extent to location tracking. >> Even where a device does not provide a specific >> unique identifier, a database administrator may be >> able to uniquely fingerprint a device based on the >> combination of other information provided in >> DeviceDescriptor or DeviceCapabilities parameters. >> >> In cases where devices have a choice to not send >> device-identifying information or geolocation, or to >> send less granular geolocation (i.e., a region rather >> than a point), PAWS implementations can reduce the >> risks associated with secondary use by not sending >> that information. Where rulesets require this >> information to be sent, these risks require >> out-of-band mitigation (e.g., public statements or >> contractual terms preventing secondary use)." >> >> Thanks, >> Alissa >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> = Shepherd write-up= >> "An in-depth review by a JSON expert might be >> useful." >> >> Did that happen? >> >> >> Tim Bray had looked at it before final call. >> >> >> = Section 1 = >> "It opens the door for innovations in spectrum >> management that can incorporate a variety >> of parameters, including >> user location and time. In the future, it >> also can include other >> parameters, such as user priority, time, >> signal type and power, >> spectrum supply and demand, payment or >> micro-auction bidding, and >> more." >> >> Time seems to be listed both as a current >> parameter and a future one, >> which is confusing. >> >> >> Agreed. The second "time" should be removed. >> >> >> = Section 4.4 = >> "FCC rules, for example, require that a >> 'Fixed Device' >> register its owner and operator contact >> information, its device >> identifier, its location, and its antenna >> height." >> >> It would be nice to have a citation for the >> rules referenced here. >> >> >> OK. >> >> >> = Section 5.1 = >> Feel free to ignore this if it's completely >> misguided, but does altitude >> really not matter? Are we sure this protocol >> won't be re-used for devices >> on airplanes trying to find available >> spectrum? (I note that in RFC 6953, >> requirement D.1 specifies that the data model >> must support "the height >> and its uncertainty" -- I have no idea what >> "the height" means or if it >> is related to altitude.) >> >> >> See Section 5.3 on "height" of the antenna. It's >> separated out, from the "latitude, longitude" >> specification >> of GeoLocation. It allows specification with >> respect to ground level or mean sea level, and is >> intended >> for Fixed devices, rather than mobile devices. >> >> From the current regulator's perspective, the >> allowed power for mobile devices is low enough that >> height does not matter. >> >> >> = Section 10 = >> I agree with Stephen that the database >> operator should be considered as a >> potential adversary from the standpoint of >> potentially being able to >> create a fine-grained database that tracks >> the locations and spectrum use >> patterns of individual devices. That data >> could certainly be abused. >> >> >> So just listing that as a potential threat and >> declare that fixing this as out of scope is >> sufficient? >> >> Or do we need to state that Databases MUST not >> track? I can see how anonymized tracking >> can be useful for spectrum management in the >> future, much like anonymized tracking of car >> locations >> provide valuable traffic information for >> navigation systems. >> >> -- >> -vince >> >> >> >> >> -- >> -vince >> >> >> >> >> -- >> -vince > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------050908020109050304050001 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit It sounds like we're closing in. Just in case, I've put the document on tomorrow's informal IESG telechat and invited Vince to join us (neither of the chairs can make it). If it resolves before then, great. If not, we'll work it out in real time.

Thanks for working on this, all.

pr

On 9/24/14 3:28 PM, Alissa Cooper wrote:
On 9/24/14, 6:17 AM, "Brian Rosen" <br@brianrosen.net> wrote:

On the location issue, this is well traveled ground.

In many cases, the location of the device is no where near a boundary, and thus can be relatively imprecise.  As you get closer to a boundary, you need more precision in order to know if which side of the boundary you are on.  In white space, sometimes the regulator specifies the required accuracy of location, sometimes it doesn’t.

If you think about a canonical wireless microphone, you want location down to maybe 100 meters to avoid having problems with the microphone, but allow use of the spectrum where there is no problem of interference.  I wouldn’t want us to specify some default accuracy, but it really does need to be fairly accurate given current technology.  We’re starting to see location determination systems that could give us less than 2 meter accuracy in some environments, and that’s probably beyond what we need.

So you both are right.  Where the regulator specifies accuracy, that’s it, you send that, you need not send more.
When the regulator doesn’t specify, someone has to put out a spec, and the clients need not send more accurate location.

Maybe we can build off of this and the text that Vince added in the –18 to make one additional recommendation, at the end of the new paragraph in Section 10:

“Similarly, regulators should require, and implementations should provide, device location at a level of granularity only as precise as necessary to support accurate database responses.”

Or something like that.

Re-reading the new text, I agree that the fingerprinting bit is covered.

Alissa


But, we’ve also looked at obfuscation when you want to report location less precise than what you have.  What we know is that it’s really, really hard to do it.

Brian

On Sep 24, 2014, at 2:57 AM, Vincent Chen <vchen@google.com> wrote:

Hi Alissa,

On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <alissa@cooperw.in> wrote:
Hi Vince,

Thanks. I like the text you added, but I think the bit about fingerprinting and the caution to implementations about not over-sharing that I had suggested are both important — any reason not to include them explicitly?

Sorry I did not respond directly to these points. Here's my train of thought.

1. The whole point of the White Space Database is to give information about available spectrum at a location. The location has to be precise enough for the information to be valid. So it seems odd for PAWS to recommend that a device give imprecise location.

2. While PAWS does indicate that serial number is optional, it is unlikely that a regulator will make it optional.

In any cases I felt the statements indicating risk of tracking covers tracking via explicit information provided by the device and via implicit information derived from fingerprinting.

-vince

 

Now that the document is clear that Slave device location and serial number are optional (unless required by a ruleset), I think the remaining task on the above three points is to add a bit of text to Section 10 to explain the potential privacy threats from authorized databases, perhaps as a short paragraph or two at the end of Section 10. Something along these lines (just a suggestion, feel free to reject this entirely or use bits that you like):

"In addition to the privacy risks described above, in some cases, users of Master or Slave devices may open themselves up to privacy risks related to the secondary use of PAWS-related information by a database administrator. For example, in situations where rulesets require that Master or Slave devices uniquely identify themselves (via the DeviceDescriptor or DeviceOwner parameters), database administrators may be able to use that information to track connectivity activity over time, or they may share such tracking information with third parties. Where Master or Slave devices choose to provide or are required to provide geolocation information in conjunction with unique device identifiers, this capability may further extent to location tracking. Even where a device does not provide a specific unique identifier, a database administrator may be able to uniquely fingerprint a device based on the combination of other information provided in DeviceDescriptor or DeviceCapabilities parameters. 

In cases where devices have a choice to not send device-identifying information or geolocation, or to send less granular geolocation (i.e., a region rather than a point), PAWS implementations can reduce the risks associated with secondary use by not sending that information. Where rulesets require this information to be sent, these risks require out-of-band mitigation (e.g., public statements or contractual terms preventing secondary use).”

Thanks,
Alissa

 


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Shepherd write-up=
"An in-depth review by a JSON expert might be useful."

Did that happen?

Tim Bray had looked at it before final call.
 

= Section 1 =
"It opens the door for innovations in spectrum
   management that can incorporate a variety of parameters, including
   user location and time.  In the future, it also can include other
   parameters, such as user priority, time, signal type and power,
   spectrum supply and demand, payment or micro-auction bidding, and
   more."

Time seems to be listed both as a current parameter and a future one,
which is confusing.

Agreed. The second "time" should be removed.
 

= Section 4.4 =
"FCC rules, for example, require that a 'Fixed Device'
   register its owner and operator contact information, its device
   identifier, its location, and its antenna height."

It would be nice to have a citation for the rules referenced here.

OK.
 

= Section 5.1 =
Feel free to ignore this if it's completely misguided, but does altitude
really not matter? Are we sure this protocol won't be re-used for devices
on airplanes trying to find available spectrum? (I note that in RFC 6953,
requirement D.1 specifies that the data model must support "the height
and its uncertainty" -- I have no idea what "the height" means or if it
is related to altitude.)

See Section 5.3 on "height" of the antenna. It's separated out, from the "latitude, longitude" specification
of GeoLocation. It allows specification with respect to ground level or mean sea level, and is intended
for Fixed devices, rather than mobile devices.

From the current regulator's perspective, the allowed power for mobile devices is low enough that
height does not matter.

 

= Section 10 =
I agree with Stephen that the database operator should be considered as a
potential adversary from the standpoint of potentially being able to
create a fine-grained database that tracks the locations and spectrum use
patterns of individual devices. That data could certainly be abused.


So just listing that as a potential threat and declare that fixing this as out of scope is sufficient? 

Or do we need to state that Databases MUST not track? I can see how anonymized tracking
can be useful for spectrum management in the future, much like anonymized tracking of car locations
provide valuable traffic information for navigation systems.

--
-vince



--
-vince



--
-vince 


-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------050908020109050304050001-- From nobody Wed Sep 24 15:36:14 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8EE1A1ADA for ; Wed, 24 Sep 2014 15:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJJGnQvYp54c for ; Wed, 24 Sep 2014 15:36:05 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7831C1A1ADE for ; Wed, 24 Sep 2014 15:35:57 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id le20so7275852vcb.4 for ; Wed, 24 Sep 2014 15:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V1GfIR+R6M16QmH+5Y2LKAF8qFjbRDLNwZqd0sN9H0Y=; b=EBzovHNfTgBgOLucCV43vhmobP4zrWiU+bjyeNcYj6AEecXiDCu7kiv0/fS9LM88Db ++TQjr/TzflLCHllKtFNxxhtbqhO599wpkTogOiqxcIrQCdRGWF4I/0BOOvWxlUrmLbC bOEoi8nIoDyF/rKwEKFf0LW7gWzJ2C7itsrw9iCUxGO317vAY7tdyjWQw0ejHcQHH6q4 kgfhGCo0wc0vKu25o2auzzSTcWXvXKikhwel9Zx8Npq/X3XDlU8hyxkFJ9InxstHxupW TVrgbVpSdJtz/edVqOZaxS+w1Z9ydHiKu3u2rqHIjAARdbVuITOTWO+XpkFxX+4Hz0rB TJ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V1GfIR+R6M16QmH+5Y2LKAF8qFjbRDLNwZqd0sN9H0Y=; b=U/Yd3t8VpgLAeayty+BCgowv+MTxe3OuOHrG4g/BFZJ69hQm957AKY1dKxGXNG+3Mp QeiMsTn1b1Mgesx/QWhjZWKEqPFid/paUnc2SemtDMLoYkRcR8o5Hk5p/OlFwz3NK7c/ As5yCZhGA/b9KMQ2313QByDdQPf7RXHZ00bTKTsSFC6FEv5j+qTXxiIJjmW3R+BIa9rM It3gCRxYNvPwoXEpIy5D3pVqg0FK/l8P0ge+q2kf/x2HIF3c6BPs7Mg7+2o819RmV7wp LphbnLsweWTjnwXDlq4tkZZfd5DaQmNpTJHUWANuADbv9S6B0SWkq4ujBKZz/oS+p7rn YcGg== X-Gm-Message-State: ALoCoQlBN0CZ6BoHbOTVdsiVGwrHZA+RzNWqLXJCcB42M1fUvpA0iOhwJwcl7Rml5CV5dCJ0rZgH MIME-Version: 1.0 X-Received: by 10.52.190.130 with SMTP id gq2mr7027378vdc.16.1411598156448; Wed, 24 Sep 2014 15:35:56 -0700 (PDT) Received: by 10.52.130.205 with HTTP; Wed, 24 Sep 2014 15:35:56 -0700 (PDT) In-Reply-To: <5423322D.2080902@qti.qualcomm.com> References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> <5423322D.2080902@qti.qualcomm.com> Date: Wed, 24 Sep 2014 15:35:56 -0700 Message-ID: From: Vincent Chen To: Pete Resnick Content-Type: multipart/alternative; boundary=089e0122ee42ae61560503d74e04 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/QuwtH3TjUjUC2ZnlCUIa07Orw_I Cc: "paws-chairs@tools.ietf.org" , "paws@ietf.org" , The IESG , Brian Rosen , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 22:36:09 -0000 --089e0122ee42ae61560503d74e04 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Alissa! The new sentence looks good and strikes a great balance. I'll add and upload a new version. -vince On Wed, Sep 24, 2014 at 2:05 PM, Pete Resnick wrote: > It sounds like we're closing in. Just in case, I've put the document on > tomorrow's informal IESG telechat and invited Vince to join us (neither o= f > the chairs can make it). If it resolves before then, great. If not, we'll > work it out in real time. > > Thanks for working on this, all. > > pr > > > On 9/24/14 3:28 PM, Alissa Cooper wrote: > > On 9/24/14, 6:17 AM, "Brian Rosen" wrote: > > On the location issue, this is well traveled ground. > > In many cases, the location of the device is no where near a boundary, > and thus can be relatively imprecise. As you get closer to a boundary, y= ou > need more precision in order to know if which side of the boundary you ar= e > on. In white space, sometimes the regulator specifies the required > accuracy of location, sometimes it doesn=E2=80=99t. > > If you think about a canonical wireless microphone, you want location > down to maybe 100 meters to avoid having problems with the microphone, bu= t > allow use of the spectrum where there is no problem of interference. I > wouldn=E2=80=99t want us to specify some default accuracy, but it really = does need > to be fairly accurate given current technology. We=E2=80=99re starting t= o see > location determination systems that could give us less than 2 meter > accuracy in some environments, and that=E2=80=99s probably beyond what we= need. > > So you both are right. Where the regulator specifies accuracy, that=E2= =80=99s > it, you send that, you need not send more. > When the regulator doesn=E2=80=99t specify, someone has to put out a spec= , and the > clients need not send more accurate location. > > > Maybe we can build off of this and the text that Vince added in the =E2= =80=9318 > to make one additional recommendation, at the end of the new paragraph in > Section 10: > > =E2=80=9CSimilarly, regulators should require, and implementations shoul= d > provide, device location at a level of granularity only as precise as > necessary to support accurate database responses.=E2=80=9D > > Or something like that. > > Re-reading the new text, I agree that the fingerprinting bit is covered. > > Alissa > > > But, we=E2=80=99ve also looked at obfuscation when you want to report lo= cation > less precise than what you have. What we know is that it=E2=80=99s reall= y, really > hard to do it. > > Brian > > On Sep 24, 2014, at 2:57 AM, Vincent Chen wrote: > > Hi Alissa, > > On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper wrote: > >> Hi Vince, >> >> Thanks. I like the text you added, but I think the bit about >> fingerprinting and the caution to implementations about not over-sharing >> that I had suggested are both important =E2=80=94 any reason not to incl= ude them >> explicitly? >> > > Sorry I did not respond directly to these points. Here's my train of > thought. > > 1. The whole point of the White Space Database is to give information > about available spectrum at a location. The location has to be precise > enough for the information to be valid. So it seems odd for PAWS to > recommend that a device give imprecise location. > > 2. While PAWS does indicate that serial number is optional, it is > unlikely that a regulator will make it optional. > > In any cases I felt the statements indicating risk of tracking covers > tracking via explicit information provided by the device and via implicit > information derived from fingerprinting. > > -vince > > > >> >> >>> Now that the document is clear that Slave device location and serial >>> number are optional (unless required by a ruleset), I think the remaini= ng >>> task on the above three points is to add a bit of text to Section 10 to >>> explain the potential privacy threats from authorized databases, perhap= s as >>> a short paragraph or two at the end of Section 10. Something along thes= e >>> lines (just a suggestion, feel free to reject this entirely or use bits >>> that you like): >>> >>> "In addition to the privacy risks described above, in some cases, >>> users of Master or Slave devices may open themselves up to privacy risk= s >>> related to the secondary use of PAWS-related information by a database >>> administrator. For example, in situations where rulesets require that >>> Master or Slave devices uniquely identify themselves (via the >>> DeviceDescriptor or DeviceOwner parameters), database administrators ma= y be >>> able to use that information to track connectivity activity over time, = or >>> they may share such tracking information with third parties. Where Mast= er >>> or Slave devices choose to provide or are required to provide geolocati= on >>> information in conjunction with unique device identifiers, this capabil= ity >>> may further extent to location tracking. Even where a device does not >>> provide a specific unique identifier, a database administrator may be a= ble >>> to uniquely fingerprint a device based on the combination of other >>> information provided in DeviceDescriptor or DeviceCapabilities paramete= rs. >>> >>> In cases where devices have a choice to not send device-identifying >>> information or geolocation, or to send less granular geolocation (i.e.,= a >>> region rather than a point), PAWS implementations can reduce the risks >>> associated with secondary use by not sending that information. Where >>> rulesets require this information to be sent, these risks require >>> out-of-band mitigation (e.g., public statements or contractual terms >>> preventing secondary use).=E2=80=9D >>> >>> Thanks, >>> Alissa >>> >>> >>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> =3D Shepherd write-up=3D >>>> "An in-depth review by a JSON expert might be useful." >>>> >>>> Did that happen? >>>> >>> >>> Tim Bray had looked at it before final call. >>> >>> >>>> >>>> =3D Section 1 =3D >>>> "It opens the door for innovations in spectrum >>>> management that can incorporate a variety of parameters, including >>>> user location and time. In the future, it also can include other >>>> parameters, such as user priority, time, signal type and power, >>>> spectrum supply and demand, payment or micro-auction bidding, and >>>> more." >>>> >>>> Time seems to be listed both as a current parameter and a future one, >>>> which is confusing. >>>> >>> >>> Agreed. The second "time" should be removed. >>> >>> >>>> >>>> =3D Section 4.4 =3D >>>> "FCC rules, for example, require that a 'Fixed Device' >>>> register its owner and operator contact information, its device >>>> identifier, its location, and its antenna height." >>>> >>>> It would be nice to have a citation for the rules referenced here. >>>> >>> >>> OK. >>> >>> >>>> >>>> =3D Section 5.1 =3D >>>> Feel free to ignore this if it's completely misguided, but does altitu= de >>>> really not matter? Are we sure this protocol won't be re-used for >>>> devices >>>> on airplanes trying to find available spectrum? (I note that in RFC >>>> 6953, >>>> requirement D.1 specifies that the data model must support "the height >>>> and its uncertainty" -- I have no idea what "the height" means or if i= t >>>> is related to altitude.) >>>> >>> >>> See Section 5.3 on "height" of the antenna. It's separated out, from >>> the "latitude, longitude" specification >>> of GeoLocation. It allows specification with respect to ground level or >>> mean sea level, and is intended >>> for Fixed devices, rather than mobile devices. >>> >>> From the current regulator's perspective, the allowed power for mobile >>> devices is low enough that >>> height does not matter. >>> >>> >>> >>>> >>>> =3D Section 10 =3D >>>> I agree with Stephen that the database operator should be considered a= s >>>> a >>>> potential adversary from the standpoint of potentially being able to >>>> create a fine-grained database that tracks the locations and spectrum >>>> use >>>> patterns of individual devices. That data could certainly be abused. >>>> >>>> >>> So just listing that as a potential threat and declare that fixing >>> this as out of scope is sufficient? >>> >>> Or do we need to state that Databases MUST not track? I can see how >>> anonymized tracking >>> can be useful for spectrum management in the future, much like >>> anonymized tracking of car locations >>> provide valuable traffic information for navigation systems. >>> >>> -- >>> -vince >>> >>> >> >> >> -- >> -vince >> >> > > > -- > -vince > > > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --=20 -vince --089e0122ee42ae61560503d74e04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Alissa!

The new sentence looks = good and strikes a great balance. I'll add and upload a new version.

-vince

On Wed, Sep 24, 2014 at 2:05 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
=20
It sounds like we're closing in. Just in case, I've put the documen= t on tomorrow's informal IESG telechat and invited Vince to join us (neither of the chairs can make it). If it resolves before then, great. If not, we'll work it out in real time.

Thanks for working on this, all.

pr


On 9/24/14 3:28 PM, Alissa Cooper wrote:
On 9/24/14, 6:17 AM, "Brian Rosen" <br@brianrosen.net> wrote:

=20
On the location issue, this is well traveled ground.

In many cases, the location of the device is no where near a boundary, and thus can be relatively imprecise.=C2=A0 As you get closer to = a boundary, you need more precision in order to know if which side of the boundary you are on.=C2=A0 In white space, sometimes the regulator specifie= s the required accuracy of location, sometimes it doesn=E2=80=99t.

If you think about a canonical wireless microphone, you want location down to maybe 100 meters to avoid having problems with the microphone, but allow use of the spectrum where there is no problem of interference.=C2=A0 I wouldn=E2=80=99t want us to specify some default accu= racy, but it really does need to be fairly accurate given current technology. =C2=A0We=E2=80=99re starting to see location determination systems that cou= ld give us less than 2 meter accuracy in some environments, and that=E2=80=99s prob= ably beyond what we need.

So you both are right.=C2=A0 Where the regulator specifies accuracy, that=E2=80=99s it, you send that, you need not send more.
When the regulator doesn=E2=80=99t specify, someone has to put out= a spec, and the clients need not send more accurate location.

Maybe we can build off of this and the text that Vince added in the =E2=80=9318 to make one additional recommendation, at the end of the ne= w paragraph in Section 10:

=E2=80=9CSimilarly, regulators should require, and implementations should provide, device location at a level of granularity only as precise as necessary to support accurate database responses.=E2=80=9D

Or something like that.

Re-reading the new text, I agree that the fingerprinting bit is covered.

Alissa


But, we=E2=80=99ve also looked at obfuscation when you want to rep= ort location less precise than what you have.=C2=A0 What we know is that it=E2= =80=99s really, really hard to do it.

Brian

On Sep 24, 2014, at 2:57 AM, Vincent Chen <vchen@google.com> wrote:

Hi Alissa,

On Tue, Sep 23, 2014 at 1:01 PM, Alissa Cooper <alissa@cooperw.in> wrote:
Hi Vince,

Thanks. I like the text you added, but I think the bit about fingerprinting and the caution to implementations about not over-sharing that I had suggested are both important =E2=80=94 any reason n= ot to include them explicitly?

Sorry I did not respond directly to these points. Here's my train of thought.

1. The whole point of the White Space Database is to give information about available spectrum at a location. The location has to be precise enough for the information to be valid. So it seems odd for PAWS to recommend that a device give imprecise location.

2. While PAWS does indicate that serial number is optional, it is unlikely that a regulator will make it optional.

In any cases I felt the statements indicating risk of tracking covers tracking via explicit information provided by the device and via implicit information derived from fingerprinting.

-vince

=C2=A0

Now that the document is clear that Slave device location and serial number are optional (unless required by a ruleset), I think the remaining task on the above three points is to add a bit of text to Section 10 to explain the potential privacy threats from authorized databases, perhaps as a short paragraph or two at the end of Section 10. Something along these lines (just a suggestion, feel free to reject this entirely or use bits that you like):

"In addition to the privacy risks described above, in some cases, users of Master or Slave devices may open themselves up to privacy risks related to the secondary use of PAWS-related information by a database administrator. For example, in situations where rulesets require that Master or Slave devices uniquely identify themselves (via the DeviceDescriptor or DeviceOwner parameters), database administrators may be able to use that information to track connectivity activity over time, or they may share such tracking information with third parties. Where Master or Slave devices choose to provide or are required to provide geolocation information in conjunction with unique device identifiers, this capability may further extent to location tracking. Even where a device does not provide a specific unique identifier, a database administrator may be able to uniquely fingerprint a device based on the combination of other information provided in DeviceDescriptor or DeviceCapabilities parameters.=C2=A0

In cases where devices have a choice to not send device-identifying information or geolocation, or to send less granular geolocation (i.e., a region rather than a point), PAWS implementations can reduce the risks associated with secondary use by not sending that information. Where rulesets require this information to be sent, these risks require out-of-band mitigation (e.g., public statements or contractual terms preventing secondary use).=E2=80=9D

Thanks,
Alissa

=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

=3D Shepherd write-up=3D
"An in-depth review by a JSON expert might be useful."

Did that happen?

Tim Bray had looked at it before final call.
=C2=A0

=3D Section 1 =3D
"It opens the door for innovations in spectrum
=C2=A0 =C2=A0management that can incorporate a variety of parameters, inclu= ding
=C2=A0 =C2=A0user location and time.=C2=A0 In the future, it also can inclu= de other
=C2=A0 =C2=A0parameters, such as user priority, time, signal type and power= ,
=C2=A0 =C2=A0spectrum supply and demand, payment or micro-auction bidding, = and
=C2=A0 =C2=A0more."

Time seems to be listed both as a current parameter and a future one,
which is confusing.

Agreed. The second "time" should be removed.
=C2=A0

=3D Section 4.4 =3D
"FCC rules, for example, require that a 'Fixed Device'
=C2=A0 =C2=A0register its owner and operator contact information, its devic= e
=C2=A0 =C2=A0identifier, its location, and its antenna height."

It would be nice to have a citation for the rules referenced here.

OK.
=C2=A0

=3D Section 5.1 =3D
Feel free to ignore this if it's completely misguided, but does altitud= e
really not matter? Are we sure this protocol won't be re-used for devices
on airplanes trying to find available spectrum? (I note that in RFC 6953,
requirement D.1 specifies that the data model must support "the height=
and its uncertainty" -- I have no idea what "the height" mea= ns or if it
is related to altitude.)

See Section 5.3 on "height" of the antenna. It= 's separated out, from the "latitude, longitude" specification
of GeoLocation. It allows specification with respect to ground level or mean sea level, and is intended
for Fixed devices, rather than mobile devices.

From the current regulator's perspective, the allowed power for mobile devices is low enough that
height does not matter.

=C2=A0

=3D Section 10 =3D
I agree with Stephen that the database operator should be considered as a
potential adversary from the standpoint of potentially being able to
create a fine-grained database that tracks the locations and spectrum use
patterns of individual devices. That data could certainly be abused.


So just listing that as a potential threat and declare that fixing this as out of scope is sufficient?=C2=A0

Or do we need to state that Databases MUST not track? I can see how anonymized tracking
can be useful for spectrum management in the future, much like anonymized tracking of car locations
provide valuable traffic information for navigation systems.

--
-vince



--
-vince



--
-vince 


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


--
-vince --089e0122ee42ae61560503d74e04-- From nobody Wed Sep 24 15:54:31 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2131A1AD6; Wed, 24 Sep 2014 15:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmByQqyO02si; Wed, 24 Sep 2014 15:54:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D60561A1AE4; Wed, 24 Sep 2014 15:54:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924225423.15095.71960.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 15:54:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/hnmwEsobN5qYDiiBnsrQM5kSuFo Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-19.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 22:54:27 -0000 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) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-19.txt Pages : 91 Date : 2014-09-24 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 managing 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 (PAWS) Databases". 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-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 24 15:54:36 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2261A1AD8 for ; Wed, 24 Sep 2014 15:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeXwcJ7xZXnG; Wed, 24 Sep 2014 15:54:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CF21A1AE8; Wed, 24 Sep 2014 15:54:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org, paws@ietf.org, presnick@qti.qualcomm.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924225423.15095.68909.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 15:54:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/hVaY8jSy34LMJY405IkFn0iUUIE Subject: [paws] New Version Notification - draft-ietf-paws-protocol-19.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 22:54:29 -0000 A new version (-19) has been submitted for draft-ietf-paws-protocol: http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-19.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Sep 24 16:02:34 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CB41A01AE; Wed, 24 Sep 2014 16:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaDxMPEBL0EW; Wed, 24 Sep 2014 16:02:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2D61A1AD7; Wed, 24 Sep 2014 16:02:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140924230215.24240.81110.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 16:02:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Mkk-4KHlZj5TrDZNvyrR9qglDQY Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org Subject: [paws] Alissa Cooper's No Objection on draft-ietf-paws-protocol-19: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 23:02:18 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-paws-protocol-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for all your work to address my DISCUSS! = Shepherd write-up= "An in-depth review by a JSON expert might be useful." Did that happen? = Section 1 = "It opens the door for innovations in spectrum management that can incorporate a variety of parameters, including user location and time. In the future, it also can include other parameters, such as user priority, time, signal type and power, spectrum supply and demand, payment or micro-auction bidding, and more." Time seems to be listed both as a current parameter and a future one, which is confusing. = Section 4.4 = "FCC rules, for example, require that a 'Fixed Device' register its owner and operator contact information, its device identifier, its location, and its antenna height." It would be nice to have a citation for the rules referenced here. = Section 5.1 = Feel free to ignore this if it's completely misguided, but does altitude really not matter? Are we sure this protocol won't be re-used for devices on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height and its uncertainty" -- I have no idea what "the height" means or if it is related to altitude.) = Section 10 = I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused. From nobody Wed Sep 24 16:04:54 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3941F1A01AE; Wed, 24 Sep 2014 16:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfDBO1u2J7sL; Wed, 24 Sep 2014 16:04:46 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294C61A1AD7; Wed, 24 Sep 2014 16:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411599886; x=1443135886; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=J2eTUgnZTZIRpROEixj0ErAxYtbvWxHWBLRI3VQPwhw=; b=QatFbSdTVghOy6LqcVT5gGxgDL7hHdKPpIbiRbbM5mM5BkIMbNo56qjl DpktQzRUrF/QKw7uquRpRjq+1zezS7pD+VIs+QyH+w230EV5yHCjM0cJJ ysw8xNTO8Cb2jdtedRuqJGF+EBH/peS6I8T95DPGYkOwy2A2j1ENdNv9v 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7571"; a="69384803" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Sep 2014 16:04:46 -0700 X-IronPort-AV: E=Sophos;i="5.04,591,1406617200"; d="scan'208";a="717289662" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Sep 2014 16:04:45 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 24 Sep 2014 16:04:44 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 24 Sep 2014 16:04:44 -0700 Message-ID: <54234E05.2060203@qti.qualcomm.com> Date: Wed, 24 Sep 2014 18:04:37 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Alissa Cooper References: <20140924230215.24240.81110.idtracker@ietfa.amsl.com> In-Reply-To: <20140924230215.24240.81110.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/paws/3Iu-llqvuU1uZytvpoMAABAC9WQ Cc: paws@ietf.org, paws-chairs@tools.ietf.org, The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's No Objection on draft-ietf-paws-protocol-19: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 23:04:49 -0000 On 9/24/14 6:02 PM, Alissa Cooper wrote: > Thanks for all your work to address my DISCUSS! > Thanks for working with us, Alissa. I'll take the item off of tomorrow's agenda. No need for you to join, Vince. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478