From internet-drafts@ietf.org Tue May 7 21:56:56 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9510821F8F0D; Tue, 7 May 2013 21:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va+mUJL2QQwI; Tue, 7 May 2013 21:56:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B8021F89C3; Tue, 7 May 2013 21:56:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> Date: Tue, 07 May 2013 21:56:26 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 04:56:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-04.txt Pages : 88 Date : 2013-05-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 manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vchen@google.com Tue May 7 22:02:37 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C37D21F8F0D for ; Tue, 7 May 2013 22:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urOfHTRIExMX for ; Tue, 7 May 2013 22:02:36 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A835821F8FF8 for ; Tue, 7 May 2013 22:01:58 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t59so1330063wes.24 for ; Tue, 07 May 2013 22:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=kmgS48mmEyLcxBq7fDwSDdbwSd49JIL3BDyw6IrmEn8=; b=iJEgxcnGv3VLHcvPGN+QCxIjxTIR68UQeJJqz6vjpNWPbG47CuDb5IyTDv0LYR0vT/ e8gBpparEAKTjjsRU384Ex1slK9TxZWcomE85se86wE/x4z0UEmgMsA4PFg3eHEs6Zpe PauBA7gWs5RC774JH2c5sAMNGwcbd6lcM6EHWIL1b33UmLs5NmQ2ZKIoxeacZHLxcEYX oa3dmwez4JZ3HzLKGk7wkTrgrobqitOvWhPHMVBZq1KbPfjOPT1uddpKSG5lgV+g3XCF gPOEpsKaNN8g+1m6PQrUxRFvv1k7lafG+UOhNj5c9beVYiIS0zZNmE7u6hqe6cMfd4+W +BDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=kmgS48mmEyLcxBq7fDwSDdbwSd49JIL3BDyw6IrmEn8=; b=ghGQiowLNRIZ4gsmvNcYvZz2MptFQWO1xare/XluYXJ4wXsE3b64RsPBMFCdYazB8l Ndz6l6dL2pByFKxA51svwWz6RproqFDg/QGIo2Z2pcOT+N/LtRucEE4J2bz1P/QwS91c F3bGObC1SjtuSlItXw2eE69sH6vZU2KIJtWe4R5WM4Hjgpcy707Du7DiZAVK3GBCJxi5 p7QKOnefpBfzw/2WsEoHMNefCNUoohL3Ola8Ngfmu0zUG55RJqngbruzoQnxv0IRaM33 y/ixJ2rhTjhsNeQfnqv71TJsojLLt5ykZe8vq+rR62kHTfNHLAw0MjmeiXCvpLSGTWYQ uSiw== MIME-Version: 1.0 X-Received: by 10.180.187.234 with SMTP id fv10mr7467595wic.29.1367989317633; Tue, 07 May 2013 22:01:57 -0700 (PDT) Received: by 10.194.135.68 with HTTP; Tue, 7 May 2013 22:01:57 -0700 (PDT) In-Reply-To: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> Date: Tue, 7 May 2013 22:01:57 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3848e559ced04dc2dd58c X-Gm-Message-State: ALoCoQkR1w9E9sQ/ZRMDORaYAJWzmC7UFu9L14Iqqxc3bU9a0262sVuGDnw3STEUOmbfAyKYIu+/Z0T/slMK+quZBRh5aD2QXEW650R6kD3ofyU0gZislN81hqYQ3RQW0A+2FYKGV1R71rIx67ivkAmeyKQAx2qTPV/yE7iYuxBn+8pWyxgsUdWB/qwM1KNpHFCMZ6OIu+OS Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 05:02:37 -0000 --001a11c3848e559ced04dc2dd58c Content-Type: text/plain; charset=ISO-8859-1 All, I have uploaded a new version that incorporates the items discussed at the previous F2F and on the list. Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-03&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-04 Summary of changes: o Expanded the Database Discovery mechanism to describe in more detail pre-configuration with URIs of databases and database- listing services, including mechanisms for updating the configurations when things change * Add database-change field to Available Spectrum Response (Section 4.4.2) o Added fields that are anticipated to be needed by the ETSI harmonized standard for White Space Devices: * Added bandwidth constraints to the Available Spectrum Response (Section 4.4.2) * Updated Available Spectrum Response to return RulesetInfo, rather than just a rule-set identifier * Added optional device-manufacturer and device-model IDs to the DeviceDescriptor (Section 5.2). message. Also moved fccId from this message to the IANA section. * Expanded IANA (Section 9) sections o Clarified restrictions on the specification of the vertices of a Polygon. o Changed default confidence level to 95% for a point with uncertainty o Clarified how devices without absolute time source can use the timestamps in the response messages o Change method names to start with "spectrum.paws." prefix o Added maximum string lengths o Updated author contact info o More typo fixes There are still some TBDs associated with the ETSI additions, but otherwise has addressed all our prior open issues. -vince On Tue, May 7, 2013 at 9:56 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Protocol to Access WS database Working > Group of the IETF. > > Title : Protocol to Access Spectrum Database > Author(s) : Vincent Chen > Subir Das > Lei Zhu > John Malyar > Peter J. McCann > Filename : draft-ietf-paws-protocol-04.txt > Pages : 88 > Date : 2013-05-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 manage spectrum sharing uses databases to report > spectrum availability to devices. To achieve interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a protocol, the > "Protocol to Access White Space database" (PAWS). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-paws-protocol-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --001a11c3848e559ced04dc2dd58c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

I have uploaded a new version that= incorporates the items discussed at the previous F2F and
on the = list.


Summary of changes:

=A0 =A0o =A0Expanded the Database Discovery mechanism to= describe in more
=A0 =A0 =A0 detail pre-configuration with URIs = of databases and database-
=A0 =A0 =A0 listing services, including mechanisms for updating the
=A0 =A0 =A0 configurations when things change
=A0 =A0 =A0= * =A0Add database-change field to Available Spectrum Response
= =A0 =A0 =A0 =A0 =A0(Section 4.4.2)
=A0 =A0o =A0Added fields that are anticipated to be needed by the ETSI=
=A0 =A0 =A0 harmonized standard for White Space Devices:
=A0 =A0 =A0 * =A0Added bandwidth constraints to the Available Spectrum R= esponse
=A0 =A0 =A0 =A0 =A0(Section 4.4.2)
=A0 =A0 =A0 * =A0Updated Avail= able Spectrum Response to return RulesetInfo,
=A0 =A0 =A0 =A0 =A0= rather than just a rule-set identifier
=A0 =A0 =A0 * =A0Added opt= ional device-manufacturer and device-model IDs to the
=A0 =A0 =A0 =A0 =A0DeviceDescriptor (Section 5.2). message. =A0Also mo= ved fccId from
=A0 =A0 =A0 =A0 =A0this message to the IANA sectio= n.
=A0 =A0 =A0 * =A0Expanded IANA (Section 9) sections
= =A0 =A0o =A0Clarified restrictions on the specification of the vertices of = a
=A0 =A0 =A0 Polygon.
=A0 =A0o =A0Changed default confidence = level to 95% for a point with
=A0 =A0 =A0 uncertainty
= =A0 =A0o =A0Clarified how devices without absolute time source can use the<= /div>
=A0 =A0 =A0 timestamps in the response messages
=A0 =A0o =A0Change method names to start with "spectrum.paws.&quo= t; prefix
=A0 =A0o =A0Added maximum string lengths
=A0 = =A0o =A0Updated author contact info
=A0 =A0o =A0More typo fixes

There are still some TBDs associated with the ETSI additions, but otherwise= has addressed all our prior open issues.

-vince


On Tue, May 7, 2013 at 9:56 PM, <internet-drafts@ietf.org><= /span> wrote:

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

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

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

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


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

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


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

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



--
-vince
--001a11c3848e559ced04dc2dd58c-- From Gabor.Bajko@nokia.com Thu May 16 14:35:30 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91DA11E80A2 for ; Thu, 16 May 2013 14:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Cz-Oyyh-9Ab for ; Thu, 16 May 2013 14:35:25 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDB811E80CC for ; Thu, 16 May 2013 14:35:25 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r4GLYoD6008180; Fri, 17 May 2013 00:35:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.50]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 May 2013 00:34:58 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.51]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.02.0328.011; Thu, 16 May 2013 21:34:49 +0000 From: To: , Thread-Topic: [paws] I-D Action: draft-ietf-paws-protocol-04.txt Thread-Index: AQHOS6iUqN9sR+BW3ECUb3LsZ1uUkZj6uwOAgA2m/yA= Date: Thu, 16 May 2013 21:35:26 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760224C913@008-AM1MPN1-006.mgdnok.nokia.com> References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.143.158.145] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760224C913008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 May 2013 21:34:58.0792 (UTC) FILETIME=[37070680:01CE527D] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 21:35:31 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760224C913008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, What are the remaining open issues in this latest draft, you or any of the = co-authors are aware of? Since there has been not much feedback, if you think there aren't open issu= es left, we could issue a working group last call. - gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Vincent Chen Sent: Tuesday, May 07, 2013 10:02 PM To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt All, I have uploaded a new version that incorporates the items discussed at the = previous F2F and on the list. Diff: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-03&diffty= pe=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-04 Summary of changes: o Expanded the Database Discovery mechanism to describe in more detail pre-configuration with URIs of databases and database- listing services, including mechanisms for updating the configurations when things change * Add database-change field to Available Spectrum Response (Section 4.4.2) o Added fields that are anticipated to be needed by the ETSI harmonized standard for White Space Devices: * Added bandwidth constraints to the Available Spectrum Response (Section 4.4.2) * Updated Available Spectrum Response to return RulesetInfo, rather than just a rule-set identifier * Added optional device-manufacturer and device-model IDs to the DeviceDescriptor (Section 5.2). message. Also moved fccId from this message to the IANA section. * Expanded IANA (Section 9) sections o Clarified restrictions on the specification of the vertices of a Polygon. o Changed default confidence level to 95% for a point with uncertainty o Clarified how devices without absolute time source can use the timestamps in the response messages o Change method names to start with "spectrum.paws." prefix o Added maximum string lengths o Updated author contact info o More typo fixes There are still some TBDs associated with the ETSI additions, but otherwise= has addressed all our prior open issues. -vince On Tue, May 7, 2013 at 9:56 PM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-04.txt Pages : 88 Date : 2013-05-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 manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760224C913008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince,

 <= /p>

What are the remaining op= en issues in this latest draft, you or any of the co-authors are aware of?<= o:p>

Since there has been not = much feedback, if you think there aren’t open issues left, we could i= ssue a working group last call.

 <= /p>

- =          gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Vincent Chen
Sent: Tuesday, May 07, 2013 10:02 PM
To: paws@ietf.org
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt=

 

All,

 

I have uploaded a new version that incorporates the = items discussed at the previous F2F and

on the list.

 

 

Summary of changes:

 

   o  Expanded the Database Discovery= mechanism to describe in more

      detail pre-configuration with U= RIs of databases and database-

      listing services, including mec= hanisms for updating the

      configurations when things chan= ge

      *  Add database-change fie= ld to Available Spectrum Response

         (Section 4.4.2)

   o  Added fields that are anticipat= ed to be needed by the ETSI

      harmonized standard for White S= pace Devices:

      *  Added bandwidth constra= ints to the Available Spectrum Response

         (Section 4.4.2)

      *  Updated Available Spect= rum Response to return RulesetInfo,

         rather than just a= rule-set identifier

      *  Added optional device-m= anufacturer and device-model IDs to the

         DeviceDescriptor (= Section 5.2). message.  Also moved fccId from

         this message to th= e IANA section.

      *  Expanded IANA (Section = 9) sections

   o  Clarified restrictions on the s= pecification of the vertices of a

      Polygon.

   o  Changed default confidence leve= l to 95% for a point with

      uncertainty

   o  Clarified how devices without a= bsolute time source can use the

      timestamps in the response mess= ages

   o  Change method names to start wi= th "spectrum.paws." prefix

   o  Added maximum string lengths

   o  Updated author contact info

   o  More typo fixes

 

There are still some TBDs associated with the ETSI a= dditions, but otherwise has addressed all our prior open issues.=

 

-vince

 

On Tue, May 7, 2013 at 9:56 PM, <internet-drafts@ietf.org&= gt; wrote:


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

        Title           : Prot= ocol to Access Spectrum Database
        Author(s)       : Vincent Chen                      = ;     Subir Das
                     = ;     Lei Zhu
                     = ;     John Malyar
                     = ;     Peter J. McCann
        Filename        : draft-iet= f-paws-protocol-04.txt
        Pages           : 88         Date            := 2013-05-07

Abstract:
   Portions of the radio spectrum that are allocated to licensees= are
   available for non-interfering use.  This available spectr= um is called
   "White Space."  Allowing secondary users access= to available spectrum
   "unlocks" existing spectrum to maximize its utilizat= ion and to
   provide opportunities for innovation, resulting in greater ove= rall
   spectrum utilization.

   One approach to manage spectrum sharing uses databases to repo= rt
   spectrum availability to devices.  To achieve interoperab= ility among
   multiple devices and databases, a standardized protocol must b= e
   defined and implemented.  This document defines such a pr= otocol, the
   "Protocol to Access White Space database" (PAWS).

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

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


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

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



 

--
-vince

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760224C913008AM1MPN1006mg_-- From vchen@google.com Thu May 16 19:10:04 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A1811E80E6 for ; Thu, 16 May 2013 19:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48lgpuScrrF0 for ; Thu, 16 May 2013 19:10:02 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 88EAB11E80BA for ; Thu, 16 May 2013 19:10:02 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so8258712iea.3 for ; Thu, 16 May 2013 19:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dAhlhgIA+Db1uNfB75coIkuPcJIx+NkU9EDkgDLtljg=; b=pxmu9Ty6Fs7XHJ+ItiJXT2ruefyUiU4Gin6NN6Y4TYH/WS5kMUlqEXzUQFQBxqDagD p9h525G8YIG9uSUgwIWdD320DzD/LiSI70AoimEgCZYAIYeNJ/KhxpjGfbZk/8evZbN/ B55zNAedcICmha/4EAeDDM1aF4nIKaGjDWlJtgEkv33A68EzoY1e7tAk/N2O6crks8i1 s9VbCQlReo43nqPondUBRz0rd58h4827uybuexNLullmNTrUC8zb41dNz1jXMymMwHv8 iLURg2+hkcnAfne5X7L1CQgaAifBhzQOhLTPcW6/LC26+Ua5jckyCm9GPa4zQfgAezPP 1RGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=dAhlhgIA+Db1uNfB75coIkuPcJIx+NkU9EDkgDLtljg=; b=QLR61nGDIUJQ8xfBLLl3r7bWrmZymxLdjGNEhRajafyoi4i6KrWaoOtSVv7ycwZeOB vq7X6uN2vBRgS62TmO1rkswbhM3lkWcnpEVNXT7n1gJ1ptAGBDCW7XvynzfHqehQlHGM 1m1K1hdMhabqjDtIuP6i8FaQyw8hmM9sR0vBKD3/CCDI4Cg21XDFBb/b5NyAjJs/Mfb2 SRW4oxjiYpRxnpHHJ/cdfozOv+S6oHANo8UamgOupQChCG5IKt33zE1bfZZUO0qsX8os 9OZAAHL7hIvDHwu6axZyxQkn5/OOEjLmafP+RSfkFyZhgZ+6j6sKq1I2PbPx7sjHQSjD diKA== MIME-Version: 1.0 X-Received: by 10.50.16.36 with SMTP id c4mr11436965igd.60.1368756597641; Thu, 16 May 2013 19:09:57 -0700 (PDT) Received: by 10.64.166.130 with HTTP; Thu, 16 May 2013 19:09:57 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760224C913@008-AM1MPN1-006.mgdnok.nokia.com> References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760224C913@008-AM1MPN1-006.mgdnok.nokia.com> Date: Thu, 16 May 2013 19:09:57 -0700 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/alternative; boundary=e89a8ff25354c9637904dce07afe X-Gm-Message-State: ALoCoQkkDhrnRXN8JTET1/VOu3u+GOsJcNBHXUeWajGFx9FNdV8rwGNz2bpRMvjoqXhciG7XcPdQOeCwFdgC1S2NFCZo9SMMTnjOcYPlX36eqf6/16C7DU50uVy3ZVRtvutDBJGUxHi0DRoO88Ngtw7PFBdsrz31d92b9/0jqt/o0DfSlXAp6NOyeoYCX6DOBKHgSRHBjMVj Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 02:10:04 -0000 --e89a8ff25354c9637904dce07afe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Gabor, There is one more issue that has come to my attention. When the Master Device is requesting the available spectrum on behalf of a Slave Device, the request message should have an optional field for identifying the Master Device (in addition to the one that already identifies the Slave Device). This should be a simple addition. -vince On Thu, May 16, 2013 at 2:35 PM, wrote: > Vince, **** > > ** ** > > What are the remaining open issues in this latest draft, you or any of th= e > co-authors are aware of?**** > > Since there has been not much feedback, if you think there aren=92t open > issues left, we could issue a working group last call.**** > > ** ** > > **- **gabor**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Vincent Chen > *Sent:* Tuesday, May 07, 2013 10:02 PM > *To:* paws@ietf.org > *Subject:* Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt**** > > ** ** > > All,**** > > ** ** > > I have uploaded a new version that incorporates the items discussed at th= e > previous F2F and**** > > on the list.**** > > ** ** > > Diff: > http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-03&difftype= =3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-04 > **** > > ** ** > > Summary of changes:**** > > ** ** > > o Expanded the Database Discovery mechanism to describe in more**** > > detail pre-configuration with URIs of databases and database-**** > > listing services, including mechanisms for updating the**** > > configurations when things change**** > > * Add database-change field to Available Spectrum Response**** > > (Section 4.4.2)**** > > o Added fields that are anticipated to be needed by the ETSI**** > > harmonized standard for White Space Devices:**** > > * Added bandwidth constraints to the Available Spectrum Response**= * > * > > (Section 4.4.2)**** > > * Updated Available Spectrum Response to return RulesetInfo,**** > > rather than just a rule-set identifier**** > > * Added optional device-manufacturer and device-model IDs to the**= * > * > > DeviceDescriptor (Section 5.2). message. Also moved fccId from*= * > ** > > this message to the IANA section.**** > > * Expanded IANA (Section 9) sections**** > > o Clarified restrictions on the specification of the vertices of a***= * > > Polygon.**** > > o Changed default confidence level to 95% for a point with**** > > uncertainty**** > > o Clarified how devices without absolute time source can use the**** > > timestamps in the response messages**** > > o Change method names to start with "spectrum.paws." prefix**** > > o Added maximum string lengths**** > > o Updated author contact info**** > > o More typo fixes**** > > ** ** > > There are still some TBDs associated with the ETSI additions, but > otherwise has addressed all our prior open issues.**** > > ** ** > > -vince**** > > ** ** > > On Tue, May 7, 2013 at 9:56 PM, wrote:**** > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Protocol to Access WS database Working > Group of the IETF. > > Title : Protocol to Access Spectrum Database > Author(s) : Vincent Chen > Subir Das > Lei Zhu > John Malyar > Peter J. McCann > Filename : draft-ietf-paws-protocol-04.txt > Pages : 88 > Date : 2013-05-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 manage spectrum sharing uses databases to report > spectrum availability to devices. To achieve interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a protocol, the > "Protocol to Access White Space database" (PAWS). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-paws-protocol-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > > > **** > > ** ** > > -- > -vince **** > --=20 -vince --e89a8ff25354c9637904dce07afe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Gabor,
<= br>
There i= s one more issue that has come to my attention.

When the Master Device= is requesting the available spectrum on behalf of a Slave Device,
the request message should have an optional field for identifying the Maste= r Device
(i= n addition to the one that already identifies the Slave Device).

This s= hould be a simple addition.

-vince


On Thu, May 16, 2013 at 2:35 PM, <Gabor.Bajko@nokia.com><= /span> wrote:

Vince,

=A0<= /p>

What are the remaining op= en issues in this latest draft, you or any of the co-authors are aware of?<= u>

Since there has been not = much feedback, if you think there aren=92t open issues left, we could issue= a working group last call.

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 gabor<= /span>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Vincent Chen
Sent: Tuesday, May 07, 2013 10:02 PM
To: paws@ietf.org=
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt

=A0

All,

=A0

I have uploaded a new version that incorporates the = items discussed at the previous F2F and

on the list.

=A0

=A0

Summary of changes:

=A0

=A0 =A0o =A0Expanded the Database Discovery mechanis= m to describe in more

=A0 =A0 =A0 detail pre-configuration with URIs of da= tabases and database-

=A0 =A0 =A0 listing services, including mechanisms f= or updating the

=A0 =A0 =A0 configurations when things change=

=A0 =A0 =A0 * =A0Add database-change field to Availa= ble Spectrum Response

=A0 =A0 =A0 =A0 =A0(Section 4.4.2)

=A0 =A0o =A0Added fields that are anticipated to be = needed by the ETSI

=A0 =A0 =A0 harmonized standard for White Space Devi= ces:

=A0 =A0 =A0 * =A0Added bandwidth constraints to the = Available Spectrum Response

=A0 =A0 =A0 =A0 =A0(Section 4.4.2)

=A0 =A0 =A0 * =A0Updated Available Spectrum Response= to return RulesetInfo,

=A0 =A0 =A0 =A0 =A0rather than just a rule-set ident= ifier

=A0 =A0 =A0 * =A0Added optional device-manufacturer = and device-model IDs to the

=A0 =A0 =A0 =A0 =A0DeviceDescriptor (Section 5.2). m= essage. =A0Also moved fccId from

=A0 =A0 =A0 =A0 =A0this message to the IANA section.=

=A0 =A0 =A0 * =A0Expanded IANA (Section 9) sections<= u>

=A0 =A0o =A0Clarified restrictions on the specificat= ion of the vertices of a

=A0 =A0 =A0 Polygon.

=A0 =A0o =A0Changed default confidence level to 95% = for a point with

=A0 =A0 =A0 uncertainty

=A0 =A0o =A0Clarified how devices without absolute t= ime source can use the

=A0 =A0 =A0 timestamps in the response messages

=A0 =A0o =A0Change method names to start with "= spectrum.paws." prefix

=A0 =A0o =A0Added maximum string lengths

=A0 =A0o =A0Updated author contact info

=A0 =A0o =A0More typo fixes

=A0

There are still some TBDs associated with the ETSI a= dditions, but otherwise has addressed all our prior open issues.<= /u>

=A0

-vince

=A0

On Tue, May 7, 2013 at 9:56 PM, <internet-drafts@ietf.org&= gt; wrote:


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

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

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

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


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

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


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

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



=A0

--
-vince




--
-vince
--e89a8ff25354c9637904dce07afe-- From Cesar.Gutierrez@ofcom.org.uk Fri May 17 04:02:48 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AF621F8756 for ; Fri, 17 May 2013 04:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id murSnN03dhT2 for ; Fri, 17 May 2013 04:02:44 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.151]) by ietfa.amsl.com (Postfix) with ESMTP id C79F021F9380 for ; Fri, 17 May 2013 04:02:38 -0700 (PDT) Received: from [85.158.139.211:21812] by server-15.bemta-5.messagelabs.com id 78/FE-31797-D4E06915; Fri, 17 May 2013 11:02:37 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-4.tower-206.messagelabs.com!1368788556!18410601!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23296 invoked from network); 17 May 2013 11:02:36 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-4.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 17 May 2013 11:02:36 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 17 May 2013 12:02:36 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%15]) with mapi id 14.01.0289.001; Fri, 17 May 2013 12:02:35 +0100 From: Cesar Gutierrez To: Vincent Chen , "gabor.bajko@nokia.com" Thread-Topic: [paws] I-D Action: draft-ietf-paws-protocol-04.txt Thread-Index: AQHOS6iDKEPBmlOoF0moAbRBUrcrHJj6qj+AgA2oOgCAAEyzgIAAoETg Date: Fri, 17 May 2013 11:02:35 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655AE983D6D@WOK-INTRA-EXC02.intra.ofcom.local> References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760224C913@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655AE983D6DWOKINTRAEXC02in_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Reza Karimi Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 11:02:49 -0000 --_000_5D3E853BEE49C848BB63047C794C8655AE983D6DWOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince and all, Another issue that has slipped under the radar. We have the concept of "Generic operational parameters" in ETSI and the UK.= These are the spectrum use parameters that ANY Slave in the coverage area = of a Master can use. The values of these parameters will be broadcasted by = the Master, and a Slave will normally use them to "associate" and eventuall= y get "specific operational parameters" which will be tailored to the Slave= precise location and device characteristics. However, it is possible that = some Slaves, for instance cheap devices that cannot geolocate, will continu= e using the generic operational parameters in normal operations (after asso= ciation) To be clear, the Generic operational parameters are used by Slaves, althoug= h the database will calculate these parameters on the basis of information = from the Master. The calculation requires the location of the Master, and t= he power levels it uses. With this, the database can 1) calculate the cover= age area of the Master, 2) assume that a Slave might be in any location wit= hin that area, and 3) calculate a set of generic parameters on that could b= e used anywhere in the coverage area. Note that the Master must have reques= ted and obtained operational parameters for itself before engaging in this.= Therefore, the database already knows the Master's location and intended p= ower (this through the SPECTRUM_USE_NOTIFY procedure). I think that a simple way to implement the request for generic operational = parameters could be to re-use the AVAIL_SPECTRUM_REQ procedure, with the ad= dition of a flag to indicate to the database that the request is for generi= c operational parameters and not for operational parameters for the Master = itself, or for a specific slave. Thanks and regards, Cesar From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: 17 May 2013 03:10 To: gabor.bajko@nokia.com Cc: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt Gabor, There is one more issue that has come to my attention. When the Master Device is requesting the available spectrum on behalf of a = Slave Device, the request message should have an optional field for identifying the Maste= r Device (in addition to the one that already identifies the Slave Device). This should be a simple addition. -vince On Thu, May 16, 2013 at 2:35 PM, > wrote: Vince, What are the remaining open issues in this latest draft, you or any of the = co-authors are aware of? Since there has been not much feedback, if you think there aren't open issu= es left, we could issue a working group last call. - gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Vincent Chen Sent: Tuesday, May 07, 2013 10:02 PM To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt All, I have uploaded a new version that incorporates the items discussed at the = previous F2F and on the list. Diff: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-03&diffty= pe=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-04 Summary of changes: o Expanded the Database Discovery mechanism to describe in more detail pre-configuration with URIs of databases and database- listing services, including mechanisms for updating the configurations when things change * Add database-change field to Available Spectrum Response (Section 4.4.2) o Added fields that are anticipated to be needed by the ETSI harmonized standard for White Space Devices: * Added bandwidth constraints to the Available Spectrum Response (Section 4.4.2) * Updated Available Spectrum Response to return RulesetInfo, rather than just a rule-set identifier * Added optional device-manufacturer and device-model IDs to the DeviceDescriptor (Section 5.2). message. Also moved fccId from this message to the IANA section. * Expanded IANA (Section 9) sections o Clarified restrictions on the specification of the vertices of a Polygon. o Changed default confidence level to 95% for a point with uncertainty o Clarified how devices without absolute time source can use the timestamps in the response messages o Change method names to start with "spectrum.paws." prefix o Added maximum string lengths o Updated author contact info o More typo fixes There are still some TBDs associated with the ETSI additions, but otherwise= has addressed all our prior open issues. -vince On Tue, May 7, 2013 at 9:56 PM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-04.txt Pages : 88 Date : 2013-05-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 manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince -- -vince ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_5D3E853BEE49C848BB63047C794C8655AE983D6DWOKINTRAEXC02in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince and all,

 

Another issue that has = slipped under the radar.

 

We have the concept of = “Generic operational parameters” in ETSI and the UK. These are = the spectrum use parameters that ANY Slave in the coverage area of a Master can use. The values of these parameters will be broadcasted by the = Master, and a Slave will normally use them to “associate” and e= ventually get “specific operational parameters” which will be t= ailored to the Slave precise location and device characteristics. However, it is possible that some Slaves, for instance cheap devices that = cannot geolocate, will continue using the generic operational parameters in= normal operations (after association)

 

To be clear, the Generi= c operational parameters are used by Slaves, although the database will cal= culate these parameters on the basis of information from the Master. The calculation requires the location of the Master, and the p= ower levels it uses. With this, the database can 1) calculate the coverage = area of the Master, 2) assume that a Slave might be in any location within = that area, and 3) calculate a set of generic parameters on that could be used anywhere in the coverage area.= Note that the Master must have requested and obtained operational paramete= rs for itself before engaging in this. Therefore, the database already know= s the Master’s location and intended power (this through the SPECTRUM_USE_NOTIFY procedure).

 

I think that a simple w= ay to implement the request for generic operational parameters could be to = re-use the AVAIL_SPECTRUM_REQ procedure, with the addition of a flag to indicate to the database that the request is for generic oper= ational parameters and not for operational parameters for the Master itself= , or for a specific slave.

 

Thanks and regards,

Cesar

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Vincent Chen
Sent: 17 May 2013 03:10
To: gabor.bajko@nokia.com
Cc: paws@ietf.org
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt

 

Gabor,

 

There is one more issue that has come to = my attention.

 

When the Master Device is requesting the = available spectrum on behalf of a Slave Device,

the request message should have an option= al field for identifying the Master Device

(in addition to the one that already iden= tifies the Slave Device).

 

This should be a simple addition.<= /p>

 

-vince

 

On Thu, May 16, 2013 at 2:35 PM, <Gabor.Bajko@nokia.com> w= rote:

Vince,

 

What are the remaining open issues in this latest draft, you or any of t= he co-authors are aware of?

Since there has been not much feedback, if you think there aren’t = open issues left, we could issue a working group last call.

 

-     &nb= sp;    gabor

 

From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Vincent Chen
Sent: Tuesday, May 07, 2013 10:02 PM
To: paws@ietf.org=
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt

 

All,

 

I have uploaded a ne= w version that incorporates the items discussed at the previous F2F and

on the list.<= /p>

 

 

Summary of changes:<= /span>

 

   o  = ;Expanded the Database Discovery mechanism to describe in more

     = detail pre-configuration with URIs of databases and database-

     = listing services, including mechanisms for updating the

     = configurations when things change

     = *  Add database-change field to Available Spectrum Response

     =    (Section 4.4.2)

   o  = ;Added fields that are anticipated to be needed by the ETSI

     = harmonized standard for White Space Devices:

     = *  Added bandwidth constraints to the Available Spectrum Response

     =    (Section 4.4.2)

     = *  Updated Available Spectrum Response to return RulesetInfo,<= /p>

     =    rather than just a rule-set identifier

     = *  Added optional device-manufacturer and device-model IDs to the

     =    DeviceDescriptor (Section 5.2). message.  Also moved fcc= Id from

     =    this message to the IANA section.

     = *  Expanded IANA (Section 9) sections

   o  = ;Clarified restrictions on the specification of the vertices of a

     = Polygon.

   o  = ;Changed default confidence level to 95% for a point with

     = uncertainty

   o  = ;Clarified how devices without absolute time source can use the

     = timestamps in the response messages

   o  = ;Change method names to start with "spectrum.paws." prefix=

   o  = ;Added maximum string lengths

   o  = ;Updated author contact info

   o  = ;More typo fixes

 

There are still some= TBDs associated with the ETSI additions, but otherwise has addressed all o= ur prior open issues.

 

-vince

=  

On Tue, May 7, 2013 = at 9:56 PM, <internet-drafts@ietf.org> wrote:


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

        Title           : Prot= ocol to Access Spectrum Database
        Author(s)       : Vincent Chen                      = ;     Subir Das
                     = ;     Lei Zhu
                     = ;     John Malyar
                     = ;     Peter J. McCann
        Filename        : draft-iet= f-paws-protocol-04.txt
        Pages           : 88         Date            := 2013-05-07

Abstract:
   Portions of the radio spectrum that are allocated to licensees= are
   available for non-interfering use.  This available spectr= um is called
   "White Space."  Allowing secondary users access= to available spectrum
   "unlocks" existing spectrum to maximize its utilizat= ion and to
   provide opportunities for innovation, resulting in greater ove= rall
   spectrum utilization.

   One approach to manage spectrum sharing uses databases to repo= rt
   spectrum availability to devices.  To achieve interoperab= ility among
   multiple devices and databases, a standardized protocol must b= e
   defined and implemented.  This document defines such a pr= otocol, the
   "Protocol to Access White Space database" (PAWS).

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

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


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

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



 

--
-vince



 

--
-vince



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

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

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

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

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_5D3E853BEE49C848BB63047C794C8655AE983D6DWOKINTRAEXC02in_-- From brian.rosen@neustar.biz Fri May 17 05:52:27 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AA021F93DC for ; Fri, 17 May 2013 05:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3P2y6WYmcvv for ; Fri, 17 May 2013 05:52:06 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id BF94421F938E for ; Fri, 17 May 2013 05:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1368795601; x=1684147825; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=vtIuOW8ZdxKaKk8rE31FEPAWDO6+F8o2NToTSVMPV2Y=; b=aiF4GjOSq2N3zXMwWuyevUNTg+V4qL8DMY0DD0CTJKRWBkNttX8sFArT3sHGJp n79cxZvkNSZ3FwPhEodW0sHg== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.24879718; Fri, 17 May 2013 08:59:59 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 17 May 2013 08:52:01 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.29]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Fri, 17 May 2013 08:51:56 -0400 From: "Rosen, Brian" To: Cesar Gutierrez Thread-Topic: [paws] I-D Action: draft-ietf-paws-protocol-04.txt Thread-Index: AQHOUv1P215nFpXI406devWZ8ZhbCg== Date: Fri, 17 May 2013 12:51:55 +0000 Message-ID: <4012BD69-86FC-4F82-95C4-0C361D360E28@neustar.biz> References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760224C913@008-AM1MPN1-006.mgdnok.nokia.com> <5D3E853BEE49C848BB63047C794C8655AE983D6D@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: <5D3E853BEE49C848BB63047C794C8655AE983D6D@WOK-INTRA-EXC02.intra.ofcom.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.18] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: gJqLQ2OY8tSf52TdpYqF8Q== Content-Type: multipart/alternative; boundary="_000_4012BD6986FC4F8295C40C361D360E28neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Reza Karimi Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 12:52:27 -0000 --_000_4012BD6986FC4F8295C40C361D360E28neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Probably better to have some multi-use type-of-request parameter in the req= uest with a registry of values, one of which would be "Generic Parameters". Brian On May 17, 2013, at 7:02 AM, Cesar Gutierrez > wrote: Vince and all, Another issue that has slipped under the radar. We have the concept of =93Generic operational parameters=94 in ETSI and the= UK. These are the spectrum use parameters that ANY Slave in the coverage a= rea of a Master can use. The values of these parameters will be broadcasted= by the Master, and a Slave will normally use them to =93associate=94 and e= ventually get =93specific operational parameters=94 which will be tailored = to the Slave precise location and device characteristics. However, it is po= ssible that some Slaves, for instance cheap devices that cannot geolocate, = will continue using the generic operational parameters in normal operations= (after association) To be clear, the Generic operational parameters are used by Slaves, althoug= h the database will calculate these parameters on the basis of information = from the Master. The calculation requires the location of the Master, and t= he power levels it uses. With this, the database can 1) calculate the cover= age area of the Master, 2) assume that a Slave might be in any location wit= hin that area, and 3) calculate a set of generic parameters on that could b= e used anywhere in the coverage area. Note that the Master must have reques= ted and obtained operational parameters for itself before engaging in this.= Therefore, the database already knows the Master=92s location and intended= power (this through the SPECTRUM_USE_NOTIFY procedure). I think that a simple way to implement the request for generic operational = parameters could be to re-use the AVAIL_SPECTRUM_REQ procedure, with the ad= dition of a flag to indicate to the database that the request is for generi= c operational parameters and not for operational parameters for the Master = itself, or for a specific slave. Thanks and regards, Cesar From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Vincent Chen Sent: 17 May 2013 03:10 To: gabor.bajko@nokia.com Cc: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt Gabor, There is one more issue that has come to my attention. When the Master Device is requesting the available spectrum on behalf of a = Slave Device, the request message should have an optional field for identifying the Maste= r Device (in addition to the one that already identifies the Slave Device). This should be a simple addition. -vince On Thu, May 16, 2013 at 2:35 PM, > wrote: Vince, What are the remaining open issues in this latest draft, you or any of the = co-authors are aware of? Since there has been not much feedback, if you think there aren=92t open is= sues left, we could issue a working group last call. - gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Vincent Chen Sent: Tuesday, May 07, 2013 10:02 PM To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt All, I have uploaded a new version that incorporates the items discussed at the = previous F2F and on the list. Diff: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-03&diffty= pe=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-04 Summary of changes: o Expanded the Database Discovery mechanism to describe in more detail pre-configuration with URIs of databases and database- listing services, including mechanisms for updating the configurations when things change * Add database-change field to Available Spectrum Response (Section 4.4.2) o Added fields that are anticipated to be needed by the ETSI harmonized standard for White Space Devices: * Added bandwidth constraints to the Available Spectrum Response (Section 4.4.2) * Updated Available Spectrum Response to return RulesetInfo, rather than just a rule-set identifier * Added optional device-manufacturer and device-model IDs to the DeviceDescriptor (Section 5.2). message. Also moved fccId from this message to the IANA section. * Expanded IANA (Section 9) sections o Clarified restrictions on the specification of the vertices of a Polygon. o Changed default confidence level to 95% for a point with uncertainty o Clarified how devices without absolute time source can use the timestamps in the response messages o Change method names to start with "spectrum.paws." prefix o Added maximum string lengths o Updated author contact info o More typo fixes There are still some TBDs associated with the ETSI additions, but otherwise= has addressed all our prior open issues. -vince On Tue, May 7, 2013 at 9:56 PM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-04.txt Pages : 88 Date : 2013-05-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 manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince -- -vince ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_4012BD6986FC4F8295C40C361D360E28neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <248C2418C2635F478A15FA50118F3321@neustar.biz> Content-Transfer-Encoding: quoted-printable Probably better to have some multi-use type-of-request parameter in the req= uest with a registry of values, one of which would be "Generic Paramet= ers".  

Brian

On May 17, 2013, at 7:02 AM, Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> wrote:
Vince and all,

 

Another issue that has slipped under the radar.

 

We have the concept of =93Generic operational parameters= =94 in ETSI and the UK. These are the spectrum use parameters that ANY Slav= e in the coverage area of a Master can use. The values of these parameters will be broadcasted by the Master, and= a Slave will normally use them to =93associate=94 and eventually get =93sp= ecific operational parameters=94 which will be tailored to the Slave precis= e location and device characteristics. However, it is possible that some Slaves, for instance cheap devices that cannot ge= olocate, will continue using the generic operational parameters in normal o= perations (after association)

 

To be clear, the Generic operational parameters are used = by Slaves, although the database will calculate these parameters on the bas= is of information from the Master. The calculation requires the location of the Master, and the power levels = it uses. With this, the database can 1) calculate the coverage area of the = Master, 2) assume that a Slave might be in any location within that area, a= nd 3) calculate a set of generic parameters on that could be used anywhere in the coverage area. Note that = the Master must have requested and obtained operational parameters for itse= lf before engaging in this. Therefore, the database already knows the Maste= r=92s location and intended power (this through the SPECTRUM_USE_NOTIFY procedure).

 

I think that a simple way to implement the request for ge= neric operational parameters could be to re-use the AVAIL_SPECTRUM_REQ proc= edure, with the addition of a flag to indicate to the database that the request is for generic operational pa= rameters and not for operational parameters for the Master itself, or for a= specific slave.

 

Thanks and regards,
Cesar

 

From:&nbs= p;paws-bounces@ietf.org [mailto:paws-bounces@ietf.org<= /a>] On Behalf Of Vincent Ch= en
Sent: 17 May 2013 = 03:10
To: gabor.bajko@nokia.com
Cc: pa= ws@ietf.org
Subject: Re: [paws= ] I-D Action: draft-ietf-paws-protocol-04.txt

 

Gabor,

 

There is o= ne more issue that has come to my attention.

 

When the M= aster Device is requesting the available spectrum on behalf of a Slave Devi= ce,
the reques= t message should have an optional field for identifying the Master Device
(in additi= on to the one that already identifies the Slave Device).

 

This shoul= d be a simple addition.

 

-vince
 
On Thu, May 16, 2013 at 2:35 PM, <= Gabor.Bajko@nokia.com> wrote:
Vince,<= /div>

 <= /p>

What are the remaining open issues in this= latest draft, you or any of the co-authors are aware of?
Since there has been not much feedback, if= you think there aren=92t open issues left, we could issue a working group = last call.

 <= /p>

-      =     gabor<= /p>

 <= /p>

From:&nbs= p;paws-bounces@ietf.org<= span class=3D"Apple-converted-space"> [mailto:paws-bounces@ietf.org] On Behalf Of ext Vincen= t Chen
Sent: Tuesday, May= 07, 2013 10:02 PM
To: paws@ietf.org
Subject: Re: [paws= ] I-D Action: draft-ietf-paws-protocol-04.txt

 

All,

 

I have uploaded a new version that incorporates the it= ems discussed at the previous F2F and
on the list.

 

 

Summary of changes:

 

   o  Expanded the Database Discovery m= echanism to describe in more
      detail pre-configuration with URI= s of databases and database-
      listing services, including mecha= nisms for updating the
      configurations when things change=
      *  Add database-change field= to Available Spectrum Response
         (Section 4.4.2)
   o  Added fields that are anticipated= to be needed by the ETSI
      harmonized standard for White Spa= ce Devices:
      *  Added bandwidth constrain= ts to the Available Spectrum Response
         (Section 4.4.2)
      *  Updated Available Spectru= m Response to return RulesetInfo,
         rather than just a r= ule-set identifier
      *  Added optional device-man= ufacturer and device-model IDs to the
         DeviceDescriptor (Se= ction 5.2). message.  Also moved fccId from
         this message to the = IANA section.
      *  Expanded IANA (Section 9)= sections
   o  Clarified restrictions on the spe= cification of the vertices of a
      Polygon.
   o  Changed default confidence level = to 95% for a point with
      uncertainty
   o  Clarified how devices without abs= olute time source can use the
      timestamps in the response messag= es
   o  Change method names to start with= "spectrum.paws." prefix
   o  Added maximum string lengths
   o  Updated author contact info
   o  More typo fixes

 

There are still some TBDs associated with the ETSI add= itions, but otherwise has addressed all our prior open issues.

 

-vince
 
On Tue, May 7, 2013 at 9:56 PM, <internet-drafts@ietf.org> wrote:

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

        Title           : Prot= ocol to Access Spectrum Database
        Author(s)       : Vincent Chen                      = ;     Subir Das
                     = ;     Lei Zhu
                     = ;     John Malyar
                     = ;     Peter J. McCann
        Filename        : draft-iet= f-paws-protocol-04.txt
        Pages           : 88         Date            := 2013-05-07

Abstract:
   Portions of the radio spectrum that are allocated to licensees= are
   available for non-interfering use.  This available spectr= um is called
   "White Space."  Allowing secondary users access= to available spectrum
   "unlocks" existing spectrum to maximize its utilizat= ion and to
   provide opportunities for innovation, resulting in greater ove= rall
   spectrum utilization.

   One approach to manage spectrum sharing uses databases to repo= rt
   spectrum availability to devices.  To achieve interoperab= ility among
   multiple devices and databases, a standardized protocol must b= e
   defined and implemented.  This document defines such a pr= otocol, the
   "Protocol to Access White Space database" (PAWS).

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

There's also a htmlized version available at:
http://to= ols.ietf.org/html/draft-ietf-paws-protocol-04

A diff from the previous version is available at:
htt= p://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-04


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

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


 

-- <= br> -vince


 

-- 
-vince


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

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

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

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

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paw= s

--_000_4012BD6986FC4F8295C40C361D360E28neustarbiz_-- From ben@crouchingbadger.com Fri May 17 06:01:28 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0321F85C3 for ; Fri, 17 May 2013 06:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFczVv1zK7Le for ; Fri, 17 May 2013 06:01:28 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBA121F871D for ; Fri, 17 May 2013 06:01:27 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id eg20so1605489lab.13 for ; Fri, 17 May 2013 06:01:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=oXJea3jJ0eNr04qcNP41Yp6FmKaMb1OPFlAYnH9nZNM=; b=aZLC+usIh7GU1MH7s0n4YpcuAJcRpkhI4P162TbivGTErj0Sg1Qv6Y51N1Q8VX6ra5 7ufEBw5ZxqoIZGpAQVkGFNmoh5HoRtwpjKGGzGy2F+om1Lq00h0TJK6nj1YEiM4EZWSh imwjkBzgkQLJ/7uhSf+Bhi21pxfTlqrJRSsj/CaILiWLoFqvQYXLOxD6YLAh/Klk+RiS l6FTJ4Ir+WebijuSR8hKo0GQChSwV9XiP9S25ih0PHKEqYOYhaFNX69ncjjlhiaxG2aY skIiapYJuw58wiJmMlTT0B5CUTllaXzirX9eG3vU5t0/murzKjzhDr7nIPHF0IweBhSm afqg== MIME-Version: 1.0 X-Received: by 10.112.19.133 with SMTP id f5mr8322483lbe.98.1368795684544; Fri, 17 May 2013 06:01:24 -0700 (PDT) Received: by 10.112.0.140 with HTTP; Fri, 17 May 2013 06:01:24 -0700 (PDT) In-Reply-To: References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 14:01:24 +0100 Message-ID: From: Ben Ward To: Vincent Chen Content-Type: multipart/alternative; boundary=14dae93d8c868c354604dce994ca X-Gm-Message-State: ALoCoQlNhSGNSkiomXMfRE97E6xXBmviqwwbx8Cjpj/vsC1RS30M8DOxecQOb/IhoWiGWgj5MTuz Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:01:29 -0000 --14dae93d8c868c354604dce994ca Content-Type: text/plain; charset=ISO-8859-1 Vince, This is my first post to the PAWS list (and indeed any IETF draft) so please let me know if I'm not following procedure. I'm glad draft 04 covers database discovery in more detail. I'm still curious about the Error Handling section. I understand a grace period is useful and necessary when no databases are contactable by the Device for a short period. Does this also handle the scenario of the Device losing contact with the regulatory domain's Listing Server? Should Devices trying to update their database entry from a Listing Server which has gone away have a grace period/hold timer too? Or does the first failed attempt cause complete shutdown of the Device? Thanks Ben On 8 May 2013 06:01, Vincent Chen wrote: > All, > > I have uploaded a new version that incorporates the items discussed at the > previous F2F and > on the list. > > Diff: > http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-03&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-04 > > Summary of changes: > > o Expanded the Database Discovery mechanism to describe in more > detail pre-configuration with URIs of databases and database- > listing services, including mechanisms for updating the > configurations when things change > * Add database-change field to Available Spectrum Response > (Section 4.4.2) > o Added fields that are anticipated to be needed by the ETSI > harmonized standard for White Space Devices: > * Added bandwidth constraints to the Available Spectrum Response > (Section 4.4.2) > * Updated Available Spectrum Response to return RulesetInfo, > rather than just a rule-set identifier > * Added optional device-manufacturer and device-model IDs to the > DeviceDescriptor (Section 5.2). message. Also moved fccId from > this message to the IANA section. > * Expanded IANA (Section 9) sections > o Clarified restrictions on the specification of the vertices of a > Polygon. > o Changed default confidence level to 95% for a point with > uncertainty > o Clarified how devices without absolute time source can use the > timestamps in the response messages > o Change method names to start with "spectrum.paws." prefix > o Added maximum string lengths > o Updated author contact info > o More typo fixes > > There are still some TBDs associated with the ETSI additions, but > otherwise has addressed all our prior open issues. > > -vince > > > On Tue, May 7, 2013 at 9:56 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Protocol to Access WS database Working >> Group of the IETF. >> >> Title : Protocol to Access Spectrum Database >> Author(s) : Vincent Chen >> Subir Das >> Lei Zhu >> John Malyar >> Peter J. McCann >> Filename : draft-ietf-paws-protocol-04.txt >> Pages : 88 >> Date : 2013-05-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 manage spectrum sharing uses databases to report >> spectrum availability to devices. To achieve interoperability among >> multiple devices and databases, a standardized protocol must be >> defined and implemented. This document defines such a protocol, the >> "Protocol to Access White Space database" (PAWS). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-paws-protocol-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> > > > > -- > -vince > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- ben@crouchingbadger.com | http://www.crouchingbadger.com --14dae93d8c868c354604dce994ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vince,

This is my first post to the PAWS list (and indee= d any IETF draft) so please let me know if I'm not following procedure.=

I'm glad draft 04 covers database discovery i= n more detail. I'm still curious about the Error Handling section.=A0

I understand a grace period is useful and necessary whe= n no databases are contactable by the Device for a short period.
=
Does this also handle the scenario of the Device losing cont= act with the regulatory domain's Listing Server? Should Devices trying = to update their database entry from a Listing Server which has gone away ha= ve a grace period/hold timer too? Or does the first failed attempt cause co= mplete shutdown of the Device?

Thanks
Ben

On 8 May 2013 06:01, Vincent Chen <vchen@google.com> w= rote:
All,

I h= ave uploaded a new version that incorporates the items discussed at the pre= vious F2F and
on the list.

Diff:=A0h= ttp://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-03&difftype= =3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-04

Summary of changes:

=A0 = =A0o =A0Expanded the Database Discovery mechanism to describe in more
=
=A0 =A0 =A0 detail pre-configuration with URIs of databases and databa= se-
=A0 =A0 =A0 listing services, including mechanisms for updating the
=A0 =A0 =A0 configurations when things change
=A0 =A0 =A0= * =A0Add database-change field to Available Spectrum Response
= =A0 =A0 =A0 =A0 =A0(Section 4.4.2)
=A0 =A0o =A0Added fields that are anticipated to be needed by the ETSI=
=A0 =A0 =A0 harmonized standard for White Space Devices:
=A0 =A0 =A0 * =A0Added bandwidth constraints to the Available Spectrum R= esponse
=A0 =A0 =A0 =A0 =A0(Section 4.4.2)
=A0 =A0 =A0 * =A0Updated Avail= able Spectrum Response to return RulesetInfo,
=A0 =A0 =A0 =A0 =A0= rather than just a rule-set identifier
=A0 =A0 =A0 * =A0Added opt= ional device-manufacturer and device-model IDs to the
=A0 =A0 =A0 =A0 =A0DeviceDescriptor (Section 5.2). message. =A0Also mo= ved fccId from
=A0 =A0 =A0 =A0 =A0this message to the IANA sectio= n.
=A0 =A0 =A0 * =A0Expanded IANA (Section 9) sections
= =A0 =A0o =A0Clarified restrictions on the specification of the vertices of = a
=A0 =A0 =A0 Polygon.
=A0 =A0o =A0Changed default confidence = level to 95% for a point with
=A0 =A0 =A0 uncertainty
= =A0 =A0o =A0Clarified how devices without absolute time source can use the<= /div>
=A0 =A0 =A0 timestamps in the response messages
=A0 =A0o =A0Change method names to start with "spectrum.paws.&quo= t; prefix
=A0 =A0o =A0Added maximum string lengths
=A0 = =A0o =A0Updated author contact info
=A0 =A0o =A0More typo fixes

There are still some TBDs associated with the ETSI additions, but otherwise= has addressed all our prior open issues.

-vince


On Tue, May 7, 2013 at 9:56 PM, <internet-drafts@ietf.org><= /span> wrote:

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

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

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

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


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

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


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

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



--
-vince

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




--
ben@crouchingbadger.c= om | http:= //www.crouchingbadger.com
--14dae93d8c868c354604dce994ca-- From vchen@google.com Mon May 20 09:41:47 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288D621F9626 for ; Mon, 20 May 2013 09:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBORuvK5IMst for ; Mon, 20 May 2013 09:41:46 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57721F9540 for ; Mon, 20 May 2013 09:41:46 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id 9so14373898iec.36 for ; Mon, 20 May 2013 09:41:46 -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=0B098o4XTVEk/slz5JGaG1OtLOL44hhXOAf5D9p1Fso=; b=DV589BGCpFlidDpEQhc8VVMPx6z6D6utW82UNM35AbGJa0c/0MAfMY0SbjEQNFX69I 0fe2Zo/k5OIUGMOa1qDoYswfNgUzNXUJxVHKSMrXzppAesVpPBuHSPzD6ICyztS83yW5 usTdAYQypYwvOKIIB1UrfyvvxaqwaTA7swwfNDX/UVdae+bsN/Dd2y41cK1ELBnG/owc 6kfltDnV76LWy3vqSXiedhay/auqosO/z79clTTylEN8gWqWGfTQ669nQ3AiVWoLZLDD WvfnwvaLccKZHFaGRNJorAwNGK5SlWcH5CYAtnKTRBBj8p85SXI9+zFpfIQMac+1BEeL N2fA== X-Google-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:x-gm-message-state; bh=0B098o4XTVEk/slz5JGaG1OtLOL44hhXOAf5D9p1Fso=; b=IT9diVlySR9o4yNe/s8KbxKmKoCfwd7JSZVQMb0iK5JX/kimB5Ekft2xaUtzx0dOU3 WzFEAVzF8dB1AqPwP1JBpgWrlutbQaodAmxydVAanpRGRt2RE4fo8UT4CBf2NmFQwwjG 5hD3deb6mf51tHbe5Ieyk8xA8NZ7qYrtKkHa13vmwwxImOMXmxe3cxjvVwBAj5eHJ/qH WxEgVzQDRD3T6sLsVOsBFnGzLgba+BwFJTj56SfxIWrYufAcNA4hMWFZkIOfbz5v/z2m lwB4qSUyiDNV6zlm6evJfJM+Lh/TUFfcsFMHtOvscT/68ep7hBLTXdtz96W0WJTT2b7t SQzg== MIME-Version: 1.0 X-Received: by 10.50.164.129 with SMTP id yq1mr5819871igb.112.1369068105904; Mon, 20 May 2013 09:41:45 -0700 (PDT) Received: by 10.64.45.102 with HTTP; Mon, 20 May 2013 09:41:45 -0700 (PDT) In-Reply-To: <5D3E853BEE49C848BB63047C794C8655AE983D6D@WOK-INTRA-EXC02.intra.ofcom.local> References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760224C913@008-AM1MPN1-006.mgdnok.nokia.com> <5D3E853BEE49C848BB63047C794C8655AE983D6D@WOK-INTRA-EXC02.intra.ofcom.local> Date: Mon, 20 May 2013 09:41:45 -0700 Message-ID: From: Vincent Chen To: Cesar Gutierrez Content-Type: multipart/alternative; boundary=089e013a01ba206a6e04dd2902ce X-Gm-Message-State: ALoCoQmuTNS5j9hebjpm1MFPnhPOGf6/991/tiUpJByaNYMt7TQCn8mLa3XO8ncvMT2kTTMiA8RizG8Q8UwUTWXxrOWwcjO4JMvJWEpdHlu9yPv5VipSGpQQGvN5BYoGGasFbAv3Mv9kpZB/0eLyr2N641azlWIWg3vUzNF5QJZLiEiq0FUucgBK5g4GGbADBVzhyr3LvIsn Cc: "paws@ietf.org" , Reza Karimi Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 16:41:47 -0000 --089e013a01ba206a6e04dd2902ce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cesar, Questions and comment inline. On Fri, May 17, 2013 at 4:02 AM, Cesar Gutierrez < Cesar.Gutierrez@ofcom.org.uk> wrote: > Vince and all, > > > > Another issue that has slipped under the radar. > > > > We have the concept of =93Generic operational parameters=94 in ETSI and t= he > UK. These are the spectrum use parameters that ANY Slave in the coverage > area of a Master can use. The values of these parameters will be > broadcasted by the Master, and a Slave will normally use them to > =93associate=94 and eventually get =93specific operational parameters=94 = which will > be tailored to the Slave precise location and device characteristics. > However, it is possible that some Slaves, for instance cheap devices that > cannot geolocate, will continue using the generic operational parameters = in > normal operations (after association) > In the PAWS specification, a "Slave" device is defined to be one that does not have its own geo-location capability. If a device does have geo-location capability, then: - It MAY uses the generic operation parameters to establish access to the database via the Master - It makes its own request (as a Master) to the database, providing its own geo location - It MAY change to the operational parmeters I think that satisfies the requirements. > > To be clear, the Generic operational parameters are used by Slaves, > although the database will calculate these parameters on the basis of > information from the Master. The calculation requires the location of the > Master, and the power levels it uses. With this, the database can 1) > calculate the coverage area of the Master, 2) assume that a Slave might b= e > in any location within that area, and 3) calculate a set of generic > parameters on that could be used anywhere in the coverage area. Note that > the Master must have requested and obtained operational parameters for > itself before engaging in this. Therefore, the database already knows the > Master=92s location and intended power (this through the SPECTRUM_USE_NOT= IFY > procedure). > > > > I think that a simple way to implement the request for generic operationa= l > parameters could be to re-use the AVAIL_SPECTRUM_REQ procedure, with the > addition of a flag to indicate to the database that the request is for > generic operational parameters and not for operational parameters for the > Master itself, or for a specific slave. > Sounds reasonable. Some regulatory domains, of course, may not allow this mode. > > > Thanks and regards, > > Cesar > > > > > --089e013a01ba206a6e04dd2902ce Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Cesar,

Questions and comment inli= ne.

On Fri, May 17, 2013 at 4:02 AM, Cesar Gutierrez <Cesa= r.Gutierrez@ofcom.org.uk> wrote:

Vince and all,

=A0

Another issue that has sl= ipped under the radar.

=A0

We have the concept of = =93Generic operational parameters=94 in ETSI and the UK. These are the spec= trum use parameters that ANY Slave in the coverage area of a Master can use. The values of these parameters will be broadcasted by the = Master, and a Slave will normally use them to =93associate=94 and eventuall= y get =93specific operational parameters=94 which will be tailored to the S= lave precise location and device characteristics. However, it is possible that some Slaves, for instance cheap devices that = cannot geolocate, will continue using the generic operational parameters in= normal operations (after association)


In the PAWS specification, a "Slave" de= vice is defined to be one that does not have its own geo-location capabilit= y. If a device does have geo-location capability, then:
=A0- It MAY uses the generic operation parameters to establish access to th= e database via the Master
=A0- It makes its own request (as= a Master) to the database, providing its own geo location
=A0- It MAY change to the operational parmeters

<= div style>I think that satisfies the requirements.

=A0

To be clear, the Generic = operational parameters are used by Slaves, although the database will calcu= late these parameters on the basis of information from the Master. The calculation requires the location of the Master, and the p= ower levels it uses. With this, the database can 1) calculate the coverage = area of the Master, 2) assume that a Slave might be in any location within = that area, and 3) calculate a set of generic parameters on that could be used anywhere in the coverage area.= Note that the Master must have requested and obtained operational paramete= rs for itself before engaging in this. Therefore, the database already know= s the Master=92s location and intended power (this through the SPECTRUM_USE_NOTIFY procedure).

=A0

I think that a simple way= to implement the request for generic operational parameters could be to re= -use the AVAIL_SPECTRUM_REQ procedure, with the addition of a flag to indicate to the database that the request is for generic oper= ational parameters and not for operational parameters for the Master itself= , or for a specific slave.


Sounds reasonable. Some regulatory domains, of course, may= not allow this mode.
=A0

=A0

Thanks and regards,

Cesar

=A0


<= /div> --089e013a01ba206a6e04dd2902ce-- From weixinpeng@huawei.com Tue May 21 18:11:03 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2207011E80A4 for ; Tue, 21 May 2013 18:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTlSGoNoCAis for ; Tue, 21 May 2013 18:10:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23B4721F8F62 for ; Tue, 21 May 2013 18:10:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATA24689; Wed, 22 May 2013 01:10:56 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 02:10:41 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 02:10:50 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Wed, 22 May 2013 09:10:39 +0800 From: Weixinpeng To: "paws@ietf.org" Thread-Topic: draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGw== Date: Wed, 22 May 2013 01:10:38 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43CA30EFCnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 01:11:03 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43CA30EFCnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei --_000_C5C3BB522B1DDF478AA09545169155B43CA30EFCnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

     &= nbsp;   I have uploaded a new version draft on database discovery= . Comments are welcomed.

ht= tp://tools.ietf.org/html/draft-wei-paws-database-discovery-01.

 

 

Xinpeng Wei

--_000_C5C3BB522B1DDF478AA09545169155B43CA30EFCnkgeml507mbxchi_-- From wwwrun@rfc-editor.org Wed May 22 08:28:30 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4521F90F1; Wed, 22 May 2013 08:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3B8AG2MjP1P; Wed, 22 May 2013 08:28:29 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9621F90EE; Wed, 22 May 2013 08:28:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 496C7B1E009; Wed, 22 May 2013 08:27:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130522152756.496C7B1E009@rfc-editor.org> Date: Wed, 22 May 2013 08:27:56 -0700 (PDT) Cc: paws@ietf.org, rfc-editor@rfc-editor.org Subject: [paws] RFC 6953 on Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:28:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6953 Title: Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements Author: A. Mancuso, Ed., S. Probasco, B. Patil Status: Informational Stream: IETF Date: May 2013 Mailbox: amancuso@google.com, scott@probasco.me, basavpat@cisco.com Pages: 23 Characters: 53560 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt URL: http://www.rfc-editor.org/rfc/rfc6953.txt Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented. This document is a product of the Protocol to Access WS database Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mark@azu.ca Wed May 22 08:29:10 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720F721F8A74 for ; Wed, 22 May 2013 08:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxndZV1wK78B for ; Wed, 22 May 2013 08:29:05 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB0321F8E93 for ; Wed, 22 May 2013 08:29:05 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o17so2792979oag.41 for ; Wed, 22 May 2013 08:29:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=Qitv3IVDPtqXCxBHI4oxkhFpEYwqC6tGwVRL0lgIgTk=; b=g6PovXGivOMS9V+tntuSrx9BJ0gIjcKaj0kSG8PsLz9rdNohB6KF7X7WLSxyay2A4j y/OszfMgvu7pJ+E0BFKPVvLWLQR0IL3D6Oz5MVoKuUrMgt4ggML7zJ3lT+vEqMkE6VEf OM0DRW2qjrMT70VpOO1bbbdm2JASeuNZ2gDEDECIRwPontmeBWsN37qgtXSh/aK2Mq3n 63/Kp8UYQydiQaAz4AUZ4IVk+6kKeZbn0p35FZbDCEZZN9SFfI7KsckAZb6vkt2+MfuB hKe4P7sxjqtro38GRTsnNVGaoAFeOwJmKBtg6sVjw+vCTX5VbKYD+6R707uhKM5W3O4v oI3Q== X-Received: by 10.60.121.106 with SMTP id lj10mr5266456oeb.128.1369236545080; Wed, 22 May 2013 08:29:05 -0700 (PDT) Received: from victor (69-165-145-59.dsl.teksavvy.com. [69.165.145.59]) by mx.google.com with ESMTPSA id ln8sm7796733obb.3.2013.05.22.08.29.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 May 2013 08:29:03 -0700 (PDT) From: "Mark Jones" To: "'Weixinpeng'" , References: In-Reply-To: Date: Wed, 22 May 2013 11:29:00 -0400 Message-ID: <004f01ce5701$16c11720$44434560$@azu.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01CE56DF.8FB1E820" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFYo+VXBs/17kMZVWofdvD7MTZ5AJn8s3/g Content-Language: en-ca X-Gm-Message-State: ALoCoQmKAHOxo1vZQXz67dn2XtsMN3Dve1jm1zDr62MWpIpA+Le/9vjG0br8CyuKOv3AFXrXMgH3 Cc: 'Peter McCann' Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:29:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0050_01CE56DF.8FB1E820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I'm unclear on how the Master device obtains the URL of a trusted discovery server unless there is some pre-configuration involved. I understand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a preferred/home domain that is then resolved with U-NAPTR) but I don't see how DHCP could be used to bootstrap this information in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comments are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei ------=_NextPart_000_0050_01CE56DF.8FB1E820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Xinpeng,

 

In = section 3, you state:

 

   The = URL or IP address of WSDB DS can be found by any method such = as

   DNS, = DHCP, manually configuring etc, and it is out of scope of = this

   = document.

 

I’m unclear on how the = Master device obtains the URL of a trusted discovery server unless there = is some pre-configuration involved. I understand that DNS could be used = if the Master device is already pre-configured with a preferred/home = TVWS DS URL (or a preferred/home domain that is then resolved with = U-NAPTR) but I don’t see how DHCP could be used to bootstrap this = information in the TVWS scenarios. Please could you = elaborate.

 

Thanks

Mark

 

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Weixinpeng
Sent: May-21-13 9:11 PM
To: = paws@ietf.org
Cc: Peter McCann
Subject: [paws] = draft-wei-paws-database-discovery-01

 

Hi all,

      =    I have uploaded a new version draft on database discovery. = Comments are welcomed.

= http://tools.ietf.org/html/draft-wei-paws-database-discovery-01.=

 

 

Xinpeng = Wei

------=_NextPart_000_0050_01CE56DF.8FB1E820-- From hannes.tschofenig@gmx.net Wed May 22 09:17:41 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1A221F96A2 for ; Wed, 22 May 2013 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H6c0IbWNx8O for ; Wed, 22 May 2013 09:17:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5FD21F969F for ; Wed, 22 May 2013 09:17:36 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Mfl5W-1UrEQl29oa-00N6vf for ; Wed, 22 May 2013 18:17:35 +0200 Received: (qmail invoked by alias); 22 May 2013 16:17:35 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.219.140] by mail.gmx.net (mp024) with SMTP; 22 May 2013 18:17:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+V++dMSleVG/PH8QApPtG18n8Dp2o1gwBS0OD0YZ VfR/a5FIYY1C6W Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Hannes Tschofenig In-Reply-To: <004f01ce5701$16c11720$44434560$@azu.ca> Date: Wed, 22 May 2013 19:17:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <53819D7B-84F9-4CE4-9D34-D8B43A6AB4B4@gmx.net> References: <004f01ce5701$16c11720$44434560$@azu.ca> To: "Mark Jones" X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: paws@ietf.org, 'Peter McCann' Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 16:17:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Mark,=20 if this follows LoST closely then the mechanisms are pretty much = standard procedures used in a number of other protocols as well: First, you can pre-configure your server (since LoST would allow you to = get a response regardless where it enters the system). This makes a = sense since you may get your server configured statically as part of the = software default configuration.=20 Second, you can dynamically obtain information about a server that is = closer to your device via DHCP or (if that does not work) via a DNS = lookup that first uses a reverse DNS lookup of the public IP address.=20 Does this help?=20 Ciao Hannes On May 22, 2013, at 6:29 PM, Mark Jones wrote: > I=E2=80=99m unclear on how the Master device obtains the URL of a = trusted discovery server unless there is some pre-configuration = involved. I understand that DNS could be used if the Master device is = already pre-configured with a preferred/home TVWS DS URL (or a = preferred/home domain that is then resolved with U-NAPTR) but I don=E2=80=99= t see how DHCP could be used to bootstrap this information in the TVWS = scenarios. Please could you elaborate. >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRnO+aAAoJEGhJURNOOiAtt8IH/AoLd2re9qEoSKNTJnf2pEUC /wz7QnJ8q77JKGwWY9imoeHMBp35M+1wnIS6dbKmRQQQYaFfbW/9ffkEhBVYPBga HWpjl6acEulUBq4HaKJYQE4JZ7FMVlH1LZrblkNRTGYaflNFGFFlKf9jhxGOXZzi grV/FOb6wATFp8lhGscwZ2iIK7j6p0rpx231YJtb5IqGc7wXho6wuGFlaaB8k+v+ ayFVi7k/KUzXuk2madYwSXGDZjHwlwQfO1kvwZ1FC8oHHNDfZOI65rzawM+59n6T 6hpkRE1AnFdn26+zD14QTFkyWeHzjntkJK0BFamyi6TReHozmyQ4BCBeFTO8+u0=3D =3DLCBT -----END PGP SIGNATURE----- From mark@azu.ca Wed May 22 12:36:42 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ABC11E8159 for ; Wed, 22 May 2013 12:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3TG+Lzgv8uG for ; Wed, 22 May 2013 12:36:41 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 266CF11E8152 for ; Wed, 22 May 2013 12:36:40 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va2so2903485obc.27 for ; Wed, 22 May 2013 12:36:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=g8IDrx5hWe46Q28myDzH6cqLruQmzSAzlAOyQDwmk9I=; b=YQ1NE9/YtRKbrzl2LpVjInFSNfQ8yZMKcQRYXsJL5Er3wt1rohbQ0w4pgOO5D0dN/c RpLcUAsdQKus6kD6UY+3e/QY38W/FXys1WWsBLcIooD344BbBkXndPzdXKjV9j5gtDyC 32MNKrXCTgqaHvydxxccdc/v6Jh3AMtNEVPmn3GtJQZK4rIbHofzeab7Oy+cntJMNNl+ mommgfQZZpAo9DE7lOzqatXng09Wv9pzaQdsfkpcSOZ0gSX1ORBXVaAfZmaope4DoU9k /2HOR1KBeUn/EXrm0KjAvs4HPM+5KUdtaQEpkPG6/c3cfSvloFJ3bE2mYKzf/g8SUCyt mywQ== X-Received: by 10.60.79.68 with SMTP id h4mr6288735oex.39.1369251400324; Wed, 22 May 2013 12:36:40 -0700 (PDT) Received: from victor (69-165-145-59.dsl.teksavvy.com. [69.165.145.59]) by mx.google.com with ESMTPSA id c20sm9084080oez.4.2013.05.22.12.36.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 May 2013 12:36:39 -0700 (PDT) From: "Mark Jones" To: "'Hannes Tschofenig'" References: <004f01ce5701$16c11720$44434560$@azu.ca> <53819D7B-84F9-4CE4-9D34-D8B43A6AB4B4@gmx.net> In-Reply-To: <53819D7B-84F9-4CE4-9D34-D8B43A6AB4B4@gmx.net> Date: Wed, 22 May 2013 15:36:35 -0400 Message-ID: <005901ce5723$ad0c2810$07247830$@azu.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFYo+VXBs/17kMZVWofdvD7MTZ5AAFoS6HfAthmxB2Z2tjbsA== Content-Language: en-ca X-Gm-Message-State: ALoCoQk3fQT8Fv7kH90GeW1N0xfi/hf+iyKNdIly3Mznm5m2E4ilkkNm/BU6IaRlp/Pp+C966v4I Cc: paws@ietf.org, 'Peter McCann' Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 19:36:42 -0000 Hi Hannes, Thanks for the explanation. Some comments/questions are inline below. > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: May-22-13 12:17 PM > To: Mark Jones > Cc: Hannes Tschofenig; 'Weixinpeng'; paws@ietf.org; 'Peter McCann' > Subject: Re: [paws] draft-wei-paws-database-discovery-01 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi Mark, >=20 > if this follows LoST closely then the mechanisms are pretty much = standard > procedures used in a number of other protocols as well: >=20 > First, you can pre-configure your server (since LoST would allow you = to get a > response regardless where it enters the system). This makes a sense = since > you may get your server configured statically as part of the software = default > configuration. >=20 Understood but I thought the goal of this draft was to get away from = device pre-configuration. If one still has to configure the device with = a URL then why not eliminate LoST and configure it with the URL of its = "home WSDB" instead. If the device is roaming then it could get a = redirect off the initial PAWS INIT_REQ/INIT_RESP to give it the URL of = the WSDB appropriate for its roaming location.=20 I realize that I'm coming late to these discussions so perhaps I missed = a regulatory requirement that the WSDB DS provider be distinct from the = WSDB provider. I don=E2=80=99t have an anti-LoST agenda here. I'm just = trying to understand the motivation for a separate service. > Second, you can dynamically obtain information about a server that is = closer > to your device via DHCP or (if that does not work) via a DNS lookup = that first > uses a reverse DNS lookup of the public IP address. >=20 These DHCP or reverse DNS methods assume that the non-WS IP connectivity = provider (backhaul provider) has some business relationship with a WSDB = DS provider for a given location. Is that correct? > Does this help? >=20 It does but I think this needs to be elaborated further in this draft. = This is the mandatory first step in the discovery procedure so I think = it needs more than an "out of scope", e.g. a few examples referring to = the scenarios in the requirements draft. Regards Mark > Ciao > Hannes >=20 > On May 22, 2013, at 6:29 PM, Mark Jones wrote: >=20 > > I=E2=80=99m unclear on how the Master device obtains the URL of a = trusted > discovery server unless there is some pre-configuration involved. I > understand that DNS could be used if the Master device is already pre- > configured with a preferred/home TVWS DS URL (or a preferred/home > domain that is then resolved with U-NAPTR) but I don=E2=80=99t see how = DHCP could > be used to bootstrap this information in the TVWS scenarios. Please = could > you elaborate. > > >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBCgAGBQJRnO+aAAoJEGhJURNOOiAtt8IH/AoLd2re9qEoSKNTJnf2pE > UC > /wz7QnJ8q77JKGwWY9imoeHMBp35M+1wnIS6dbKmRQQQYaFfbW/9ffkEhB > VYPBga > HWpjl6acEulUBq4HaKJYQE4JZ7FMVlH1LZrblkNRTGYaflNFGFFlKf9jhxGOXZzi > grV/FOb6wATFp8lhGscwZ2iIK7j6p0rpx231YJtb5IqGc7wXho6wuGFlaaB8k+v+ > ayFVi7k/KUzXuk2madYwSXGDZjHwlwQfO1kvwZ1FC8oHHNDfZOI65rzawM+5 > 9n6T > 6hpkRE1AnFdn26+zD14QTFkyWeHzjntkJK0BFamyi6TReHozmyQ4BCBeFTO8+ > u0=3D > =3DLCBT > -----END PGP SIGNATURE----- From weixinpeng@huawei.com Wed May 22 20:13:31 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2183911E8134 for ; Wed, 22 May 2013 20:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw+gRwMAx5Ms for ; Wed, 22 May 2013 20:13:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A176511E812C for ; Wed, 22 May 2013 20:13:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARQ44176; Thu, 23 May 2013 03:13:21 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 04:13:07 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 04:13:19 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Thu, 23 May 2013 11:13:11 +0800 From: Weixinpeng To: Mark Jones , "paws@ietf.org" Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGwANNtsAACiGISA= Date: Thu, 23 May 2013 03:13:10 +0000 Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> In-Reply-To: <004f01ce5701$16c11720$44434560$@azu.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43CA320D3nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 03:13:31 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43CA320D3nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. Besides, using DHCP method doesn't means IP network prov= ider must have some business relationship with WSDB DS provider, if the net= work provider wants to provide master device with FQDN of WSDB DS it can us= e DHCP. Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I'm unclear on how the Master device obtains the URL of a trusted discovery= server unless there is some pre-configuration involved. I understand that = DNS could be used if the Master device is already pre-configured with a pre= ferred/home TVWS DS URL (or a preferred/home domain that is then resolved w= ith U-NAPTR) but I don't see how DHCP could be used to bootstrap this infor= mation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei --_000_C5C3BB522B1DDF478AA09545169155B43CA320D3nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mark= ,

 &= nbsp;       Thanks for your feedback, and I t= hink there are some issues that I need to clarify.

 &= nbsp;      

 &= nbsp;       we have to be clear that the disc= overy mechanism is provided as an optional method that can help master devi= ce to find the correct WSDB, which means the master device can get WSDB by,= such as, pre-configuring of WSDB, provision etc.

 &= nbsp;      

 &= nbsp;       The dynamic discovery mechanism p= rovides more convenient for master device to find WSDB, for example, when a= new WSDB is setup for providing service or when some deployed WSDB goes do= wn and never work.

 &= nbsp;      

 &= nbsp;       About the DHCP you mentioned belo= w, technically speaking, there have been some extension of DHCP for support= ing the provision of LoST server, refer to RFC5223. Besides, using DHCP met= hod doesn’t means IP network provider must have some business relationsh= ip with WSDB DS provider, if the network provider wants to provide master d= evice with FQDN of WSDB DS it can use DHCP.

&n= bsp;

Best Re= gards,

Xinpeng= .

&n= bsp;

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; paws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Hi Xinpeng,

 

In section 3, you state:

 

&= nbsp;  The URL or IP address of WSDB DS can be found by any method suc= h as

&= nbsp;  DNS, DHCP, manually configuring etc, and it is out of scope of = this

&= nbsp;  document.

 

I’m unclear on how the Master device obtains the URL of a t= rusted discovery server unless there is some pre-configuration involved. I = understand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a p= referred/home domain that is then resolved with U-NAPTR) but I don’t = see how DHCP could be used to bootstrap this information in the TVWS scenar= ios. Please could you elaborate.

 

Thanks

Mark

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

 

Hi all,

     &= nbsp;   I have uploaded a new version draft on database discovery= . Comments are welcomed.

h= ttp://tools.ietf.org/html/draft-wei-paws-database-discovery-01.

 

 

Xinpeng Wei

--_000_C5C3BB522B1DDF478AA09545169155B43CA320D3nkgeml507mbxchi_-- From mark@azu.ca Thu May 23 07:30:47 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47D821F92EB for ; Thu, 23 May 2013 07:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdeuOdxKCfff for ; Thu, 23 May 2013 07:30:42 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9BECE21F9193 for ; Thu, 23 May 2013 07:30:42 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id 1so1903402qec.39 for ; Thu, 23 May 2013 07:30:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=z3E6CBSMmFue5tPX7J26YxfiB4WEHz1Ai4/8GlweyEo=; b=FKF64+kq0/k2w9wE7Mu/JJdOGOO+zO8eG88Zi+aDajJ4AwBwCO4vEbh4E80kpF6oTa 9leLm5YsgO8V1zlBUtD5/ixVqGJntWqbykR7980CfnsrNGnIRXBUbzAkhGwIUl6C5U4A FyT3ygJeZWdwqjaE5B9RkQst9ty+Z4w7vpwgZW7vhqQJhDjPxrZ0kUGWvrHm+lxu2y0d 5bkyDv7whplUNLOrGyoM7GPO4Vs6PeOgHfM8rebI1lk2MDyXpeAPmluLAjBKaRAiF0YX Lqq0+mHx/MdV4ayTFFqEEL1s/3paKil4W2faq+2zz7JURY5QqBCtp8cNzwNvk0af0wvW 2AxA== X-Received: by 10.224.22.197 with SMTP id o5mr11681543qab.52.1369319437833; Thu, 23 May 2013 07:30:37 -0700 (PDT) Received: from victor (dynamic22-11.netcelerate.net. [208.87.22.11]) by mx.google.com with ESMTPSA id h13sm11650805qej.1.2013.05.23.07.30.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 May 2013 07:30:36 -0700 (PDT) From: "Mark Jones" To: "'Weixinpeng'" , References: <004f01ce5701$16c11720$44434560$@azu.ca> In-Reply-To: Date: Thu, 23 May 2013 10:30:33 -0400 Message-ID: <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CE57A0.8F97D7C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFYo+VXBs/17kMZVWofdvD7MTZ5AAFoS6HfARsycuGZ6hEbgA== Content-Language: en-ca X-Gm-Message-State: ALoCoQlRv/vf2opcvJT/En2Z3hkQQKLMSRnemwbX/KemF3z4pankXcqplOplPrmS7c5na2nw3GdB Cc: 'Peter McCann' Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 14:30:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01CE57A0.8F97D7C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I need to clarify. we have to be clear that the discovery mechanism is provided as an optional method that can help master device to find the correct WSDB, which means the master device can get WSDB by, such as, pre-configuring of WSDB, provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for master device to find WSDB, for example, when a new WSDB is setup for providing service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient mechanism to manage WSDB instances being commissioned or decommissioned. I view LoST as a kind of "location-aware DNS" so I understand its applicability to discovery of the appropriate WSDB. I still think the draft needs more information on how the Master device finds its WSDB DS so that implementers understand if/when this optional discovery method is applicable to their deployment. About the DHCP you mentioned below, technically speaking, there have been some extension of DHCP for supporting the provision of LoST server, refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be provided to the Master device when it initiated its backhaul connection (non-WS connection) to the internet. Correct? Besides, using DHCP method doesn't means IP network provider must have some business relationship with WSDB DS provider, if the network provider wants to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send options to provision the WSDB DS then I assume he has some business interest in doing so. What am I missing? Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I'm unclear on how the Master device obtains the URL of a trusted discovery server unless there is some pre-configuration involved. I understand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a preferred/home domain that is then resolved with U-NAPTR) but I don't see how DHCP could be used to bootstrap this information in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comments are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei ------=_NextPart_000_000D_01CE57A0.8F97D7C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Xinpeng,

 

Thank = you for your responses. I have some further comments/questions inline = below (prefixed by = mj>).

 

From:= Weixinpeng = [mailto:weixinpeng@huawei.com]
Sent: May-22-13 11:13 = PM
To: Mark Jones; paws@ietf.org
Cc: Peter McCann; = Zhulei (A)
Subject: RE: [paws] = draft-wei-paws-database-discovery-01

 

Hi = Mark,

   &nbs= p;     Thanks for your feedback, and I think there = are some issues that I need to clarify.

   &nbs= p;    

   &nbs= p;     we have to be clear that the discovery = mechanism is provided as an optional method that can help master device = to find the correct WSDB, which means the master device can get WSDB by, = such as, pre-configuring of WSDB, provision etc. =

 

mj> = Understood.

=  

   &nbs= p;     The dynamic discovery mechanism provides more = convenient for master device to find WSDB, for example, when a new WSDB = is setup for providing service or when some deployed WSDB goes down and = never work.

   &nbs= p;    

mj> = In this regard, DNS resolution would appear to be equally convenient = mechanism to manage WSDB instances being commissioned or decommissioned. = I view LoST as a kind of “location-aware DNS” so I = understand its applicability to discovery of the appropriate WSDB. I = still think the draft needs more information on how the Master device = finds its WSDB DS so that implementers understand if/when this optional = discovery method is applicable to their = deployment.

=  

   &nbs= p;     About the DHCP you mentioned below, = technically speaking, there have been some extension of DHCP for = supporting the provision of LoST server, refer to RFC5223.

=

=  

mj> I = understand that the DHCP option specifying the LoST server would be = provided to the Master device when it initiated its backhaul connection = (non-WS connection) to the internet. Correct?

=

Besides, using DHCP = method doesn’t means IP network provider must have some business = relationship with WSDB DS provider, if the network provider wants to = provide master device with FQDN of WSDB DS it can use = DHCP.

 

mj> = If the backhaul network operator is configuring his DHCP server to send = options to provision the WSDB DS then I assume he has some business = interest in doing so. What am I missing?

&nbs= p;

Thanks

Mark=

=  

Best = Regards,

Xinpeng.

 

From: Mark Jones [mailto:mark@azu.ca]
Sent: = Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; paws@ietf.org
Cc: Peter = McCann
Subject: RE: [paws] = draft-wei-paws-database-discovery-01

 

Hi = Xinpeng,

=  

In = section 3, you state:

=  

   The URL or IP address of = WSDB DS can be found by any method such as

   DNS, DHCP, manually = configuring etc, and it is out of scope of this

   = document.

=  

IR= 17;m unclear on how the Master device obtains the URL of a trusted = discovery server unless there is some pre-configuration involved. I = understand that DNS could be used if the Master device is already = pre-configured with a preferred/home TVWS DS URL (or a preferred/home = domain that is then resolved with U-NAPTR) but I don’t see how = DHCP could be used to bootstrap this information in the TVWS scenarios. = Please could you elaborate.

=  

Thank= s

Mark<= o:p>

=  

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of Weixinpeng
Sent: May-21-13 9:11 = PM
To: paws@ietf.org
Cc: Peter = McCann
Subject: [paws] = draft-wei-paws-database-discovery-01

 

Hi all,

      =    I have uploaded a new version draft on database discovery. = Comments are welcomed.

= http://tools.ietf.org/html/draft-wei-paws-database-discovery-01.=

 

 

Xinpeng = Wei

------=_NextPart_000_000D_01CE57A0.8F97D7C0-- From weixinpeng@huawei.com Thu May 23 18:59:31 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115C21F9600 for ; Thu, 23 May 2013 18:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgLkyB3UtXWs for ; Thu, 23 May 2013 18:59:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CABF021F9601 for ; Thu, 23 May 2013 18:59:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARR35152; Fri, 24 May 2013 01:59:25 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 02:59:10 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 02:59:23 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Fri, 24 May 2013 09:58:42 +0800 From: Weixinpeng To: Mark Jones , "paws@ietf.org" Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGwFoS6HfARsycuGZ6hEbgJn6/6IQ Date: Fri, 24 May 2013 01:57:35 +0000 Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> In-Reply-To: <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43CA321BDnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 01:59:31 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43CA321BDnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline= below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient me= chanism to manage WSDB instances being commissioned or decommissioned. I vi= ew LoST as a kind of "location-aware DNS" so I understand its applicability= to discovery of the appropriate WSDB. I still think the draft needs more i= nformation on how the Master device finds its WSDB DS so that implementers = understand if/when this optional discovery method is applicable to their de= ployment. [Wei] Yeah, because we cannot covey location information in DNS query messa= ge, so DNS is inappropriate to find the WSDB. I think I will do more clarif= ication about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be p= rovided to the Master device when it initiated its backhaul connection (non= -WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn't means IP network provider must have some= business relationship with WSDB DS provider, if the network provider wants= to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send= options to provision the WSDB DS then I assume he has some business intere= st in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and W= SDB DS. But the reason why DHCP is mentioned here is because in the LoST pr= otocol DHCP is extended to provide LoST server's domain name to the LoST cl= ient. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I'm unclear on how the Master device obtains the URL of a trusted discovery= server unless there is some pre-configuration involved. I understand that = DNS could be used if the Master device is already pre-configured with a pre= ferred/home TVWS DS URL (or a preferred/home domain that is then resolved w= ith U-NAPTR) but I don't see how DHCP could be used to bootstrap this infor= mation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei --_000_C5C3BB522B1DDF478AA09545169155B43CA321BDnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mark= ,

 &= nbsp;       Please see comments inline. Thank= s!

&n= bsp;

Best Re= gards,

Xinpeng= .

&n= bsp;

&n= bsp;

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; paws@ietf.org
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Hi Xinpeng,

 

Thank you for your responses. I have some further comments/questi= ons inline below (prefixed by mj>).

 

From: Weixinpeng [= mailto:weixinpeng@huawei.com]
Sent: May-22-13 11:13 PM
To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Hi Mark= ,

 &= nbsp;       Thanks for your feedback, and I t= hink there are some issues that I need to clarify.

 &= nbsp;      

 &= nbsp;       we have to be clear that the disc= overy mechanism is provided as an optional method that can help master devi= ce to find the correct WSDB, which means the master device can get WSDB by,= such as, pre-configuring of WSDB, provision etc.

&n= bsp;

mj> Understood.

 

 &= nbsp;       The dynamic discovery mechanism p= rovides more convenient for master device to find WSDB, for example, when a= new WSDB is setup for providing service or when some deployed WSDB goes do= wn and never work.

 &= nbsp;      

mj> In this regard, DNS resolution would appear to be equally conv= enient mechanism to manage WSDB instances being commissioned or decommissio= ned. I view LoST as a kind of “location-aware DNS” so I understand its applicability to discovery of the appropria= te WSDB. I still think the draft needs more information on how the Master d= evice finds its WSDB DS so that implementers understand if/when this option= al discovery method is applicable to their deployment.

[= Wei] Yeah, because we cannot covey location information in DNS query messag= e, so DNS is inappropriate to find the WSDB. I think I will do more clarifi= cation about how master device finds WSDB DS later.=

 

 &= nbsp;       About the DHCP you mentioned belo= w, technically speaking, there have been some extension of DHCP for support= ing the provision of LoST server, refer to RFC5223.

 

mj> I understand that the DHCP option specifying the LoST server w= ould be provided to the Master device when it initiated its backhaul connec= tion (non-WS connection) to the internet. Correct?

[= Wei] Yeah.=

 

Besides= , using DHCP method doesn’t means IP network provider must have some = business relationship with WSDB DS provider, if the network provider wants = to provide master device with FQDN of WSDB DS it can use DHCP.

&n= bsp;

mj> If the backhaul network operator is configuring his DHCP serve= r to send options to provision the WSDB DS then I assume he has some busine= ss interest in doing so. What am I missing?

[= Wei] I think there may be some relationship between network operator and WS= DB DS. But the reason why DHCP is mentioned here is because in the LoST pro= tocol DHCP is extended to provide LoST server’s domain name to the LoST client.

 

Thanks

Mark

 

Best Re= gards,

Xinpeng= .

&n= bsp;

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; paws@ietf.org Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Hi Xinpeng,

 

In section 3, you state:

 

&= nbsp;  The URL or IP address of WSDB DS can be found by any method suc= h as

&= nbsp;  DNS, DHCP, manually configuring etc, and it is out of scope of = this

&= nbsp;  document.

 

I’m unclear on how the Master device obtains the URL of a t= rusted discovery server unless there is some pre-configuration involved. I = understand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a p= referred/home domain that is then resolved with U-NAPTR) but I don’t = see how DHCP could be used to bootstrap this information in the TVWS scenar= ios. Please could you elaborate.

 

Thanks

Mark

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

 

Hi all,

     &= nbsp;   I have uploaded a new version draft on database discovery= . Comments are welcomed.

h= ttp://tools.ietf.org/html/draft-wei-paws-database-discovery-01.

 

 

Xinpeng Wei

--_000_C5C3BB522B1DDF478AA09545169155B43CA321BDnkgeml507mbxchi_-- From vchen@google.com Fri May 24 19:17:22 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B237621F95EE for ; Fri, 24 May 2013 19:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw2sM30KYUhK for ; Fri, 24 May 2013 19:17:22 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id F278421F9425 for ; Fri, 24 May 2013 19:17:21 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id f4so6521471iea.23 for ; Fri, 24 May 2013 19:17:21 -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=zUuoC0u6xlbSxMAzQ9t4oFgT1qHCIH1RN9cVJw7mfVs=; b=Qs5nZUnRPuKIiCX6YVdaRymYja0UFT40Kq6Cx+i6y8hW03GIWgE/dYuSXoTC49I53o Q3H6ido1+qLw5817dwkXVaRwXjRUn/fjCPXYzfsu+EYwaX0iSUz2R7sE9bYhYettyWha XWPoUg7GIxBZ5rpE80toGHUFtXC0Ikf6zqX3VbuEWErFOk8N9RKtYJAsG3Rg6irhUs/8 xpSGbK2JD21FvZwOiNxvZPckdwAARk1K4xGOAahjD6GOr8FvJYoOKV2w2ZSuJ6nte4D/ FYCTAxpzhg6yLukKynJcOZDUK7QzLKfiiet/rRkLuglJy2ssa3ykxmhghlX9iovDvOmQ S9GA== X-Google-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:x-gm-message-state; bh=zUuoC0u6xlbSxMAzQ9t4oFgT1qHCIH1RN9cVJw7mfVs=; b=ZPwZvR1yTxqrLJoaclZHvWkgDerblKgrEK2NLAlwqq8v8Okbt1lwqts7FOaH21Y/LE XVuRd6NWjXV14hVF6IuHyNRGH6zpNNh6zkXJWzyWi6lSpAq3HtYA1sg6/ooAwnv9pC5H fGtsvj7C+P0qxe1W1vc+6TdLXiMQYNdP2OJKbPnBp7CZFYBM6RC6PtNCF7XQsTcU1c4Z g8agF0Ou8K8AGU9As+Hmsang0Qq3Ozgz8GWkrrqys2NAwtM8KbS/vDkFwuNbrxeOqGuq sXifGwM/ntcYX5iwn1WV9B5mKhipzOh03CyhYk1Fdobjq+xiMj2xIwj3XDjjkMmvIfrP aneg== MIME-Version: 1.0 X-Received: by 10.50.131.137 with SMTP id om9mr2787453igb.1.1369448241357; Fri, 24 May 2013 19:17:21 -0700 (PDT) Received: by 10.64.43.228 with HTTP; Fri, 24 May 2013 19:17:21 -0700 (PDT) In-Reply-To: References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> Date: Fri, 24 May 2013 19:17:21 -0700 Message-ID: From: Vincent Chen To: Ben Ward Content-Type: multipart/alternative; boundary=047d7b2e1213f6fdff04dd818351 X-Gm-Message-State: ALoCoQkW6asK3WSjNeALjqo5EiFW0gixIM3YZ+p+N9QtrNzvUezJHnQJYro74OpyL1ZQfcrWbnVRoODHLLSm8zTR0at5u5SsZURV0AYO71jr3jRgeGExGEWjknzQFJi1QGmugXbxOLUxnP6TpL+YrK4sSRbRu8/tVXZij4Lz7sPdl9kl9LVSACfFqOta7KfEhYWIVkLvtzqY Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 02:17:22 -0000 --047d7b2e1213f6fdff04dd818351 Content-Type: text/plain; charset=ISO-8859-1 Ben, I'm sorry about letting this slip through without a response. Whether there is a grace period for the Listing Server is determined by a regulator, but it probably makes sense to allow for that parameter in the protocol. The question is, can the current grace-period parameter be applied to both the Database and the Listing Server? or should we add another parameter to maintain flexibility? Thoughts? -vince On Fri, May 17, 2013 at 6:01 AM, Ben Ward wrote: > Vince, > > This is my first post to the PAWS list (and indeed any IETF draft) so > please let me know if I'm not following procedure. > > I'm glad draft 04 covers database discovery in more detail. I'm still > curious about the Error Handling section. > > I understand a grace period is useful and necessary when no databases are > contactable by the Device for a short period. > > Does this also handle the scenario of the Device losing contact with the > regulatory domain's Listing Server? Should Devices trying to update their > database entry from a Listing Server which has gone away have a grace > period/hold timer too? Or does the first failed attempt cause complete > shutdown of the Device? > > Thanks > Ben > > > --047d7b2e1213f6fdff04dd818351 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ben,

I'm sorry about letting = this slip through without a response.

= Whether there is a grace period for the Listing Server is determined by a r= egulator, but it probably makes sense
to allow for that parameter in the protocol.
The question is, can the current grace-period parameter b= e applied to both the Database and the
Listing Server? or s= hould we add another parameter to maintain flexibility?

Thoughts?

-vince


On Fri, May 17, 2013 at 6:01 AM, Ben Ward <ben@c= rouchingbadger.com> wrote:
Vince,

This is my first p= ost to the PAWS list (and indeed any IETF draft) so please let me know if I= 'm not following procedure.

I'm glad draft 04 covers database discovery in more= detail. I'm still curious about the Error Handling section.=A0

I understand a grace period is useful and necessary whe= n no databases are contactable by the Device for a short period.
=
Does this also handle the scenario of the Device losing cont= act with the regulatory domain's Listing Server? Should Devices trying = to update their database entry from a Listing Server which has gone away ha= ve a grace period/hold timer too? Or does the first failed attempt cause co= mplete shutdown of the Device?

Thanks
Ben


--047d7b2e1213f6fdff04dd818351-- From vchen@google.com Tue May 28 22:09:40 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA73521F8ECB for ; Tue, 28 May 2013 22:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th54MIdDBzgJ for ; Tue, 28 May 2013 22:09:39 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2F64721F8EBE for ; Tue, 28 May 2013 22:09:38 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id tp5so7097770ieb.34 for ; Tue, 28 May 2013 22:09:38 -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=jqs5QDqcE2eYbuh+Lz2jcoSVNJG9SFtkaFBOihWDQCo=; b=PuTK5aEAop3wR40brvis145aXtkACnM7esiGzzyo96QmyAKzJJdqIrf93wv2zE/0Qf hBN14XfxA8AaGxh5QErR8gwQg9JuWba4/SkhY++L1pADirNeJmlHwaf5ZvO6JQFP9jlG HdHg8jt784G4bKYu93x9rc8qYiQXU17D76infDf5OlfG6ZGzQ8Ej5zGDAgiwaQ0AsCfd L7kBnY/K/ts/WVldgMtOM/iw9D4OeuqkhJeT4btrZ0h9BcdyYSMb4KnOX1/MWvJxfhPX lH8zwRW3C9KOkuF1mL07xHAV4enYzK204P0MqhymZL2fZUD5KfYPqnw0BZY9KSijwWRD LWtg== X-Google-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:x-gm-message-state; bh=jqs5QDqcE2eYbuh+Lz2jcoSVNJG9SFtkaFBOihWDQCo=; b=UQ+dOXfgWKALuSWdizAgvmiGQhHO5IUXlAtboTqhxh/AhyFx6NWM/8KCZbXt5ssBK/ Y+C35lB4eUf/yPIrO7Di6HGra69slhAy04BCmkY4/0rH+JPG2oOJjx7QVgarSVhMcxmF ETrLVDa/z2bAbSZRa7P13CoMnbJ92anDGCDilTd6CenfpMW+Lk3t672rBknY6ZjAPLlq o4dzIUEnxj1TbRjKMdOQ1y84YUPYbmqP1rfzvBMZjm/4Dy/3RmOzJHGG3bHGMfMO8lJu XLP5KMi3XexnsBylh23nAzz809ciyKeE29m9PJJMjum7joYShJKz1jVxxlSPb2+aBtJU 7IiQ== MIME-Version: 1.0 X-Received: by 10.42.50.202 with SMTP id b10mr448730icg.7.1369804178405; Tue, 28 May 2013 22:09:38 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Tue, 28 May 2013 22:09:38 -0700 (PDT) In-Reply-To: <000001ce5b05$8aa13d70$9fe3b850$@azu.ca> References: <20130508045626.14850.61103.idtracker@ietfa.amsl.com> <000001ce5b05$8aa13d70$9fe3b850$@azu.ca> Date: Tue, 28 May 2013 22:09:38 -0700 Message-ID: From: Vincent Chen To: Mark Jones Content-Type: multipart/alternative; boundary=90e6ba61453a7760f304ddd46306 X-Gm-Message-State: ALoCoQmvVPMqP2KkM+8vKlWpE0lw0IVL/ObpobVP06GUmoJlLhdASvk+mgb00ej1kuDwhSlHVuzCgy5+HT/kgOq1aQwiBwZpNdxOeAX0WKI/djG0CS1xsORTcsjCcHznpVaWaoRdnrWczT/5Zp4prgSQUWXQKbhz8kZsba4pjnaPT9WLsY5KB1wA3lvVwc0qMcJ3RWfQ2Ncm Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-04.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 05:09:40 -0000 --90e6ba61453a7760f304ddd46306 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mark, ** ** > > Apologies for the late comments. In the -04 rev, I noticed that the term > =93listing server=94 is used before it is defined. I suggest adding an en= try > for =93Database Listing Server=94 to the Terminology section to improve > readability. > Thanks. I'll add this to the Terminology section. > **** > > ** ** > > I also wanted to check my understanding of the database discovery clauses= . In section 4, the draft states that database discovery MUST be supported = by Master devices. I understand from the draft that there are two types of = database discovery: pre-configured database discovery and dynamic discovery= . For the pre-configured database discovery, a Master device would determin= e its location and consult its local config to find the appropriate WSDB(s)= . For dynamic discovery, it would use the procedures in section 4.1.1 and c= ontact a Database Listing Server. Is this understanding correct so far? > > I would characterize the second as a preconfiguration of a Database Listing Server, so it's not completely "dynamic". This is driven by Ofcom (and potentially the ETSI) requirement that a regulator may dictate that a device MUST contact a listing server operated by the regulator for an approved list of DBs. This is behavior that must be built into the device. For example, a DB can inform the device that it is in the UK, but the device must map "UK" to the URL of the listing server specified by the UK regulator. > **** > > ** ** > > In section 4.1.1 you state =93Specific message formats are defined by the= regulators=94. In some regulatory domains, the regulator has deferred prot= ocol definition to the market participants but I=92m taking this to mean th= at LoST could be one the =93specific message formats=94 selected by a regul= ator. Is this the correct interpretation? > > I suppose LoST could be one of the formats. One reservation is that it might result in XML vs JSON discussions again :) > **** > > > > -vince --90e6ba61453a7760f304ddd46306 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Mark,

=A0

Apologies for the= late comments. In the -04 rev, I noticed that the term =93listing server= =94 is used before it is defined. I suggest adding an entry for =93Database= Listing Server=94 to the Terminology sec= tion to improve readability.


Thanks. I'll add this to t= he Terminology section.
=A0

=A0

I also wanted to check my understanding of =
the database discovery clauses. In section 4, the draft states that databas=
e discovery MUST be supported by Master devices. I understand from the draf=
t that there are two types of database discovery: pre-configured database d=
iscovery and dynamic discovery. For the pre-configured database discovery, =
a Master device would determine its location and consult its local config t=
o find the appropriate WSDB(s). For dynamic discovery, it would use the pro=
cedures in section 4.1.1 and contact a Database Listing Server. Is this und=
erstanding correct so far?
I would characterize the second as a preconfi= guration of a Database Listing Server, so it's not completely "dyn= amic".
This is driven by Ofcom (and potentially the ETSI) re= quirement that a regulator may dictate that a device MUST contact
a listing server operated by the regulator for an approved list of DBs= . This is behavior that must be built into the device.

=
For example, a DB can inform the device that it is in the UK, but the = device must map "UK" to the URL of the
listing server specified by the UK regulator.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
=A0
In section 4.1.1 you state =93Specific mess=
age formats are defined by the regulators=94. In some regulatory domains, t=
he regulator has deferred protocol definition to the market participants bu=
t I=92m taking this to mean that LoST could be one the =93specific message =
formats=94 selected by a regulator. Is this the correct interpretation?

I suppose LoST could be one of= the formats. One reservation is that it might result in XML vs JSON discus= sions again :)


-vince=A0
--90e6ba61453a7760f304ddd46306--