From internet-drafts@ietf.org Mon Jul 2 11:10:09 2012 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 55B5E21F8775; Mon, 2 Jul 2012 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 485H1iFk-s+y; Mon, 2 Jul 2012 11:10:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBB321F8752; Mon, 2 Jul 2012 11:10:08 -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.21p1 Message-ID: <20120702181008.8632.18696.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 11:10:08 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-06.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, 02 Jul 2012 18:10:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access White Space database: PS, use cases a= nd rqmts Author(s) : Scott Probasco Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-06.txt Pages : 42 Date : 2012-07-02 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes a number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol. The concept of TV white spaces is described including the problems that need to be addressed to enable white space spectrum for additional uses without causing interference to currently assigned use. Use of white space is enabled by querying a database which stores information about the channel availability at any given location and time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-= rqmts-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scott.probasco@nokia.com Mon Jul 2 11:23:28 2012 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 9D63F11E80A2 for ; Mon, 2 Jul 2012 11:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 MHRR4denC0tU for ; Mon, 2 Jul 2012 11:23:27 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 82F3321F845E for ; Mon, 2 Jul 2012 11:23:27 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q62INVPk017625 for ; Mon, 2 Jul 2012 21:23:31 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Jul 2012 21:23:46 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Mon, 2 Jul 2012 20:23:30 +0200 From: To: Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt Thread-Index: AQHNT87waPQcHCLdgEi6NSBAo5lVn5cLHxFQgAU/mICABYvlgA== Date: Mon, 2 Jul 2012 18:23:29 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F55E8B@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.34.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Jul 2012 18:23:46.0441 (UTC) FILETIME=[D19CAF90:01CD587F] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.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, 02 Jul 2012 18:23:28 -0000 Hi All, Version 06 of the document has been uploaded. The only edits are to address Andy's comments. Kind Regards, Scott & Raj On 6/28/12 7:41 PM, "Bajko Gabor (Nokia-CIC/SiliconValley)" wrote: >Folks, > >There have not been any comments to the draft version -05 which would >result in significant changes to the draft. The editors will generate in >the next few days a version -06 to incorporate the minor/editorial >changes requested by Andy, and I will do the write-up and send the draft >to the iesg. > >- Gabor > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >ext andy.sago@bt.com >Sent: Monday, June 25, 2012 8:02 AM >To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org >Subject: Re: [paws] I-D Action: >draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt > >Scott, Raj > >Thank you for all your hard work on the requirements drafts. I've >reviewed draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt and it >appears to cover all the UK and Ofcom requirements as we currently >understand them. I believe that there will be a public url from next week >for the reference for [Ofcom Requirements], and I'll let you know as soon >as this is made available. > >I have a suggestion regarding Figure 8, for clarity. According to the >text, this scenario is not dependent on the air interface being TDD, so >it should be labelled as "WS AirIF" (for consistency with subsequent >figures) instead of "TDD Air Interface". I then suggest that the label is >moved to be next to or across the dotted line between the right hand >master device and the slave device that was added recently under editing. >At the moment it could be interpreted that the slave is wired to the >master. > >Finally I have found just two typos: > >In 6.2 O.2, second sentence: "... have the capability determine its >location..." is missing "to" >In 6.2 O.9, "frequency" is misspelt. > >Regards > >Andy > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >scott.probasco@nokia.com >Sent: 21 June 2012 17:57 >To: paws@ietf.org >Subject: Re: [paws] I-D Action: >draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt > >Hello All, > >This version 05 contains updates from the editors to address the comments >posted to the reflector during 2nd WGLC. We hope this fulfills the work >group's needs & desires, and look forward to continued progress in PAWS. > >Kind Regards, >Scott & Raj > > > >On 6/21/12 11:42 AM, "ext internet-drafts@ietf.org" > wrote: > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Protocol to Access WS database >>Working Group of the IETF. >> >> Title : Protocol to Access White Space database: PS, use >>cases and rqmts >> Author(s) : Scott Probasco >> Basavaraj Patil >> Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt >> Pages : 42 >> Date : 2012-06-21 >> >>Abstract: >> Portions of the radio spectrum that are assigned to a particular use >> but are unused or unoccupied at specific locations and times are >> defined as "white space". The concept of allowing additional >> transmissions (which may or may not be licensed) in white space is a >> technique to "unlock" existing spectrum for new use. An obvious >> requirement is that these additional transmissions do not interfere >> with the assigned use of the spectrum. One approach to using the >> white space spectrum at a given time and location is to verify with a >> database for available channels. >> >> This document describes a number of possible use cases of white space >> spectrum and technology as well as a set of requirements for the >> database query protocol. The concept of TV white spaces is described >> including the problems that need to be addressed to enable white >> space spectrum for additional uses without causing interference to >> currently assigned use. Use of white space is enabled by querying a >> database which stores information about the channel availability at >> any given location and time. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases- >>rqm >>ts >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts- >>05 >> >>A diff from previous version is available at: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecase >>s-r >>qmts-05 >> >> >>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 > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Thu Jul 5 02:57:54 2012 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 69C1621F84B6 for ; Thu, 5 Jul 2012 02:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 tT8J9t2BVtLy for ; Thu, 5 Jul 2012 02:57:53 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB221F84B8 for ; Thu, 5 Jul 2012 02:57:52 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 5 Jul 2012 10:58:04 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.29]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 5 Jul 2012 10:58:04 +0100 From: To: , , Date: Thu, 5 Jul 2012 10:58:02 +0100 Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt Thread-Index: AQHNT87waPQcHCLdgEi6NSBAo5lVn5cLHxFQgAU/mICABYvlgIAEnRIA Message-ID: <619CDADDCCD2B44380834BE8BF6F714140A8EEA91E@EMV62-UKRD.domain1.systemhost.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F55E8B@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.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, 05 Jul 2012 09:57:54 -0000 Scott, Raj, Gabor The reference [Ofcom Requirements] has now been made available, it is http:= //www.cept.org/Documents/se-43/6161/SE43(12)Info11_Ofcom-regulatory-require= ments-for-WSDs-in-the-UHF-TV-band . The words "draft final" can be removed = from the description of the reference. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 02 July 2012 19:23 To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts= -05.txt Hi All, Version 06 of the document has been uploaded. The only edits are to address= Andy's comments. Kind Regards, Scott & Raj On 6/28/12 7:41 PM, "Bajko Gabor (Nokia-CIC/SiliconValley)" wrote: >Folks, > >There have not been any comments to the draft version -05 which would=20 >result in significant changes to the draft. The editors will generate=20 >in the next few days a version -06 to incorporate the minor/editorial=20 >changes requested by Andy, and I will do the write-up and send the=20 >draft to the iesg. > >- Gabor > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of=20 >ext andy.sago@bt.com >Sent: Monday, June 25, 2012 8:02 AM >To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org >Subject: Re: [paws] I-D Action: >draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt > >Scott, Raj > >Thank you for all your hard work on the requirements drafts. I've=20 >reviewed draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt and it=20 >appears to cover all the UK and Ofcom requirements as we currently=20 >understand them. I believe that there will be a public url from next=20 >week for the reference for [Ofcom Requirements], and I'll let you know=20 >as soon as this is made available. > >I have a suggestion regarding Figure 8, for clarity. According to the=20 >text, this scenario is not dependent on the air interface being TDD, so=20 >it should be labelled as "WS AirIF" (for consistency with subsequent >figures) instead of "TDD Air Interface". I then suggest that the label=20 >is moved to be next to or across the dotted line between the right hand=20 >master device and the slave device that was added recently under editing. >At the moment it could be interpreted that the slave is wired to the=20 >master. > >Finally I have found just two typos: > >In 6.2 O.2, second sentence: "... have the capability determine its=20 >location..." is missing "to" >In 6.2 O.9, "frequency" is misspelt. > >Regards > >Andy > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of=20 >scott.probasco@nokia.com >Sent: 21 June 2012 17:57 >To: paws@ietf.org >Subject: Re: [paws] I-D Action: >draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt > >Hello All, > >This version 05 contains updates from the editors to address the=20 >comments posted to the reflector during 2nd WGLC. We hope this fulfills=20 >the work group's needs & desires, and look forward to continued progress i= n PAWS. > >Kind Regards, >Scott & Raj > > > >On 6/21/12 11:42 AM, "ext internet-drafts@ietf.org" > wrote: > >> >>A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> This draft is a work item of the Protocol to Access WS database=20 >>Working Group of the IETF. >> >> Title : Protocol to Access White Space database: PS, use >>cases and rqmts >> Author(s) : Scott Probasco >> Basavaraj Patil >> Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt >> Pages : 42 >> Date : 2012-06-21 >> >>Abstract: >> Portions of the radio spectrum that are assigned to a particular use >> but are unused or unoccupied at specific locations and times are >> defined as "white space". The concept of allowing additional >> transmissions (which may or may not be licensed) in white space is a >> technique to "unlock" existing spectrum for new use. An obvious >> requirement is that these additional transmissions do not interfere >> with the assigned use of the spectrum. One approach to using the >> white space spectrum at a given time and location is to verify with a >> database for available channels. >> >> This document describes a number of possible use cases of white space >> spectrum and technology as well as a set of requirements for the >> database query protocol. The concept of TV white spaces is described >> including the problems that need to be addressed to enable white >> space spectrum for additional uses without causing interference to >> currently assigned use. Use of white space is enabled by querying a >> database which stores information about the channel availability at >> any given location and time. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases >>- >>rqm >>ts >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts >>- >>05 >> >>A diff from previous version is available at: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecas >>e >>s-r >>qmts-05 >> >> >>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 > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Mon Jul 9 14:04:27 2012 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 7783911E81CA for ; Mon, 9 Jul 2012 14:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.263, 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 xsOR2rVVvJXl for ; Mon, 9 Jul 2012 14:04:27 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A044711E8171 for ; Mon, 9 Jul 2012 14:04:26 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q69L4nlR029763 for ; Tue, 10 Jul 2012 00:04:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 00:05:11 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Mon, 9 Jul 2012 23:04:48 +0200 From: To: Thread-Topic: draft document for Discovery Thread-Index: AQHNXhZ4yrw5iFI/q0OpvWK1evuW3A== Date: Mon, 9 Jul 2012 21:04:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [172.19.40.96] Content-Type: multipart/alternative; boundary="_000_CC20B1B3DB76scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2012 21:05:11.0871 (UTC) FILETIME=[877844F0:01CD5E16] X-Nokia-AV: Clean Subject: [paws] draft document for Discovery 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, 09 Jul 2012 21:04:27 -0000 --_000_CC20B1B3DB76scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj --_000_CC20B1B3DB76scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



--_000_CC20B1B3DB76scottprobasconokiacom_-- From brian.rosen@neustar.biz Mon Jul 9 14:27:12 2012 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 2D65D11E80E4 for ; Mon, 9 Jul 2012 14:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[AWL=1.576, 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 6evdzDNm2lZd for ; Mon, 9 Jul 2012 14:27:11 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E810B11E80E1 for ; Mon, 9 Jul 2012 14:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1341868995; x=1657218862; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=2waSGQFi9C01TbbQE65uVoZL+QbQqWyiF6/B2IHiibQ=; b=Rll5BRToWWpEb3/ySS/NWzQ3lFzjQ4evzu7JhMdWpTK5mrhWBZGaoBxfB/eCrA ejG/koIBbFNnzUlMuQRur07g== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.8568112; Mon, 09 Jul 2012 17:23:14 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 9 Jul 2012 17:27:31 -0400 From: "Rosen, Brian" To: "" Date: Mon, 9 Jul 2012 17:27:31 -0400 Thread-Topic: [paws] draft document for Discovery Thread-Index: Ac1eGaX7NK3EQlw9T/yKgRYdz8EjaQ== Message-ID: <3E5B9B7D-1A14-4AEC-A427-1D826D53E245@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: g6WKHqvmRtutqd52ufMCsw== Content-Type: multipart/alternative; boundary="_000_3E5B9B7D1A144AECA4271D826D53E245neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft document for Discovery 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, 09 Jul 2012 21:27:12 -0000 --_000_3E5B9B7D1A144AECA4271D826D53E245neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_3E5B9B7D1A144AECA4271D826D53E245neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This re-invents LoST witho= ut the extensive mechanisms for self organizing databases.
LoST has a q= uery that sends location in, with a Service URN (which for this use would b= e "I want a WSDB for this location" and you get back (a list of) URIs. &nbs= p;

That's what you propose, without the service UR= N because you want a special location based discovery mechanism just for WS= DBs.

What you don't deal with is how a WSDB DS fin= ds out about all other WSDB DSs.  That's the LoST "Forest Guide". &nbs= p;The FG works without a root, and allows cooperating LoST servers to  = ;refer queries to the right server.

It's not reall= y a great idea to bake a URI into a device.  Who knows what will happe= n over the life of a device?

The existing LoST dis= covery mechanism is built for widespread deployment in ISPs.   We may = need something that works well without that.  There aren't a lot of go= od mechanisms that really work well - you either have a root of some sort, = or, as you propose, a starting seed.  The root problem is who runs the= root, and the starting seed problem is the lifetime of the seed.  You= note that the seed gets nothing out of the exchange - it doesn't get to se= rve the query, it only gets to refer to someone who does.  
=
I actually think this is not an important problem to solve r= eally well.  The most common deployment model is going to be a tower a= nd clients.  The tower can be configured, and either the clients learn= from the tower, or the tower handles the database query itself.  Clie= nt discovery in that case could be the LoST discovery mechanism.
=
We have to handle the self organizing case (say a MANET) whe= re one or more devices have some other path to the Internet to get to the W= SDB.  They will need real discovery and may not have a cooperating ISP= .  While I really don't like configuration, it may be the only viable = way to do it.

Brian

=
On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mai= lman/listinfo/paws

= --_000_3E5B9B7D1A144AECA4271D826D53E245neustarbiz_-- From Peter.McCann@huawei.com Tue Jul 10 07:32:39 2012 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 7156221F86EC for ; Tue, 10 Jul 2012 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMJQsv3G7XNg for ; Tue, 10 Jul 2012 07:32:39 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E893821F86DF for ; Tue, 10 Jul 2012 07:32:38 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX07956; Tue, 10 Jul 2012 10:33:06 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 07:30:50 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.138]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 07:30:53 -0700 From: Peter McCann To: "paws@ietf.org" Thread-Topic: New draft on a protocol framework for PAWS Thread-Index: Ac1eqJuh/2z7gPuJTGWGeHYaYAOYdg== Date: Tue, 10 Jul 2012 14:30:52 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E16784@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [paws] New draft on a protocol framework for PAWS X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:32:39 -0000 Hi, all, Yesterday we submitted a draft protocol framework for PAWS that defines an XML schema for messages and data elements between a master device and a database. You can find it here: http://tools.ietf.org/html/draft-wei-paws-framework-00 For now the draft is kind of hand-wavy about database discovery and the security model, especially the security model for validating slave devices. These issues probably need to be addressed in separate documents. -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 U= SA From scott.probasco@nokia.com Tue Jul 10 12:37:52 2012 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 869EF11E80D9 for ; Tue, 10 Jul 2012 12:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.211, 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 S0oD++4LTSJJ for ; Tue, 10 Jul 2012 12:37:51 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id E351D11E80A6 for ; Tue, 10 Jul 2012 12:37:50 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6AJcF9J001676 for ; Tue, 10 Jul 2012 22:38:15 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 22:38:39 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Tue, 10 Jul 2012 21:38:14 +0200 From: To: Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsam1igeb9LkGV+JKNCiTfyJcibuGAgAAGioA= Date: Tue, 10 Jul 2012 19:38:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.35.18] Content-Type: multipart/alternative; boundary="_000_CC21ED51DBD2scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2012 19:38:39.0514 (UTC) FILETIME=[9AFF37A0:01CD5ED3] X-Nokia-AV: Clean Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:37:52 -0000 --_000_CC21ED51DBD2scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC21ED51DBD2scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0706EA39080C8249ABB8C2A9709690C5@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get = back (a list of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works = without a root, and allows cooperating LoST servers to  refer queries = to the right server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

 --_000_CC21ED51DBD2scottprobasconokiacom_-- From brian.rosen@neustar.biz Tue Jul 10 12:49:45 2012 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 0BF7511E8158 for ; Tue, 10 Jul 2012 12:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.81 X-Spam-Level: X-Spam-Status: No, score=-5.81 tagged_above=-999 required=5 tests=[AWL=0.788, 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 DgymZIgiwokU for ; Tue, 10 Jul 2012 12:49:43 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7C511E812C for ; Tue, 10 Jul 2012 12:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1341950065; x=1657309342; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=nII6nVlTQVtdQZWPnNuLb+pCyzoslmne23HwsOAP1SE=; b=PBxMblh36ocKsRhs20onBTFCTohxHcoiQ8o5zfFoLoRCgQkR/9EKIcLE4kIpor jfqKAHI1CjNbZ0j3t8+sIITA== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.11766104; Tue, 10 Jul 2012 15:54:24 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 10 Jul 2012 15:50:09 -0400 From: "Rosen, Brian" To: " " Date: Tue, 10 Jul 2012 15:50:08 -0400 Thread-Topic: [paws] draft document for Discovery Thread-Index: Ac1e1TW37WwpvnJ5QdKVtxUTXAu4Qg== Message-ID: <1605A384-C2C4-4B3D-B862-4BC0CE3185DF@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: eI1eA0GSOjxJDae0YP00PA== Content-Type: multipart/alternative; boundary="_000_1605A384C2C44B3DB8624BC0CE3185DFneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:49:45 -0000 --_000_1605A384C2C44B3DB8624BC0CE3185DFneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1605A384C2C44B3DB8624BC0CE3185DFneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
When I do the discove= ry, I don't know which country I am in.  I can't know enough to query = the right DS unless we put country boundary polygons in the device.

Of course, I forgot to add to this that if there is the U= .S. model of competing DBs, then the whole discovery mechanism falls apart,= and you need configuration, because if the device knows who its business r= elationship is with, it can know the URI.

Brian



Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get back (a li= st of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works without a = root, and allows cooperating LoST servers to  refer queries to the rig= ht server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian


Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mai= lman/listinfo/paws

= --_000_1605A384C2C44B3DB8624BC0CE3185DFneustarbiz_-- From scott.probasco@nokia.com Tue Jul 10 12:57:25 2012 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 45C6511E80FB for ; Tue, 10 Jul 2012 12:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.175, 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 u7CxRn6pLJ21 for ; Tue, 10 Jul 2012 12:57:23 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8D511E80D9 for ; Tue, 10 Jul 2012 12:57:23 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6AJvon2022844 for ; Tue, 10 Jul 2012 22:57:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 22:58:13 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Tue, 10 Jul 2012 21:57:48 +0200 From: To: Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsam1igeb9LkGV+JKNCiTfyJcibuGAgAAGioCAAFdFAP//rjeA Date: Tue, 10 Jul 2012 19:57:47 +0000 Message-ID: In-Reply-To: <1605A384-C2C4-4B3D-B862-4BC0CE3185DF@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.35.18] Content-Type: multipart/alternative; boundary="_000_CC21F201DBE8scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2012 19:58:13.0931 (UTC) FILETIME=[570107B0:01CD5ED6] X-Nokia-AV: Clean Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:57:25 -0000 --_000_CC21F201DBE8scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, The intention is that each DS has global scope. The WSD does not have to kn= ow what country it is in. In the US the I don't believe the discovery model falls apart. Discovery wi= ll return all suitable WSDB addresses allowing the WSD to make its own sele= ction. Also I don't know why a WSD would be restricted to a business relati= onship with a single WSDB. One small example, perhaps my device has relatio= nship with two different WSDB, each DB provides a different 'additional ser= vice' which might be the ultimate deciding factor why my WSD selects one WS= DB over the other (at a given location, time, or user-selected service requ= est). But in in case discovery would work the same. Kind Regards, Scott From: "ext Rosen, Brian" > Date: Tue, 10 Jul 2012 15:50:08 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC21F201DBE8scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8CD298D37AFDA84B91B4A065990603F9@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi Brian,

The intention is that each DS has global scope. The WSD does not have = to know what country it is in. 

In the US the I don't believe the discovery model falls apart. Discove= ry will return all suitable WSDB addresses allowing the WSD to make its own= selection. Also I don't know why a WSD would be restricted to a business r= elationship with a single WSDB. One small example, perhaps my device has relationship with two different W= SDB, each DB provides a different 'additional service' which might be the u= ltimate deciding factor why my WSD selects one WSDB over the other (at a gi= ven location, time, or user-selected service request). But in in case discovery would work the same.

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Tue, 10 Jul 2012 15:50:08 -04= 00
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

When I do the discovery, I don't know which country I am in.  I c= an't know enough to query the right DS unless we put country boundary polyg= ons in the device.

Of course, I forgot to add to this that if there is the U.S. model of = competing DBs, then the whole discovery mechanism falls apart, and you need= configuration, because if the device knows who its business relationship i= s with, it can know the URI.

Brian


On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get = back (a list of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works = without a root, and allows cooperating LoST servers to  refer queries = to the right server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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

 --_000_CC21F201DBE8scottprobasconokiacom_-- From Basavaraj.Patil@nokia.com Tue Jul 10 13:00:34 2012 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 54DFE21F869E for ; Tue, 10 Jul 2012 13:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, 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 dnnT-66V9FTL for ; Tue, 10 Jul 2012 13:00:33 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D942521F869C for ; Tue, 10 Jul 2012 13:00:32 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6AK0vCu011732; Tue, 10 Jul 2012 23:00:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 23:01:21 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.156]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Tue, 10 Jul 2012 22:00:47 +0200 From: To: , Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhZ4yrw5iFI/q0OpvWK1evuW3JchVZeAgAFtOwCAAAaQgIAAA1QA//+vq4A= Date: Tue, 10 Jul 2012 20:00:46 +0000 Message-ID: In-Reply-To: <1605A384-C2C4-4B3D-B862-4BC0CE3185DF@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.77] Content-Type: multipart/alternative; boundary="_000_CC21F32D20EC1basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2012 20:01:21.0982 (UTC) FILETIME=[C71755E0:01CD5ED6] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:00:34 -0000 --_000_CC21F32D20EC1basavarajpatilnokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline: From: "", "Brian.Rosen@neustar.biz" > Date: Tuesday, July 10, 2012 2:50 PM To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Raj> The WSD could send information (such as GPS co-ordinates, MCC+MNC, SSI= D etc.) to the discovery server which can be used to determine the country = that it is in. The DS itself is not country specific. It uses the informati= on sent by the device to determine which country the device is located in a= nd respond with the address(es) of the WSDBs therein. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is= with, it can know the URI. Raj> In such a case it is configured in the device. The device could still = query the DS and get a list of competing databases and then some policy on = the device will enable it to choose a preferred DB. -Raj Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC21F32D20EC1basavarajpatilnokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <060F50E43A00E2468D629994DD9D633E@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Inline: 

From: "<ext Rosen>"= , "Brian.Rosen@neustar.biz<= /a>" <Brian.Rosen@neusta= r.biz>
Date: Tuesday, July 10, 2012 2:50 P= M
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

When I do the discovery, I don't know which country I am in.  I c= an't know enough to query the right DS unless we put country boundary polyg= ons in the device.

Raj> The WSD could send information (such as GPS co-ordinates, MCC&= #43;MNC, SSID etc.) to the discovery server which can be used to determine = the country that it is in. The DS itself is not country specific. It uses t= he information sent by the device to determine which country the device is located in and respond with the address(es) of= the WSDBs therein.

Of course, I forgot to add to this that if there is the U.S. model of = competing DBs, then the whole discovery mechanism falls apart, and you need=  
configuration, because if the device knows who its business relationsh= ip is with, it can know the URI.

Raj> In such a case it is configured in the device. The device coul= d still query the DS and get a list of competing databases and then some po= licy on the device will enable it to choose a preferred DB.

-Raj


Brian


On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get = back (a list of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works = without a root, and allows cooperating LoST servers to  refer queries = to the right server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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

 --_000_CC21F32D20EC1basavarajpatilnokiacom_-- From brian.rosen@neustar.biz Tue Jul 10 13:12:00 2012 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 0015211E80BB for ; Tue, 10 Jul 2012 13:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.496 X-Spam-Level: X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OazlZwOxT7T5 for ; Tue, 10 Jul 2012 13:11:57 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0D621F86C6 for ; Tue, 10 Jul 2012 13:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1341951260; x=1657300224; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=Hw4BNzAdJKmSNHMRY28HgnBmUcWb98tNWexONsp8+nU=; b=QRGG/YcTniu7sU4+V3Rh0kROGYPKYFq6DeO1Lhp+ff8WE/iGVhl0vd6uhi8+oI GQaTXsO7qHpYZ4Z3WIZTjiVg== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.11337406; Tue, 10 Jul 2012 16:14:19 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 10 Jul 2012 16:12:20 -0400 From: "Rosen, Brian" Date: Tue, 10 Jul 2012 16:12:19 -0400 Thread-Topic: [paws] draft document for Discovery Thread-Index: Ac1e2E9Lsb/ZNOkTQT6BNcQMkwdmag== Message-ID: <09531A19-075F-437E-A6B0-89F2A6745267@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Af5MB+ExIa0rgbAhbt3tMQ== Content-Type: multipart/alternative; boundary="_000_09531A19075F437EA6B089F2A6745267neustarbiz_" MIME-Version: 1.0 To: "" Cc: "paws@ietf.org" Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:12:01 -0000 --_000_09531A19075F437EA6B089F2A6745267neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott said in his email that DS was per country: If vendor X intends their WSD to operate in Country Y, then WSDB DS used b= y vendor X must include appropriate Country Y mapping information (location= to WSDB or WSDB listing server) in their WSDB DS. If every DS will, for free, refer to the right DS for every other country, = great. Otherwise, we have a problem. Forest Guides in LoST work kind of= like this. If you find any LoST server, the FGs can refer a query to the = right LoST server based on location. If you configure a policy in a device, you can configure a URI. There is n= o need for discovery mechanisms in such cases. Discovery mechanisms genera= lly work without configuration, and they (should) work everywhere. I'm not opposed to a discovery mechanism. I do rather like the LoST mechan= ism, because it is documented, it works, and it solves this set of problems= , provided the servers do in fact allow you to refer to other servers for f= ree. Configuration and LoST works. Why invent something else? If you want to build in some default LoST server URI into the device, as lo= ng as that server is willing to refer the query to the right LoST server fo= r ever, for free, that works. Brian On Jul 10, 2012, at 4:00 PM, > wrote: Inline: From: "", "Brian.Rosen@neustar.biz" > Date: Tuesday, July 10, 2012 2:50 PM To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Raj> The WSD could send information (such as GPS co-ordinates, MCC+MNC, SSI= D etc.) to the discovery server which can be used to determine the country = that it is in. The DS itself is not country specific. It uses the informati= on sent by the device to determine which country the device is located in a= nd respond with the address(es) of the WSDBs therein. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is= with, it can know the URI. Raj> In such a case it is configured in the device. The device could still = query the DS and get a list of competing databases and then some policy on = the device will enable it to choose a preferred DB. -Raj Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_09531A19075F437EA6B089F2A6745267neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott said in his email th= at DS was per country:
 If vendor = X intends their WSD to operate in Country Y, then WSDB DS used by vendor X = must include appropriate Country Y mapping information (location to WSDB or= WSDB listing server) in their WSDB DS.

If every DS will, for free, refer to the right DS for every other = country, great.  Otherwise, we have a problem.    Forest Gui= des in LoST work kind of like this.  If you find any LoST server, the = FGs can refer a query to the right LoST server based on location.

If you configure a policy in a device, you can configure a = URI.  There is no need for discovery mechanisms in such cases.  D= iscovery mechanisms generally work without configuration, and they (should)= work everywhere.

I'm not opposed to a discovery m= echanism.  I do rather like the LoST mechanism, because it is document= ed, it works, and it solves this set of problems, provided the servers do i= n fact allow you to refer to other servers for free.

Configuration and LoST works.  Why invent something else?

If you want to build in some default LoST server URI into t= he device, as long as that server is willing to refer the query to the righ= t LoST server for ever, for free, that works.

Bria= n



On Jul 10, 2012, at= 4:00 PM, <Basavaraj.Patil@= nokia.com> wrote:

Inline: 


When I do the discovery, I don't know which country I am in.  I c= an't know enough to query the right DS unless we put country boundary polyg= ons in the device.

Raj> The WSD could send information (such as GPS co-ordinates, MCC+= MNC, SSID etc.) to the discovery server which can be used to determine the = country that it is in. The DS itself is not country specific. It uses the i= nformation sent by the device to determine which country the device is located in and respond with the address(es) of= the WSDBs therein.

Of course, I forgot to add to this that if there is the U.S. model of = competing DBs, then the whole discovery mechanism falls apart, and you need=  
configuration, because if the device knows who its business relationsh= ip is with, it can know the URI.

Raj> In such a case it is configured in the device. The device coul= d still query the DS and get a list of competing databases and then some po= licy on the device will enable it to choose a preferred DB.

-Raj


Brian



Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get back (a li= st of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works without a = root, and allows cooperating LoST servers to  refer queries to the rig= ht server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian


Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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


= --_000_09531A19075F437EA6B089F2A6745267neustarbiz_-- From scott.probasco@nokia.com Tue Jul 10 13:46:03 2012 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 9888611E80D0 for ; Tue, 10 Jul 2012 13:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6rAUMA0Aib6 for ; Tue, 10 Jul 2012 13:46:02 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C269621F8606 for ; Tue, 10 Jul 2012 13:46:01 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6AKkJnW016892 for ; Tue, 10 Jul 2012 23:46:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 23:46:48 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Tue, 10 Jul 2012 22:46:23 +0200 From: To: Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsam1igeb9LkGV+JKNCiTfyJcibuGAgAAGioCAAFdFAIAAAvgAgAADOoD//7WiAA== Date: Tue, 10 Jul 2012 20:46:22 +0000 Message-ID: In-Reply-To: <09531A19-075F-437E-A6B0-89F2A6745267@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.35.18] Content-Type: multipart/alternative; boundary="_000_CC21F79ADBFAscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2012 20:46:48.0827 (UTC) FILETIME=[206ADCB0:01CD5EDD] X-Nokia-AV: Clean Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:46:03 -0000 --_000_CC21F79ADBFAscottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Tue, 10 Jul 2012 16:12:19 -0400 To: Raj Patil > Cc: Scott Probasco >, "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery Scott said in his email that DS was per country: If vendor X intends their WSD to operate in Country Y, then WSDB DS used b= y vendor X must include appropriate Country Y mapping information (location= to WSDB or WSDB listing server) in their WSDB DS. MSP->This was not meant to imply that there is a WSDB DS for each country. = There is a global DS URI that the device is configured with. The DS is awar= e of all the databases offering service in various regulatory domains. The = DS responds with the list of databases to the device based on its current l= ocation. If every DS will, for free, refer to the right DS for every other country, = great. Otherwise, we have a problem. Forest Guides in LoST work kind of= like this. If you find any LoST server, the FGs can refer a query to the = right LoST server based on location. If you configure a policy in a device, you can configure a URI. There is n= o need for discovery mechanisms in such cases. Discovery mechanisms genera= lly work without configuration, and they (should) work everywhere. MSP->IMHO the process should work the same, at every power up. A WSD which = never 'roams' will experience the simple or trivial case (e.g. in the US al= ways receive the addresses of the same WSDBs, and likely pick the same addr= ess for service every time). But when the device powers up in a roaming sta= te, then the situation becomes more interesting. I'm not opposed to a discovery mechanism. I do rather like the LoST mechan= ism, because it is documented, it works, and it solves this set of problems= , provided the servers do in fact allow you to refer to other servers for f= ree. Configuration and LoST works. Why invent something else? MSP->Simplicity? It is not obvious for me how a white space business model = will support the Authoritative Mapping Server, Forest Guide & Resolver enti= ties in RFC5582. If you want to build in some default LoST server URI into the device, as lo= ng as that server is willing to refer the query to the right LoST server fo= r ever, for free, that works. Brian On Jul 10, 2012, at 4:00 PM, > wrote: Inline: From: "", "Brian.Rosen@neustar.biz" > Date: Tuesday, July 10, 2012 2:50 PM To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Raj> The WSD could send information (such as GPS co-ordinates, MCC+MNC, SSI= D etc.) to the discovery server which can be used to determine the country = that it is in. The DS itself is not country specific. It uses the informati= on sent by the device to determine which country the device is located in a= nd respond with the address(es) of the WSDBs therein. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is= with, it can know the URI. Raj> In such a case it is configured in the device. The device could still = query the DS and get a list of competing databases and then some policy on = the device will enable it to choose a preferred DB. -Raj Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC21F79ADBFAscottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <53C2DF07961F714DBAD1C507C3D2FC99@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Tue, 10 Jul 2012 16:12:19 -04= 00
To: Raj Patil <Basavaraj.Patil@nokia.com>
Cc: Scott Probasco <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document = for Discovery

Scott said in his email that DS was per country:
 If vendor X intends their WSD to operate in Country Y, then WSDB= DS used by vendor X must include appropriate Country Y mapping information= (location to WSDB or WSDB listing server) in their WSDB DS.
MSP->This was not meant to imply that there is a WSDB DS for each c= ountry. There is a global DS URI that the device is configured with. The DS= is aware of all the databases offering service in various regulatory domai= ns. The DS responds with the list of databases to the device based on its current location.

If every DS will, for free, refer to the right DS for every other coun= try, great.  Otherwise, we have a problem.    Forest Guides = in LoST work kind of like this.  If you find any LoST server, the FGs = can refer a query to the right LoST server based on location.

If you configure a policy in a device, you can configure a URI.  = There is no need for discovery mechanisms in such cases.  Discovery me= chanisms generally work without configuration, and they (should) work every= where.
MSP->IMHO the process should work the same, at every power up. A WS= D which never 'roams' will experience the simple or trivial case (e.g. in t= he US always receive the addresses of the same WSDBs, and likely pick the s= ame address for service every time). But when the device powers up in a roaming state, then the situation becom= es more interesting.

I'm not opposed to a discovery mechanism.  I do rather like the L= oST mechanism, because it is documented, it works, and it solves this set o= f problems, provided the servers do in fact allow you to refer to other ser= vers for free.

Configuration and LoST works.  Why invent something else?
MSP->Simplicity? It is not obvious for me how a white space busines= s model will support the Authoritative Mapping Server, Forest Guide & R= esolver entities in RFC5582.

If you want to build in some default LoST server URI into the device, = as long as that server is willing to refer the query to the right LoST serv= er for ever, for free, that works.

Brian



On Jul 10, 2012, at 4:00 PM, <Basavaraj.Patil@nokia.com> wrote:

Inline: 

From: "<ext Rosen>"= , "Brian.Rosen@neustar.biz<= /a>" <Brian.Rosen@neusta= r.biz>
Date: Tuesday, July 10, 2012 2:50 P= M
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

When I do the discovery, I don't know which country I am in.  I c= an't know enough to query the right DS unless we put country boundary polyg= ons in the device.

Raj> The WSD could send information (such as GPS co-ordinates, MCC&= #43;MNC, SSID etc.) to the discovery server which can be used to determine = the country that it is in. The DS itself is not country specific. It uses t= he information sent by the device to determine which country the device is located in and respond with the address(es) of= the WSDBs therein.

Of course, I forgot to add to this that if there is the U.S. model of = competing DBs, then the whole discovery mechanism falls apart, and you need=  
configuration, because if the device knows who its business relationsh= ip is with, it can know the URI.

Raj> In such a case it is configured in the device. The device coul= d still query the DS and get a list of competing databases and then some po= licy on the device will enable it to choose a preferred DB.

-Raj


Brian


On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get = back (a list of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works = without a root, and allows cooperating LoST servers to  refer queries = to the right server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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


 --_000_CC21F79ADBFAscottprobasconokiacom_-- From brian.rosen@neustar.biz Tue Jul 10 14:02:25 2012 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 594FF21F85E0 for ; Tue, 10 Jul 2012 14:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3KXrxMsoCKH for ; Tue, 10 Jul 2012 14:02:21 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id C22CC21F85DB for ; Tue, 10 Jul 2012 14:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1341953900; x=1657303661; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=aSJBDq6oZZQC/YIH3/Iovxry5ZfvzsphGppNKqFtRzU=; b=Eg28FQ1KZQ7oiG55xvl0/fGn4h3vjIeNab9OGqDLB8KjXHpu7cwv+JHzQ33Dxq bGZWRADfyj4AxbGI/Etyu1KA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.8608987; Tue, 10 Jul 2012 16:58:19 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 10 Jul 2012 17:02:36 -0400 From: "Rosen, Brian" To: "" Date: Tue, 10 Jul 2012 17:02:34 -0400 Thread-Topic: [paws] draft document for Discovery Thread-Index: Ac1e31SpZiVBHT0hSH+yRSHjgKiD6w== Message-ID: <8754F7FB-AEF7-4F6C-B68C-B6EB0E076826@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: fpiHGpi1G6mYKToVBgzyfw== Content-Type: multipart/alternative; boundary="_000_8754F7FBAEF74F6CB68CB6EB0E076826neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:02:25 -0000 --_000_8754F7FBAEF74F6CB68CB6EB0E076826neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MSP->IMHO the process should work the same, at every power up. A WSD which = never 'roams' will experience the simple or trivial case (e.g. in the US al= ways receive the addresses of the same WSDBs, and likely pick the same addr= ess for service every time). But when the device powers up in a roaming sta= te, then the situation becomes more interesting. If you need to configure to have a policy that decides which of multiple co= mpeting databases you have a relationship with, configure the URI to the da= tabase. If your default database has roaming agreements, your configured database c= an refer you to the right one. If your device can roam, on its own, to places where there is only one data= base (for example, a government run or sponsored database), then we might w= ant a discovery mechanism, but I think LoST is it. MSP->Simplicity? It is not obvious for me how a white space business model = will support the Authoritative Mapping Server, Forest Guide & Resolver enti= ties in RFC5582. Authoritative Mapping server =3D Lost Server. Your DS. Forest Guide can be part of the LoST server - it's just an entity that exch= anges coverage information with other FGs to build a referral database. You can restrict access to the FG to only authorized LoST servers (DS in yo= ur terms). That means that if a DS doesn't know what the right DS is, it c= onsults the FG, which tells it. That makes the load on the FG very low. F= Gs have no root. It would be perfectly reasonable for a regulator to run a= n FG as long as only DSs in the country could access it. It would connect = to similar FGs elsewhere. It's also possible for anyone who wants to to run an FG with similar restri= ctions - only handling requests from DSs (LoST servers) it knows. It would be very easy for example, the U.S. WSDB Admins to agree on an FG m= odel that worked for the US and connected to other country's DSs. Brian If you want to build in some default LoST server URI into the device, as lo= ng as that server is willing to refer the query to the right LoST server fo= r ever, for free, that works. Brian On Jul 10, 2012, at 4:00 PM, > wrote: Inline: From: "", "Brian.Rosen@neustar.biz" > Date: Tuesday, July 10, 2012 2:50 PM To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Raj> The WSD could send information (such as GPS co-ordinates, MCC+MNC, SSI= D etc.) to the discovery server which can be used to determine the country = that it is in. The DS itself is not country specific. It uses the informati= on sent by the device to determine which country the device is located in a= nd respond with the address(es) of the WSDBs therein. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is= with, it can know the URI. Raj> In such a case it is configured in the device. The device could still = query the DS and get a list of competing databases and then some policy on = the device will enable it to choose a preferred DB. -Raj Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_8754F7FBAEF74F6CB68CB6EB0E076826neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
MSP->IMHO the process should work th= e same, at every power up. A WSD which never 'roams' will experience the si= mple or trivial case (e.g. in the US always receive the addresses of the sa= me WSDBs, and likely pick the same address for service every time). But when the device powers up in a roaming state, then the situation becom= es more interesting.
If you need to configure to ha= ve a policy that decides which of multiple competing databases you have a r= elationship with, configure the URI to the database.

If your default database has roaming agreements, your configured databas= e can refer you to the right one.

If your device c= an roam, on its own, to places where there is only one database (for exampl= e, a government run or sponsored database), then we might want a discovery = mechanism, but I think LoST is it.

=
MSP->Simplicity? It is not obvious for me= how a white space business model will support the Authoritative Mapping Se= rver, Forest Guide & Resolver entities in RFC5582.
Authoritative Mapping server =3D Lost Server.  Your DS.
= Forest Guide can be part of the LoST server - it's just an entity that exch= anges coverage information with other FGs to build a referral database.

You can restrict access to the FG to only authorized = LoST servers (DS in your terms).  That means that if a DS doesn't know= what the right DS is, it consults the FG, which tells it.  That makes= the load on the FG very low.  FGs have no root.  It would be per= fectly reasonable for a regulator to run an FG as long as only DSs in the c= ountry could access it.  It would connect to similar FGs elsewhere.

It's also possible for anyone who wants to to run an= FG with similar restrictions - only handling requests from DSs (LoST serve= rs) it knows.

It would be very easy for example, t= he U.S. WSDB Admins to agree on an FG model that worked for the US and conn= ected to other country's DSs.

Brian

If you want to build in some default LoST server URI into the device, = as long as that server is willing to refer the query to the right LoST serv= er for ever, for free, that works.

Brian



On Jul 10, 2012, at 4:00 PM, <Basavaraj.Patil@nokia.com> wrote:

Inline: 


When I do the discovery, I don't know which country I am in.  I c= an't know enough to query the right DS unless we put country boundary polyg= ons in the device.

Raj> The WSD could send information (such as GPS co-ordinates, MCC+= MNC, SSID etc.) to the discovery server which can be used to determine the = country that it is in. The DS itself is not country specific. It uses the i= nformation sent by the device to determine which country the device is located in and respond with the address(es) of= the WSDBs therein.

Of course, I forgot to add to this that if there is the U.S. model of = competing DBs, then the whole discovery mechanism falls apart, and you need=  
configuration, because if the device knows who its business relationsh= ip is with, it can know the URI.

Raj> In such a case it is configured in the device. The device coul= d still query the DS and get a list of competing databases and then some po= licy on the device will enable it to choose a preferred DB.

-Raj


Brian



Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get back (a li= st of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works without a = root, and allows cooperating LoST servers to  refer queries to the rig= ht server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian


Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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

= --_000_8754F7FBAEF74F6CB68CB6EB0E076826neustarbiz_-- From peter@spectrumbridge.com Tue Jul 10 14:06:00 2012 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 D329911E80CB for ; Tue, 10 Jul 2012 14:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op4Jsu-6yur0 for ; Tue, 10 Jul 2012 14:05:59 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE2511E80C4 for ; Tue, 10 Jul 2012 14:05:59 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 10 Jul 2012 17:06:26 -0400 From: Peter Stanforth To: "Rosen, Brian" Date: Tue, 10 Jul 2012 17:09:37 -0400 Thread-Topic: [paws] draft document for Discovery Thread-Index: Ac1e394Z7INZYsfcTDelHldVJC7D5Q== Message-ID: <7E7636AD-90AA-485E-A826-155052EE4A91@spectrumbridge.com> References: <1605A384-C2C4-4B3D-B862-4BC0CE3185DF@neustar.biz> In-Reply-To: <1605A384-C2C4-4B3D-B862-4BC0CE3185DF@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7E7636AD90AA485EA826155052EE4A91spectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:06:01 -0000 --_000_7E7636AD90AA485EA826155052EE4A91spectrumbridgecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 b24gdGhpcyB0b3BpYyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFwcHJvYWNoIHdvdWxkIGJlIGZv ciB0aGUgZGV2aWNlIHRvIGNhbGwgaG9tZSwgdG8gdGhlIG1hbnVmYWN0dXJlciwgd2l0aCB0aGUg YWJpbGl0eSBmb3IgdGhlIG1hbnVmYWN0dXJlciB0byBwb2ludCBpdCB0byB0aGUgYXBwcm9wcmlh dGUgREIgZm9yIHRoYXQgbG9jYXRpb24uIFRoaXMgd29ya3Mgd2VsbCwgYW5kIHNpbXBseSBpZiB3 ZSBhc3N1bWUgdGhlIGRldmljZSBoYXMgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBEQi4gSWYg aXQgaXMgYSB1c2VyIChTYXkgbmV0d29yayBvcGVyYXRvcikgdGhlbiBJIHdvdWxkIGV4cGVjdCB0 aGVtIHRvIGNvbmZpZ3VyZSB0aGVpciBkZXZpY2VzIHRvIGdvIHdoZXJlIHRoZXkgZGVzaXJlIHRo ZW0gdG8gZ28uDQoNCk9uIEp1bCAxMCwgMjAxMiwgYXQgMzo1MCBQTSwgIlJvc2VuLCBCcmlhbiIg PEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4+ IHdyb3RlOg0KDQpXaGVuIEkgZG8gdGhlIGRpc2NvdmVyeSwgSSBkb24ndCBrbm93IHdoaWNoIGNv dW50cnkgSSBhbSBpbi4gIEkgY2FuJ3Qga25vdyBlbm91Z2ggdG8gcXVlcnkgdGhlIHJpZ2h0IERT IHVubGVzcyB3ZSBwdXQgY291bnRyeSBib3VuZGFyeSBwb2x5Z29ucyBpbiB0aGUgZGV2aWNlLg0K DQpPZiBjb3Vyc2UsIEkgZm9yZ290IHRvIGFkZCB0byB0aGlzIHRoYXQgaWYgdGhlcmUgaXMgdGhl IFUuUy4gbW9kZWwgb2YgY29tcGV0aW5nIERCcywgdGhlbiB0aGUgd2hvbGUgZGlzY292ZXJ5IG1l Y2hhbmlzbSBmYWxscyBhcGFydCwgYW5kIHlvdSBuZWVkIGNvbmZpZ3VyYXRpb24sIGJlY2F1c2Ug aWYgdGhlIGRldmljZSBrbm93cyB3aG8gaXRzIGJ1c2luZXNzIHJlbGF0aW9uc2hpcCBpcyB3aXRo LCBpdCBjYW4ga25vdyB0aGUgVVJJLg0KDQpCcmlhbg0KDQoNCk9uIEp1bCAxMCwgMjAxMiwgYXQg MzozOCBQTSwgPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbTxtYWlsdG86c2NvdHQucHJvYmFzY29A bm9raWEuY29tPj4gPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbTxtYWlsdG86c2NvdHQucHJvYmFz Y29Abm9raWEuY29tPj4gd3JvdGU6DQoNCkhpIEJyaWFuLA0KDQpDb21tZW50cyBiZWxvdzogTVNQ LT4NCg0KS2luZCBSZWdhcmRzLA0KU2NvdHQNCg0KRnJvbTogImV4dCBSb3NlbiwgQnJpYW4iIDxC cmlhbi5Sb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+Pg0K RGF0ZTogTW9uLCA5IEp1bCAyMDEyIDE3OjI3OjMxIC0wNDAwDQpUbzogU2NvdHQgUHJvYmFzY28g PHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbTxtYWlsdG86c2NvdHQucHJvYmFzY29Abm9raWEuY29t Pj4NCkNjOiAicGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4iIDxwYXdzQGlldGYu b3JnPG1haWx0bzpwYXdzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcGF3c10gZHJhZnQgZG9j dW1lbnQgZm9yIERpc2NvdmVyeQ0KDQpUaGlzIHJlLWludmVudHMgTG9TVCB3aXRob3V0IHRoZSBl eHRlbnNpdmUgbWVjaGFuaXNtcyBmb3Igc2VsZiBvcmdhbml6aW5nIGRhdGFiYXNlcy4NCkxvU1Qg aGFzIGEgcXVlcnkgdGhhdCBzZW5kcyBsb2NhdGlvbiBpbiwgd2l0aCBhIFNlcnZpY2UgVVJOICh3 aGljaCBmb3IgdGhpcyB1c2Ugd291bGQgYmUgIkkgd2FudCBhIFdTREIgZm9yIHRoaXMgbG9jYXRp b24iIGFuZCB5b3UgZ2V0IGJhY2sgKGEgbGlzdCBvZikgVVJJcy4NCg0KVGhhdCdzIHdoYXQgeW91 IHByb3Bvc2UsIHdpdGhvdXQgdGhlIHNlcnZpY2UgVVJOIGJlY2F1c2UgeW91IHdhbnQgYSBzcGVj aWFsIGxvY2F0aW9uIGJhc2VkIGRpc2NvdmVyeSBtZWNoYW5pc20ganVzdCBmb3IgV1NEQnMuDQoN CldoYXQgeW91IGRvbid0IGRlYWwgd2l0aCBpcyBob3cgYSBXU0RCIERTIGZpbmRzIG91dCBhYm91 dCBhbGwgb3RoZXIgV1NEQiBEU3MuICBUaGF0J3MgdGhlIExvU1QgIkZvcmVzdCBHdWlkZSIuICBU aGUgRkcgd29ya3Mgd2l0aG91dCBhIHJvb3QsIGFuZCBhbGxvd3MgY29vcGVyYXRpbmcgTG9TVCBz ZXJ2ZXJzIHRvICByZWZlciBxdWVyaWVzIHRvIHRoZSByaWdodCBzZXJ2ZXIuDQpNU1AtPklmIGVh Y2ggV1NEIHZlbmRvciBhcnJhbmdlcyBhIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IHdpdGggYSBX U0RCIERTIChvciBwcm92aWRlcyB0aGVpciBvd24gV1NEQiBEUykgdGhlbiBpdCBpcyBub3Qgb2J2 aW91cyB0byBtZSB3aHkgYSBXU0RCIERTIHdvdWxkIG5lZWQgdG8gZmluZCBvdXQgYWJvdXQgb3Ro ZXIgV1NEQiBEU3MuIEVhY2ggV1NEQiBEUyBpcyBpbmRlcGVuZGVudC4gSWYgdmVuZG9yIFggaW50 ZW5kcyB0aGVpciBXU0QgdG8gb3BlcmF0ZSBpbiBDb3VudHJ5IFksIHRoZW4gV1NEQiBEUyB1c2Vk IGJ5IHZlbmRvciBYIG11c3QgaW5jbHVkZSBhcHByb3ByaWF0ZSBDb3VudHJ5IFkgbWFwcGluZyBp bmZvcm1hdGlvbiAobG9jYXRpb24gdG8gV1NEQiBvciBXU0RCIGxpc3Rpbmcgc2VydmVyKSBpbiB0 aGVpciBXU0RCIERTLg0KDQpJdCdzIG5vdCByZWFsbHkgYSBncmVhdCBpZGVhIHRvIGJha2UgYSBV UkkgaW50byBhIGRldmljZS4gIFdobyBrbm93cyB3aGF0IHdpbGwgaGFwcGVuIG92ZXIgdGhlIGxp ZmUgb2YgYSBkZXZpY2U/DQpNU1AtPkluY2x1ZGluZyBhbiBhZGRyZXNzIGluIHRoZSBkZXZpY2Ug ZG9lcyBub3QgaW1wbHkgdGhhdCB0aGUgYWRkcmVzcyBjYW5ub3QgYmUgY2hhbmdlZCBpZiBuZWVk ZWQuIFNXIHVwZGF0ZXMsIGRldmljZSBtYW5hZ2VtZW50IG9yIHNpbWlsYXIgY2FuIGFsbG93IGZv ciBjaGFuZ2VzIGlmIG5lZWRlZC4gSSB0YWtlIHlvdXIgcG9pbnQsIHRoZXNlIGNoYW5nZXMgc2hv dWxkIGJlIGV4Y2VwdGlvbnMgcmF0aGVyIHRoYW4gcmVndWxhciBldmVudHMuDQoNClRoZSBleGlz dGluZyBMb1NUIGRpc2NvdmVyeSBtZWNoYW5pc20gaXMgYnVpbHQgZm9yIHdpZGVzcHJlYWQgZGVw bG95bWVudCBpbiBJU1BzLiAgIFdlIG1heSBuZWVkIHNvbWV0aGluZyB0aGF0IHdvcmtzIHdlbGwg d2l0aG91dCB0aGF0LiAgVGhlcmUgYXJlbid0IGEgbG90IG9mIGdvb2QgbWVjaGFuaXNtcyB0aGF0 IHJlYWxseSB3b3JrIHdlbGwgLSB5b3UgZWl0aGVyIGhhdmUgYSByb290IG9mIHNvbWUgc29ydCwg b3IsIGFzIHlvdSBwcm9wb3NlLCBhIHN0YXJ0aW5nIHNlZWQuICBUaGUgcm9vdCBwcm9ibGVtIGlz IHdobyBydW5zIHRoZSByb290LCBhbmQgdGhlIHN0YXJ0aW5nIHNlZWQgcHJvYmxlbSBpcyB0aGUg bGlmZXRpbWUgb2YgdGhlIHNlZWQuICBZb3Ugbm90ZSB0aGF0IHRoZSBzZWVkIGdldHMgbm90aGlu ZyBvdXQgb2YgdGhlIGV4Y2hhbmdlIC0gaXQgZG9lc24ndCBnZXQgdG8gc2VydmUgdGhlIHF1ZXJ5 LCBpdCBvbmx5IGdldHMgdG8gcmVmZXIgdG8gc29tZW9uZSB3aG8gZG9lcy4NCk1TUC0+SXQgaXMg bm90IGNsZWFyIHRvIG1lIHdoYXQgYnVzaW5lc3MgbW9kZWwgd291bGQgc3VwcG9ydCBhIHNvcGhp c3RpY2F0ZWQgaW5mcmFzdHJ1Y3R1cmUgYXMgZGVzY3JpYmVkIGluIHRoZSBMb1NUIEFyY2hpdGVj dHVyZSAmIEZyYW1ld29yayBSRkMgNTU4Mi4NCg0KSSBhY3R1YWxseSB0aGluayB0aGlzIGlzIG5v dCBhbiBpbXBvcnRhbnQgcHJvYmxlbSB0byBzb2x2ZSByZWFsbHkgd2VsbC4gIFRoZSBtb3N0IGNv bW1vbiBkZXBsb3ltZW50IG1vZGVsIGlzIGdvaW5nIHRvIGJlIGEgdG93ZXIgYW5kIGNsaWVudHMu ICBUaGUgdG93ZXIgY2FuIGJlIGNvbmZpZ3VyZWQsIGFuZCBlaXRoZXIgdGhlIGNsaWVudHMgbGVh cm4gZnJvbSB0aGUgdG93ZXIsIG9yIHRoZSB0b3dlciBoYW5kbGVzIHRoZSBkYXRhYmFzZSBxdWVy eSBpdHNlbGYuICBDbGllbnQgZGlzY292ZXJ5IGluIHRoYXQgY2FzZSBjb3VsZCBiZSB0aGUgTG9T VCBkaXNjb3ZlcnkgbWVjaGFuaXNtLg0KDQpXZSBoYXZlIHRvIGhhbmRsZSB0aGUgc2VsZiBvcmdh bml6aW5nIGNhc2UgKHNheSBhIE1BTkVUKSB3aGVyZSBvbmUgb3IgbW9yZSBkZXZpY2VzIGhhdmUg c29tZSBvdGhlciBwYXRoIHRvIHRoZSBJbnRlcm5ldCB0byBnZXQgdG8gdGhlIFdTREIuICBUaGV5 IHdpbGwgbmVlZCByZWFsIGRpc2NvdmVyeSBhbmQgbWF5IG5vdCBoYXZlIGEgY29vcGVyYXRpbmcg SVNQLiAgV2hpbGUgSSByZWFsbHkgZG9uJ3QgbGlrZSBjb25maWd1cmF0aW9uLCBpdCBtYXkgYmUg dGhlIG9ubHkgdmlhYmxlIHdheSB0byBkbyBpdC4NCk1TUC0+Q29uZmlndXJhdGlvbiBpcyBwcmFn bWF0aWMgYW5kIGNhbiBiZSBlYXNpbHkgZGVwbG95ZWQNCg0KQnJpYW4NCg0KT24gSnVsIDksIDIw MTIsIGF0IDU6MDQgUE0sIDxzY290dC5wcm9iYXNjb0Bub2tpYS5jb208bWFpbHRvOnNjb3R0LnBy b2Jhc2NvQG5va2lhLmNvbT4+IHdyb3RlOg0KDQpIZWxsbyBBbGwsDQoNClBsZWFzZSBmaW5kIGEg bGluayBiZWxvdyB0byBhIGRyYWZ0IHN1Ym1pc3Npb24gZm9yIHRoZSBEaXNjb3ZlcnkgcHJvY2Vz cyBhcyBkZXNjcmliZWQgaW4gdGhlIFVzZSBDYXNlcyAmIFJlcXVpcmVtZW50cyBkb2N1bWVudC4g V2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIHJldmlldyBhbmQgY29tbWVudHMgYXMgd2Vs bCBhcyBkaXNjdXNzaW9uIGF0IElFVEYjODQuDQoNCkFic3RyYWN0Og0KICAgQSB3aGl0ZSBzcGFj ZSBtYXN0ZXIgZGV2aWNlIG5lZWRzIHRvIHF1ZXJ5IGEgd2hpdGUgc3BhY2UgZGF0YWJhc2UgYW5k DQogICBvYnRhaW4gaW5mb3JtYXRpb24gYWJvdXQgYXZhaWxhYmxlIHNwZWN0cnVtL2NoYW5uZWxz IHByaW9yIHRvDQogICBvcGVyYXRpb24uICBXaGl0ZSBzcGFjZSBkYXRhYmFzZXMgd2hpY2ggY29u dGFpbiBpbmZvcm1hdGlvbiBhYm91dA0KICAgYXZhaWxhYmxlIHNwZWN0cnVtL2NoYW5uZWxzIGFy ZSBhc3NvY2lhdGVkIHdpdGggYSByZWd1bGF0b3J5IGRvbWFpbi4NCiAgIEEgd2hpdGUgc3BhY2Ug bWFzdGVyIGRldmljZSBuZWVkcyB0byBkaXNjb3ZlciB0aGUgcmVsZXZhbnQgd2hpdGUNCiAgIHNw YWNlIGRhdGFiYXNlKHMpIGdpdmVuIGl0cyBjdXJyZW50IGxvY2F0aW9uIGFuZCBpbiB3aGljaCBy ZWd1bGF0b3J5DQogICBkb21haW4gdGhhdCBpdCBpcyBvcGVyYXRpbmcuICBUaGUgd2hpdGUgc3Bh Y2UgZGF0YWJhc2UgZGlzY292ZXJ5IGlzDQogICB0aGUgcHJlbGltaW5hcnkgc3RlcCB0aGF0IGEg d2hpdGUgc3BhY2UgbWFzdGVyIGRldmljZSBoYXMgdG8gcGVyZm9ybS4NCg0KDQpVUkw6ICAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXByb2Jhc2Nv LXBhd3MtZGlzY292ZXJ5LTAwLnR4dA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1wcm9iYXNjby1wYXdzLWRpc2NvdmVyeS0wMA0KDQpLaW5kIFJlZ2Fy ZHMsDQpTY290dCAmIFJhag0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpw YXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwYXdz IG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NA aWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MNCg== --_000_7E7636AD90AA485EA826155052EE4A91spectrumbridgecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+b24gdGhpcyB0 b3BpYyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFwcHJvYWNoIHdvdWxkIGJlIGZvciB0aGUgZGV2 aWNlIHRvIGNhbGwgaG9tZSwgdG8gdGhlIG1hbnVmYWN0dXJlciwgd2l0aCB0aGUgYWJpbGl0eSBm b3IgdGhlIG1hbnVmYWN0dXJlciB0byBwb2ludCBpdCB0byB0aGUgYXBwcm9wcmlhdGUgREIgZm9y IHRoYXQgbG9jYXRpb24uIFRoaXMgd29ya3Mgd2VsbCwgYW5kIHNpbXBseSBpZiB3ZSBhc3N1bWUg dGhlIGRldmljZSBoYXMgdGhlIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBEQi4gSWYgaXQgaXMgYSB1 c2VyIChTYXkgbmV0d29yayBvcGVyYXRvcikgdGhlbiBJIHdvdWxkIGV4cGVjdCB0aGVtIHRvIGNv bmZpZ3VyZSB0aGVpciBkZXZpY2VzIHRvIGdvIHdoZXJlIHRoZXkgZGVzaXJlIHRoZW0gdG8gZ28u ICZuYnNwOzxicj48YnI+T24gSnVsIDEwLCAyMDEyLCBhdCAzOjUwIFBNLCAiUm9zZW4sIEJyaWFu IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5Ccmlhbi5Sb3Nl bkBuZXVzdGFyLmJpejwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGRpdj48L2Rpdj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxkaXY+V2hlbiBJIGRvIHRoZSBkaXNjb3ZlcnksIEkg ZG9uJ3Qga25vdyB3aGljaCBjb3VudHJ5IEkgYW0gaW4uICZuYnNwO0kgY2FuJ3Qga25vdyBlbm91 Z2ggdG8gcXVlcnkgdGhlIHJpZ2h0IERTIHVubGVzcyB3ZSBwdXQgY291bnRyeSBib3VuZGFyeSBw b2x5Z29ucyBpbiB0aGUgZGV2aWNlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+T2YgY291cnNl LCBJIGZvcmdvdCB0byBhZGQgdG8gdGhpcyB0aGF0IGlmIHRoZXJlIGlzIHRoZSBVLlMuIG1vZGVs IG9mIGNvbXBldGluZyBEQnMsIHRoZW4gdGhlIHdob2xlIGRpc2NvdmVyeSBtZWNoYW5pc20gZmFs bHMgYXBhcnQsIGFuZCB5b3UgbmVlZCBjb25maWd1cmF0aW9uLCBiZWNhdXNlIGlmIHRoZSBkZXZp Y2Uga25vd3Mgd2hvIGl0cyBidXNpbmVzcyByZWxhdGlvbnNoaXAgaXMgd2l0aCwgaXQgY2FuIGtu b3cgdGhlIFVSSS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkJyaWFuPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48YnI+PGRpdj48ZGl2PjxkaXY+T24gSnVsIDEwLCAyMDEyLCBhdCAzOjM4IFBN LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbSI+c2NvdHQucHJv YmFzY29Abm9raWEuY29tPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzY290dC5wcm9iYXNj b0Bub2tpYS5jb20iPnNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2 PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQoNCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2PkhpIEJyaWFuLDwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkNvbW1lbnRzIGJlbG93OiBNU1AtJmd0OzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PktpbmQgUmVnYXJkcyw8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2PlNjb3R0PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFs aWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVS LUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBp bjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9S REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiJleHQgUm9zZW4sIEJyaWFuIiAmbHQ7PGEg aHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5Ccmlhbi5Sb3NlbkBuZXVzdGFy LmJpejwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv c3Bhbj5Nb24sIDkgSnVsIDIwMTIgMTc6Mjc6MzEgLTA0MDA8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5TY290dCBQcm9iYXNjbyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbSI+c2NvdHQucHJvYmFzY29Abm9raWEuY29tPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4iPGEg aHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+IiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtwYXdzXSBkcmFm dCBkb2N1bWVudCBmb3IgRGlzY292ZXJ5PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KVGhp cyByZS1pbnZlbnRzIExvU1Qgd2l0aG91dCB0aGUgZXh0ZW5zaXZlIG1lY2hhbmlzbXMgZm9yIHNl bGYgb3JnYW5pemluZyBkYXRhYmFzZXMuDQo8ZGl2PkxvU1QgaGFzIGEgcXVlcnkgdGhhdCBzZW5k cyBsb2NhdGlvbiBpbiwgd2l0aCBhIFNlcnZpY2UgVVJOICh3aGljaCBmb3IgdGhpcyB1c2Ugd291 bGQgYmUgIkkgd2FudCBhIFdTREIgZm9yIHRoaXMgbG9jYXRpb24iIGFuZCB5b3UgZ2V0IGJhY2sg KGEgbGlzdCBvZikgVVJJcy4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aGF0J3Mgd2hhdCB5b3UgcHJvcG9zZSwgd2l0aG91dCB0aGUgc2VydmljZSBVUk4gYmVjYXVzZSB5 b3Ugd2FudCBhIHNwZWNpYWwgbG9jYXRpb24gYmFzZWQgZGlzY292ZXJ5IG1lY2hhbmlzbSBqdXN0 IGZvciBXU0RCcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsgIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgeW91IGRvbid0IGRl YWwgd2l0aCBpcyBob3cgYSBXU0RCIERTIGZpbmRzIG91dCBhYm91dCBhbGwgb3RoZXIgV1NEQiBE U3MuICZuYnNwO1RoYXQncyB0aGUgTG9TVCAiRm9yZXN0IEd1aWRlIi4gJm5ic3A7VGhlIEZHIHdv cmtzIHdpdGhvdXQgYSByb290LCBhbmQgYWxsb3dzIGNvb3BlcmF0aW5nIExvU1Qgc2VydmVycyB0 byAmbmJzcDtyZWZlciBxdWVyaWVzIHRvIHRoZSByaWdodCBzZXJ2ZXIuPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5NU1AtJmd0O0lmIGVhY2ggV1NEIHZlbmRvciBhcnJhbmdl cyBhIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IHdpdGggYSBXU0RCIERTIChvciZuYnNwO3Byb3Zp ZGVzIHRoZWlyIG93biBXU0RCIERTKSB0aGVuIGl0IGlzIG5vdCBvYnZpb3VzIHRvIG1lIHdoeSBh IFdTREIgRFMgd291bGQgbmVlZCB0byBmaW5kIG91dCBhYm91dCBvdGhlciBXU0RCIERTcy4gRWFj aCBXU0RCIERTIGlzIGluZGVwZW5kZW50LiBJZiB2ZW5kb3IgWCBpbnRlbmRzIHRoZWlyIFdTRA0K IHRvIG9wZXJhdGUgaW4gQ291bnRyeSBZLCB0aGVuIFdTREIgRFMgdXNlZCBieSB2ZW5kb3IgWCBt dXN0IGluY2x1ZGUgYXBwcm9wcmlhdGUgQ291bnRyeSBZIG1hcHBpbmcgaW5mb3JtYXRpb24gKGxv Y2F0aW9uIHRvIFdTREIgb3IgV1NEQiBsaXN0aW5nIHNlcnZlcikgaW4gdGhlaXIgV1NEQiBEUy48 L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5JdCdzIG5vdCByZWFsbHkgYSBncmVhdCBpZGVhIHRvIGJha2UgYSBVUkkgaW50byBhIGRl dmljZS4gJm5ic3A7V2hvIGtub3dzIHdoYXQgd2lsbCBoYXBwZW4gb3ZlciB0aGUgbGlmZSBvZiBh IGRldmljZT88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pk1TUC0mZ3Q7SW5j bHVkaW5nIGFuIGFkZHJlc3MgaW4gdGhlIGRldmljZSBkb2VzIG5vdCBpbXBseSB0aGF0IHRoZSBh ZGRyZXNzIGNhbm5vdCBiZSBjaGFuZ2VkIGlmIG5lZWRlZC4gU1cgdXBkYXRlcywgZGV2aWNlIG1h bmFnZW1lbnQgb3Igc2ltaWxhciBjYW4gYWxsb3cgZm9yIGNoYW5nZXMgaWYgbmVlZGVkLiBJIHRh a2UgeW91ciBwb2ludCwgdGhlc2UgY2hhbmdlcyBzaG91bGQgYmUgZXhjZXB0aW9ucyByYXRoZXIg dGhhbiByZWd1bGFyIGV2ZW50cy48L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZXhpc3RpbmcgTG9TVCBkaXNjb3ZlcnkgbWVj aGFuaXNtIGlzIGJ1aWx0IGZvciB3aWRlc3ByZWFkIGRlcGxveW1lbnQgaW4gSVNQcy4gJm5ic3A7 IFdlIG1heSBuZWVkIHNvbWV0aGluZyB0aGF0IHdvcmtzIHdlbGwgd2l0aG91dCB0aGF0LiAmbmJz cDtUaGVyZSBhcmVuJ3QgYSBsb3Qgb2YgZ29vZCBtZWNoYW5pc21zIHRoYXQgcmVhbGx5IHdvcmsg d2VsbCAtIHlvdSBlaXRoZXIgaGF2ZSBhIHJvb3Qgb2Ygc29tZSBzb3J0LCBvciwgYXMgeW91IHBy b3Bvc2UsDQogYSBzdGFydGluZyBzZWVkLiAmbmJzcDtUaGUgcm9vdCBwcm9ibGVtIGlzIHdobyBy dW5zIHRoZSByb290LCBhbmQgdGhlIHN0YXJ0aW5nIHNlZWQgcHJvYmxlbSBpcyB0aGUgbGlmZXRp bWUgb2YgdGhlIHNlZWQuICZuYnNwO1lvdSBub3RlIHRoYXQgdGhlIHNlZWQgZ2V0cyBub3RoaW5n IG91dCBvZiB0aGUgZXhjaGFuZ2UgLSBpdCBkb2Vzbid0IGdldCB0byBzZXJ2ZSB0aGUgcXVlcnks IGl0IG9ubHkgZ2V0cyB0byByZWZlciB0byBzb21lb25lIHdobyBkb2VzLiAmbmJzcDs8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pk1TUC0mZ3Q7SXQgaXMgbm90IGNsZWFyIHRv IG1lIHdoYXQgYnVzaW5lc3MgbW9kZWwgd291bGQgc3VwcG9ydCBhIHNvcGhpc3RpY2F0ZWQgaW5m cmFzdHJ1Y3R1cmUgYXMgZGVzY3JpYmVkIGluIHRoZSBMb1NUIEFyY2hpdGVjdHVyZSAmYW1wOyBG cmFtZXdvcmsgUkZDIDU1ODIuPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBhY3R1YWxseSB0aGluayB0aGlzIGlzIG5vdCBhbiBp bXBvcnRhbnQgcHJvYmxlbSB0byBzb2x2ZSByZWFsbHkgd2VsbC4gJm5ic3A7VGhlIG1vc3QgY29t bW9uIGRlcGxveW1lbnQgbW9kZWwgaXMgZ29pbmcgdG8gYmUgYSB0b3dlciBhbmQgY2xpZW50cy4g Jm5ic3A7VGhlIHRvd2VyIGNhbiBiZSBjb25maWd1cmVkLCBhbmQgZWl0aGVyIHRoZSBjbGllbnRz IGxlYXJuIGZyb20gdGhlIHRvd2VyLCBvciB0aGUgdG93ZXIgaGFuZGxlcyB0aGUgZGF0YWJhc2Ug cXVlcnkNCiBpdHNlbGYuICZuYnNwO0NsaWVudCBkaXNjb3ZlcnkgaW4gdGhhdCBjYXNlIGNvdWxk IGJlIHRoZSBMb1NUIGRpc2NvdmVyeSBtZWNoYW5pc20uPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9zcGFuPjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5XZSBoYXZlIHRvIGhhbmRsZSB0aGUgc2VsZiBvcmdhbml6aW5nIGNhc2UgKHNheSBhIE1B TkVUKSB3aGVyZSBvbmUgb3IgbW9yZSBkZXZpY2VzIGhhdmUgc29tZSBvdGhlciBwYXRoIHRvIHRo ZSBJbnRlcm5ldCB0byBnZXQgdG8gdGhlIFdTREIuICZuYnNwO1RoZXkgd2lsbCBuZWVkIHJlYWwg ZGlzY292ZXJ5IGFuZCBtYXkgbm90IGhhdmUgYSBjb29wZXJhdGluZyBJU1AuICZuYnNwO1doaWxl IEkgcmVhbGx5IGRvbid0IGxpa2UgY29uZmlndXJhdGlvbiwgaXQNCiBtYXkgYmUgdGhlIG9ubHkg dmlhYmxlIHdheSB0byBkbyBpdC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+TVNQLSZndDtDb25maWd1cmF0aW9uIGlzIHByYWdtYXRp YyBhbmQgY2FuIGJlIGVhc2lseSBkZXBsb3llZDwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9E WV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CcmlhbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj5PbiBKdWwgOSwgMjAxMiwgYXQgNTowNCBQTSwgJmx0OzxhIGhyZWY9 Im1haWx0bzpzY290dC5wcm9iYXNjb0Bub2tpYS5jb20iPnNjb3R0LnByb2Jhc2NvQG5va2lhLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2PkhlbGxvIEFsbCw8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBsZWFzZSBmaW5kIGEgbGluayBiZWxvdyB0byBh IGRyYWZ0IHN1Ym1pc3Npb24gZm9yIHRoZSBEaXNjb3ZlcnkgcHJvY2VzcyBhcyBkZXNjcmliZWQg aW4gdGhlIFVzZSBDYXNlcyAmYW1wOyBSZXF1aXJlbWVudHMgZG9jdW1lbnQuIFdlIGFyZSBsb29r aW5nIGZvcndhcmQgdG8geW91ciByZXZpZXcgYW5kIGNvbW1lbnRzIGFzIHdlbGwgYXMgZGlzY3Vz c2lvbiBhdCBJRVRGIzg0LjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD b25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07ICI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNw YW4iIGZhY2U9IkNhbGlicmkiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07ICI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDYWxpYnJpOyAiPkFic3RyYWN0Ojwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07ICI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpOyAiPiZuYnNwOyZuYnNwOyBBIHdoaXRlIHNwYWNlIG1hc3RlciBk ZXZpY2UgbmVlZHMgdG8gcXVlcnkgYSB3aGl0ZSBzcGFjZSBkYXRhYmFzZSBhbmQ8L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVt OyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgIj4mbmJzcDsmbmJzcDsgb2J0 YWluIGluZm9ybWF0aW9uIGFib3V0IGF2YWlsYWJsZSBzcGVjdHJ1bS9jaGFubmVscyBwcmlvciB0 bzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1z aXplOiBtZWRpdW07ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPiZuYnNw OyZuYnNwOyBvcGVyYXRpb24uJm5ic3A7Jm5ic3A7V2hpdGUgc3BhY2UgZGF0YWJhc2VzIHdoaWNo IGNvbnRhaW4gaW5mb3JtYXRpb24gYWJvdXQ8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQ2FsaWJyaTsgIj4mbmJzcDsmbmJzcDsgYXZhaWxhYmxlIHNwZWN0cnVtL2NoYW5u ZWxzIGFyZSBhc3NvY2lhdGVkIHdpdGggYSByZWd1bGF0b3J5IGRvbWFpbi48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyAi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgIj4mbmJzcDsmbmJzcDsgQSB3aGl0 ZSBzcGFjZSBtYXN0ZXIgZGV2aWNlIG5lZWRzIHRvIGRpc2NvdmVyIHRoZSByZWxldmFudCB3aGl0 ZTwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1z aXplOiBtZWRpdW07ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPiZuYnNw OyZuYnNwOyBzcGFjZSBkYXRhYmFzZShzKSBnaXZlbiBpdHMgY3VycmVudCBsb2NhdGlvbiBhbmQg aW4gd2hpY2ggcmVndWxhdG9yeTwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpOyAiPiZuYnNwOyZuYnNwOyBkb21haW4gdGhhdCBpdCBpcyBvcGVyYXRpbmcuJm5i c3A7Jm5ic3A7VGhlIHdoaXRlIHNwYWNlIGRhdGFiYXNlIGRpc2NvdmVyeSBpczwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07 ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyAiPiZuYnNwOyZuYnNwOyB0aGUg cHJlbGltaW5hcnkgc3RlcCB0aGF0IGEgd2hpdGUgc3BhY2UgbWFzdGVyIGRldmljZSBoYXMgdG8g cGVyZm9ybS48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6 IG1lZGl1bTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7ICI+VVJMOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7ICI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgIj48YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wcm9iYXNjby1wYXdzLWRp c2NvdmVyeS0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXByb2Jhc2NvLXBhd3MtZGlzY292ZXJ5LTAwLnR4dDwvYT48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgIj5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcHJvYmFzY28tcGF3cy1kaXNjb3ZlcnktMDAiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1wcm9iYXNjby1wYXdzLWRpc2NvdmVyeS0wMDwvc3Bhbj48L2E+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgIj48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pktp bmQgUmVnYXJkcyw8L2Rpdj4NCjxkaXY+U2NvdHQgJmFtcDsgUmFqPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGF3cyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Bhd3MiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48 YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9kaXY+DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnBhd3MgbWFpbGluZyBsaXN0PGJy PjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxicj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48YnI+PC9ibG9ja3F1b3RlPjwv ZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvc3Bhbj48YnI+PHNwYW4+cGF3cyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFu PjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjwvc3Bhbj48 YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8L2E+PC9zcGFu Pjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_7E7636AD90AA485EA826155052EE4A91spectrumbridgecom_-- From brian.rosen@neustar.biz Tue Jul 10 14:17:29 2012 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 26E2B21F8638 for ; Tue, 10 Jul 2012 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.490, 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 4eoEo21e25c3 for ; Tue, 10 Jul 2012 14:17:27 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 39B4211E80CC for ; Tue, 10 Jul 2012 14:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1341955324; x=1657309342; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=VGOnvXOLvqp3ie2Q8j+UWhvXITk1qyxlez0SoubEYpw=; b=ZhvVL3TgAYvS6MZD5oBXV1iJSNNq2HCDKObUUH72wapQW77DWlWD+lAv4chETA SESGHXrw9HM24Iu+OxHScjJg== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.11769663; Tue, 10 Jul 2012 17:22:03 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 10 Jul 2012 17:17:48 -0400 From: "Rosen, Brian" To: Peter Stanforth Date: Tue, 10 Jul 2012 17:17:46 -0400 Thread-Topic: [paws] draft document for Discovery Thread-Index: Ac1e4XQPuQKOde12QVKU0ziF04UTUQ== Message-ID: <14FA0A69-0245-4297-9B0A-FDD71AC6B87D@neustar.biz> References: <1605A384-C2C4-4B3D-B862-4BC0CE3185DF@neustar.biz> <7E7636AD-90AA-485E-A826-155052EE4A91@spectrumbridge.com> In-Reply-To: <7E7636AD-90AA-485E-A826-155052EE4A91@spectrumbridge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 7wTMJ48f6ReprYakXY0OLA== Content-Type: multipart/alternative; boundary="_000_14FA0A69024542979B0AFDD71AC6B87Dneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:17:29 -0000 --_000_14FA0A69024542979B0AFDD71AC6B87Dneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That would work. This would happen every time the device booted. That could be a fair amoun= t of traffic for a high volume manufacturer. They have to support this fo= rever. It's simple. I wonder if the device mfg would agree to that? Brian On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote: on this topic a completely different approach would be for the device to ca= ll home, to the manufacturer, with the ability for the manufacturer to poin= t it to the appropriate DB for that location. This works well, and simply i= f we assume the device has the relationship with the DB. If it is a user (S= ay network operator) then I would expect them to configure their devices to= go where they desire them to go. On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_14FA0A69024542979B0AFDD71AC6B87Dneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That would work.

<= /div>
This would happen every time the device booted.  That could = be a fair amount of traffic for a high volume manufacturer.   They hav= e to support this forever.

It's simple.
=
I wonder if the device mfg would agree to that?
Brian

On Jul 10, 2012, at 5:09 PM, Pet= er Stanforth wrote:

on this topic a completely di= fferent approach would be for the device to call home, to the manufacturer,= with the ability for the manufacturer to point it to the appropriate DB fo= r that location. This works well, and simply if we assume the device has th= e relationship with the DB. If it is a user (Say network operator) then I w= ould expect them to configure their devices to go where they desire them to= go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:<= br>
When I do the d= iscovery, I don't know which country I am in.  I can't know enough to = query the right DS unless we put country boundary polygons in the device.

Of course, I forgot to add to this that if there is= the U.S. model of competing DBs, then the whole discovery mechanism falls = apart, and you need configuration, because if the device knows who its busi= ness relationship is with, it can know the URI.

Br= ian


On Jul 10, 2012, at 3:38 PM= , <scott.probasco@nokia.com<= /a>> <scott.probasco@noki= a.com> wrote:

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get back (a li= st of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works without a = root, and allows cooperating LoST servers to  refer queries to the rig= ht server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian


Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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


= --_000_14FA0A69024542979B0AFDD71AC6B87Dneustarbiz_-- From scott.probasco@nokia.com Tue Jul 10 14:35:58 2012 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 387FF11E80CC for ; Tue, 10 Jul 2012 14:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIzPo4ehJqT0 for ; Tue, 10 Jul 2012 14:35:56 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id E573E21F8601 for ; Tue, 10 Jul 2012 14:35:55 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6ALaHYe028281 for ; Wed, 11 Jul 2012 00:36:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 00:36:40 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Tue, 10 Jul 2012 23:36:16 +0200 From: To: Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsam1igeb9LkGV+JKNCiTfyJcibuGAgAAGioCAAFdFAIAAAvgAgAADOoD//7WiAIAAWGkA//+1fAA= Date: Tue, 10 Jul 2012 21:36:15 +0000 Message-ID: In-Reply-To: <8754F7FB-AEF7-4F6C-B68C-B6EB0E076826@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.35.18] Content-Type: multipart/alternative; boundary="_000_CC2206FDDC44scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2012 21:36:41.0107 (UTC) FILETIME=[17F48E30:01CD5EE4] X-Nokia-AV: Clean Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:35:58 -0000 --_000_CC2206FDDC44scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, The concept of 'policy' is perhaps difficult to handle. We don't have a def= inition, and it could ultimately be simply a user's choice. It is difficult= to assume URIs could be configured with such flexibility. Roaming agreements among WSDBs is interesting, I like the concept. But the = protocols must function even if there happen to not be roaming agreements i= n place. If LoST turns out to be the best solution, I am okay with it. I believe we = need to look at proposals and understand what is needed, possible and also = pragmatic. Best Regards, Scott From: "ext Rosen, Brian" > Date: Tue, 10 Jul 2012 17:02:34 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery MSP->IMHO the process should work the same, at every power up. A WSD which = never 'roams' will experience the simple or trivial case (e.g. in the US al= ways receive the addresses of the same WSDBs, and likely pick the same addr= ess for service every time). But when the device powers up in a roaming sta= te, then the situation becomes more interesting. If you need to configure to have a policy that decides which of multiple co= mpeting databases you have a relationship with, configure the URI to the da= tabase. If your default database has roaming agreements, your configured database c= an refer you to the right one. If your device can roam, on its own, to places where there is only one data= base (for example, a government run or sponsored database), then we might w= ant a discovery mechanism, but I think LoST is it. MSP->Simplicity? It is not obvious for me how a white space business model = will support the Authoritative Mapping Server, Forest Guide & Resolver enti= ties in RFC5582. Authoritative Mapping server =3D Lost Server. Your DS. Forest Guide can be part of the LoST server - it's just an entity that exch= anges coverage information with other FGs to build a referral database. You can restrict access to the FG to only authorized LoST servers (DS in yo= ur terms). That means that if a DS doesn't know what the right DS is, it c= onsults the FG, which tells it. That makes the load on the FG very low. F= Gs have no root. It would be perfectly reasonable for a regulator to run a= n FG as long as only DSs in the country could access it. It would connect = to similar FGs elsewhere. It's also possible for anyone who wants to to run an FG with similar restri= ctions - only handling requests from DSs (LoST servers) it knows. It would be very easy for example, the U.S. WSDB Admins to agree on an FG m= odel that worked for the US and connected to other country's DSs. Brian If you want to build in some default LoST server URI into the device, as lo= ng as that server is willing to refer the query to the right LoST server fo= r ever, for free, that works. Brian On Jul 10, 2012, at 4:00 PM, > wrote: Inline: From: "", "Brian.Rosen@neustar.biz" > Date: Tuesday, July 10, 2012 2:50 PM To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Raj> The WSD could send information (such as GPS co-ordinates, MCC+MNC, SSI= D etc.) to the discovery server which can be used to determine the country = that it is in. The DS itself is not country specific. It uses the informati= on sent by the device to determine which country the device is located in a= nd respond with the address(es) of the WSDBs therein. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is= with, it can know the URI. Raj> In such a case it is configured in the device. The device could still = query the DS and get a list of competing databases and then some policy on = the device will enable it to choose a preferred DB. -Raj Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC2206FDDC44scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Brian,

The concept of 'policy' is perhaps difficult to handle. We don't have = a definition, and it could ultimately be simply a user's choice. It is diff= icult to assume URIs could be configured with such flexibility.

Roaming agreements among WSDBs is interesting, I like the concept. But= the protocols must function even if there happen to not be roaming agreeme= nts in place.

If LoST turns out to be the best solution, I am okay with it. I believ= e we need to look at proposals and understand what is needed, possible and = also pragmatic.

Best Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Tue, 10 Jul 2012 17:02:34 -04= 00
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

MSP->IMHO the process should work the same, at every power up. A WS= D which never 'roams' will experience the simple or trivial case (e.g. in t= he US always receive the addresses of the same WSDBs, and likely pick the s= ame address for service every time). But when the device powers up in a roaming state, then the situation becom= es more interesting.
If you need to configure to have a policy that decides which of multiple co= mpeting databases you have a relationship with, configure the URI to the da= tabase.

If your default database has roaming agreements, your configured datab= ase can refer you to the right one.

If your device can roam, on its own, to places where there is only one= database (for example, a government run or sponsored database), then we mi= ght want a discovery mechanism, but I think LoST is it.

MSP->Simplicity? It is not obvious for me how a white space busines= s model will support the Authoritative Mapping Server, Forest Guide & R= esolver entities in RFC5582.
Authoritative Mapping server =3D Lost Server.  Your DS.
Forest Guide can be part of the LoST server - it's just an entity that= exchanges coverage information with other FGs to build a referral database= .

You can restrict access to the FG to only authorized LoST servers (DS = in your terms).  That means that if a DS doesn't know what the right D= S is, it consults the FG, which tells it.  That makes the load on the = FG very low.  FGs have no root.  It would be perfectly reasonable for a regulator to run an FG as long as only DSs i= n the country could access it.  It would connect to similar FGs elsewh= ere.

It's also possible for anyone who wants to to run an FG with similar r= estrictions - only handling requests from DSs (LoST servers) it knows.

It would be very easy for example, the U.S. WSDB Admins to agree on an= FG model that worked for the US and connected to other country's DSs.

Brian

If you want to build in some default LoST server URI into the device, = as long as that server is willing to refer the query to the right LoST serv= er for ever, for free, that works.

Brian



On Jul 10, 2012, at 4:00 PM, <Basavaraj.Patil@nokia.com> wrote:

Inline: 

From: "<ext Rosen>"= , "Brian.Rosen@neustar.biz<= /a>" <Brian.Rosen@neusta= r.biz>
Date: Tuesday, July 10, 2012 2:50 P= M
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

When I do the discovery, I don't know which country I am in.  I c= an't know enough to query the right DS unless we put country boundary polyg= ons in the device.

Raj> The WSD could send information (such as GPS co-ordinates, MCC&= #43;MNC, SSID etc.) to the discovery server which can be used to determine = the country that it is in. The DS itself is not country specific. It uses t= he information sent by the device to determine which country the device is located in and respond with the address(es) of= the WSDBs therein.

Of course, I forgot to add to this that if there is the U.S. model of = competing DBs, then the whole discovery mechanism falls apart, and you need=  
configuration, because if the device knows who its business relationsh= ip is with, it can know the URI.

Raj> In such a case it is configured in the device. The device coul= d still query the DS and get a list of competing databases and then some po= licy on the device will enable it to choose a preferred DB.

-Raj


Brian


On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get = back (a list of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works = without a root, and allows cooperating LoST servers to  refer queries = to the right server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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


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

--_000_CC2206FDDC44scottprobasconokiacom_-- From scott.probasco@nokia.com Tue Jul 10 14:36:44 2012 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 159D611E80F8 for ; Tue, 10 Jul 2012 14:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.184, 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 FldXPMg1mXfM for ; Tue, 10 Jul 2012 14:36:42 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 821C621F8648 for ; Tue, 10 Jul 2012 14:36:42 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6ALb9Ou027429 for ; Wed, 11 Jul 2012 00:37:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 00:37:32 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0283.004; Tue, 10 Jul 2012 23:37:07 +0200 From: To: Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsam1igeb9LkGV+JKNCiTfyJcibuGAgAAGioCAAFdFAIAAFjWA//+z2IA= Date: Tue, 10 Jul 2012 21:37:06 +0000 Message-ID: In-Reply-To: <7E7636AD-90AA-485E-A826-155052EE4A91@spectrumbridge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.35.18] Content-Type: multipart/alternative; boundary="_000_CC220A6DDC62scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2012 21:37:32.0998 (UTC) FILETIME=[36E27E60:01CD5EE4] X-Nokia-AV: Clean Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:36:44 -0000 --_000_CC220A6DDC62scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, In the simplest form, this is the essence of our discovery proposal. The de= vice calls home to learn which DB to use. Best Regards, Scott From: "ext com>" = > Date: Tue, 10 Jul 2012 17:09:37 -0400 To: "Rosen, Brian" = > Cc: Scott Probasco >, "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery on this topic a completely different approach would be for the device to ca= ll home, to the manufacturer, with the ability for the manufacturer to poin= t it to the appropriate DB for that location. This works well, and simply i= f we assume the device has the relationship with the DB. If it is a user (S= ay network operator) then I would expect them to configure their devices to= go where they desire them to go. On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC220A6DDC62scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Peter,

In the simplest form, this is the essence of our discovery proposal. T= he device calls home to learn which DB to use. 

Best Regards,
Scott

From: "ext com>" <<= a href=3D"mailto:peter@spectrumbridge.com">peter@spectrumbridge.com>=
Date: Tue, 10 Jul 2012 17:09:37 -04= 00
To: "Rosen, Brian" <Brian.Rosen@neustar.biz> Cc: Scott Probasco <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document = for Discovery

on this topic a completely different approach would be for the device = to call home, to the manufacturer, with the ability for the manufacturer to= point it to the appropriate DB for that location. This works well, and sim= ply if we assume the device has the relationship with the DB. If it is a user (Say network operator) then = I would expect them to configure their devices to go where they desire them= to go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

When I do the discovery, I don't know which country I am in.  I c= an't know enough to query the right DS unless we put country boundary polyg= ons in the device.

Of course, I forgot to add to this that if there is the U.S. model of = competing DBs, then the whole discovery mechanism falls apart, and you need= configuration, because if the device knows who its business relationship i= s with, it can know the URI.

Brian


On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get = back (a list of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works = without a root, and allows cooperating LoST servers to  refer queries = to the right server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ie= tf.org/mailman/listinfo/paws
 --_000_CC220A6DDC62scottprobasconokiacom_-- From scott.probasco@nokia.com Tue Jul 10 14:43:17 2012 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 2E1D311E80C4 for ; Tue, 10 Jul 2012 14:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.165, 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 Vb-5PoQ9GIGN for ; Tue, 10 Jul 2012 14:43:15 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id C929B21F8589 for ; Tue, 10 Jul 2012 14:43:14 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6ALhgUe002123 for ; Wed, 11 Jul 2012 00:43:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 00:44:06 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Tue, 10 Jul 2012 23:43:41 +0200 From: To: Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsam1igeb9LkGV+JKNCiTfyJcibuGAgAAGioCAAFdFAIAAFjWAgAACRwD//7NSgA== Date: Tue, 10 Jul 2012 21:43:40 +0000 Message-ID: In-Reply-To: <14FA0A69-0245-4297-9B0A-FDD71AC6B87D@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.35.18] Content-Type: multipart/alternative; boundary="_000_CC220AB3DC67scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2012 21:44:06.0506 (UTC) FILETIME=[216F0CA0:01CD5EE5] X-Nokia-AV: Clean Subject: Re: [paws] draft document for Discovery X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:43:17 -0000 --_000_CC220AB3DC67scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, It is simple. Vendors could support it forever. And if for example the roam= ing agreement becomes a preferred solution, the vendor could program one or= more addresses into the device (SW update, device management, etc). In the= use case & requirements document the assumption has been that a simple cas= e of discovery is hard-coded addresses in the device. Best Regards, Scott From: "ext Rosen, Brian" > Date: Tue, 10 Jul 2012 17:17:46 -0400 To: "ext com>" > Cc: Scott Probasco >, "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery That would work. This would happen every time the device booted. That could be a fair amoun= t of traffic for a high volume manufacturer. They have to support this fo= rever. It's simple. I wonder if the device mfg would agree to that? Brian On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote: on this topic a completely different approach would be for the device to ca= ll home, to the manufacturer, with the ability for the manufacturer to poin= t it to the appropriate DB for that location. This works well, and simply i= f we assume the device has the relationship with the DB. If it is a user (S= ay network operator) then I would expect them to configure their devices to= go where they desire them to go. On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CC220AB3DC67scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi All,

It is simple. Vendors could support it forever. And if for example the= roaming agreement becomes a preferred solution, the vendor could program o= ne or more addresses into the device (SW update, device management, etc). I= n the use case & requirements document the assumption has been that a simple case of discovery is hard-coded addr= esses in the device.

Best Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Tue, 10 Jul 2012 17:17:46 -04= 00
To: "ext com>" <peter@spectrumbridge.com> Cc: Scott Probasco <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document = for Discovery

That would work.

This would happen every time the device booted.  That could be a = fair amount of traffic for a high volume manufacturer.   They have to = support this forever.

It's simple.

I wonder if the device mfg would agree to that?

Brian

On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote:

on this topic a completely different approach would be for the device = to call home, to the manufacturer, with the ability for the manufacturer to= point it to the appropriate DB for that location. This works well, and sim= ply if we assume the device has the relationship with the DB. If it is a user (Say network operator) then = I would expect them to configure their devices to go where they desire them= to go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

When I do the discovery, I don't know which country I am in.  I c= an't know enough to query the right DS unless we put country boundary polyg= ons in the device.

Of course, I forgot to add to this that if there is the U.S. model of = competing DBs, then the whole discovery mechanism falls apart, and you need= configuration, because if the device knows who its business relationship i= s with, it can know the URI.

Brian


On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" = <Brian.Rosen@neustar.biz&= gt;
Date: Mon, 9 Jul 2012 17:27:31 -040= 0
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

This re-invents LoST without the extensive mechanisms for self organizing d= atabases.
LoST has a query that sends location in, with a Service URN (which for= this use would be "I want a WSDB for this location" and you get = back (a list of) URIs.  

That's what you propose, without the service URN because you want a sp= ecial location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WS= DB DSs.  That's the LoST "Forest Guide".  The FG works = without a root, and allows cooperating LoST servers to  refer queries = to the right server.
MSP->If each WSD vendor arranges a service level agreement with a W= SDB DS (or provides their own WSDB DS) then it is not obvious to me wh= y a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is in= dependent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include approp= riate Country Y mapping information (location to WSDB or WSDB listing serve= r) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who kn= ows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the add= ress cannot be changed if needed. SW updates, device management or similar = can allow for changes if needed. I take your point, these changes should be= exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployme= nt in ISPs.   We may need something that works well without that. &nbs= p;There aren't a lot of good mechanisms that really work well - you either = have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the star= ting seed problem is the lifetime of the seed.  You note that the seed= gets nothing out of the exchange - it doesn't get to serve the query, it o= nly gets to refer to someone who does.  
MSP->It is not clear to me what business model would support a soph= isticated infrastructure as described in the LoST Architecture & Framew= ork RFC 5582.

I actually think this is not an important problem to solve really well= .  The most common deployment model is going to be a tower and clients= .  The tower can be configured, and either the clients learn from the = tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery me= chanism.

We have to handle the self organizing case (say a MANET) where one or = more devices have some other path to the Internet to get to the WSDB.  = ;They will need real discovery and may not have a cooperating ISP.  Wh= ile I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



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

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

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

 --_000_CC220AB3DC67scottprobasconokiacom_-- From andy.sago@bt.com Wed Jul 11 14:21:24 2012 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 9A11E11E80EE for ; Wed, 11 Jul 2012 14:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.213, 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 S5kAk7gteGhn for ; Wed, 11 Jul 2012 14:21:19 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id C33A011E80EA for ; Wed, 11 Jul 2012 14:21:18 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 11 Jul 2012 22:21:49 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.29]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 11 Jul 2012 22:21:49 +0100 From: To: , Date: Wed, 11 Jul 2012 22:21:47 +0100 Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsam1igeb9LkGV+JKNCiTfyJcibuGAgAAGioCAAFdFAIAAFjWAgAACRwD//7NSgIAB/r4g Message-ID: <619CDADDCCD2B44380834BE8BF6F714140A8FD87D6@EMV62-UKRD.domain1.systemhost.net> References: <14FA0A69-0245-4297-9B0A-FDD71AC6B87D@neustar.biz> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F714140A8FD87D6EMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] draft document for Discovery 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, 11 Jul 2012 21:21:24 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140A8FD87D6EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All Just to highlight that Ofcom requires that the list of available databases = (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving= database operators can be removed from the list and devices stop using the= ir channel allocations). Ofcom doesn't permit a master device to have a pre= -arrangement with a database (such as a pre-programmed URI), or at least, t= he validity of any pre-programmed URI has to be checked every 24 hours with= Ofcom's listing. The discovery problem is similar to US, but two step thro= ugh an intermediate listing. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 10 July 2012 22:44 To: paws@ietf.org Subject: Re: [paws] draft document for Discovery Hi All, It is simple. Vendors could support it forever. And if for example the roam= ing agreement becomes a preferred solution, the vendor could program one or= more addresses into the device (SW update, device management, etc). In the= use case & requirements document the assumption has been that a simple cas= e of discovery is hard-coded addresses in the device. Best Regards, Scott From: "ext Rosen, Brian" > Date: Tue, 10 Jul 2012 17:17:46 -0400 To: "ext com>" > Cc: Scott Probasco >, "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery That would work. This would happen every time the device booted. That could be a fair amoun= t of traffic for a high volume manufacturer. They have to support this fo= rever. It's simple. I wonder if the device mfg would agree to that? Brian On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote: on this topic a completely different approach would be for the device to ca= ll home, to the manufacturer, with the ability for the manufacturer to poin= t it to the appropriate DB for that location. This works well, and simply i= f we assume the device has the relationship with the DB. If it is a user (S= ay network operator) then I would expect them to configure their devices to= go where they desire them to go. On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_619CDADDCCD2B44380834BE8BF6F714140A8FD87D6EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

<= p class=3DMsoNormal> 

Just to highlight that Ofc= om requires that the list of available databases (maintained by Ofcom) is c= onsulted once every 24 hours (so that misbehaving database operators can be= removed from the list and devices stop using their channel allocations). O= fcom doesn’t permit a master device to have a pre-arrangement with a = database (such as a pre-programmed URI), or at least, the validity of any p= re-programmed URI has to be checked every 24 hours with Ofcom’s listi= ng. The discovery problem is similar to US, but two step through an interme= diate listing.

 

=

Regards

 =

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: = 10 July 2012 22:44
To: paws@ietf.org
Subject: Re: [paws= ] draft document for Discovery

 

Hi All,<= /o:p>

 

It is simple. Vendors could supp= ort it forever. And if for example the roaming agreement becomes a preferre= d solution, the vendor could program one or more addresses into the device = (SW update, device management, etc). In the use case & requirements doc= ument the assumption has been that a simple case of discovery is hard-coded= addresses in the device.

 

B= est Regards,

Scot= t

 

From: <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:bla= ck'>"ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Tue, 10 Jul 2012 17:17= :46 -0400
To: "ext com>" <peter@spectrumbridge.com>
Cc: Scott P= robasco <scott.probasco@noki= a.com>, "paws@ietf.org&quo= t; <paws@ietf.org>
Subject= : Re: [paws] draft document for Discovery

 

That would work.

 

This would happen every time the device booted.  That could b= e a fair amount of traffic for a high volume manufacturer.   They have= to support this forever.

 

I= t's simple.

=  

I wonder if the= device mfg would agree to that?

 

Brian

 

On Jul 10, 201= 2, at 5:09 PM, Peter Stanforth wrote:



on this topic a completely differen= t approach would be for the device to call home, to the manufacturer, with = the ability for the manufacturer to point it to the appropriate DB for that= location. This works well, and simply if we assume the device has the rela= tionship with the DB. If it is a user (Say network operator) then I would e= xpect them to configure their devices to go where they desire them to go. &= nbsp;

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrot= e:

When I do the discovery, = I don't know which country I am in.  I can't know enough to query the = right DS unless we put country boundary polygons in the device.<= /span>

 

=

Of course, I forgot to add to this tha= t if there is the U.S. model of competing DBs, then the whole discovery mec= hanism falls apart, and you need configuration, because if the device knows= who its business relationship is with, it can know the URI.

 

Brian

 

 

On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:



Hi Brian,

 

Comments below: MSP->

 

Kind Regards,

<= div>

Scott

 

From: "ext Rosen, Brian" <= ;Brian.Rosen@neustar.biz>=
Date: Mon, 9 Jul 2012 17:27:31 -0400
To: Scott Probasc= o <scott.probasco@nokia.com<= /a>>
Cc: "paws@ietf.org<= /a>" <paws@ietf.org>
= Subject: Re: [paws] draft document for Discovery

<= /div>

 

=

This re-invents LoST without the extensive m= echanisms for self organizing databases.

LoST has a query that sends location in, with a Service = URN (which for this use would be "I want a WSDB for this location"= ; and you get back (a list of) URIs.  

 

That's what you propose, without the service URN because = you want a special location based discovery mechanism just for WSDBs.<= /o:p>

=  

What you d= on't deal with is how a WSDB DS finds out about all other WSDB DSs.  T= hat's the LoST "Forest Guide".  The FG works without a root,= and allows cooperating LoST servers to  refer queries to the right se= rver.

MSP->If each WSD vendor arranges a service level agreement with a WSDB = DS (or provides their own WSDB DS) then it is not obvious to me why a = WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is indepe= ndent. If vendor X intends their WSD to operate in Country Y, then WSDB DS = used by vendor X must include appropriate Country Y mapping information (lo= cation to WSDB or WSDB listing server) in their WSDB DS.<= /p>

 <= /p>

It's not really a great idea to bak= e a URI into a device.  Who knows what will happen over the life of a = device?

MSP->Including an address in the device does not imply that the addre= ss cannot be changed if needed. SW updates, device management or similar ca= n allow for changes if needed. I take your point, these changes should be e= xceptions rather than regular events.

=

 

The existing LoST discovery mechanism is built for wid= espread deployment in ISPs.   We may need something that works well wi= thout that.  There aren't a lot of good mechanisms that really work we= ll - you either have a root of some sort, or, as you propose, a starting se= ed.  The root problem is who runs the root, and the starting seed prob= lem is the lifetime of the seed.  You note that the seed gets nothing = out of the exchange - it doesn't get to serve the query, it only gets to re= fer to someone who does.  

MSP->It is not clear to me what business mode= l would support a sophisticated infrastructure as described in the LoST Arc= hitecture & Framework RFC 5582.

 

I actually think this is not an important problem to sol= ve really well.  The most common deployment model is going to be a tow= er and clients.  The tower can be configured, and either the clients l= earn from the tower, or the tower handles the database query itself.  = Client discovery in that case could be the LoST discovery mechanism.

<= o:p> 

We have to = handle the self organizing case (say a MANET) where one or more devices hav= e some other path to the Internet to get to the WSDB.  They will need = real discovery and may not have a cooperating ISP.  While I really don= 't like configuration, it may be the only viable way to do it.

MSP-&= gt;Configuration is pragmatic and can be easily deployed<= /p>

 

Brian

 

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wr= ote:



Hello All,

 

Please find a link below to a draft submis= sion for the Discovery process as described in the Use Cases & Requirem= ents document. We are looking forward to your review and comments as well a= s discussion at IETF#84.

<= o:p> 

Abstract:

   A white= space master device needs to query a white space database and

   obtain information= about available spectrum/channels prior to

<= p class=3DMsoNormal>   operation.  White space dat= abases which contain information about

   available spectrum/channels are associated= with a regulatory domain.

   A white space master device needs to discover the rele= vant white

 =   space database(s) given its current location and in which regulatory=

   domai= n that it is operating.  The white space database discovery is=

   the prel= iminary step that a white space master device has to perform.

 

 

URL:       =       http://www.ietf.org/internet-= drafts/draft-probasco-paws-discovery-00.txt

Htmlized:      &= nbsp; http://tools.ietf.= org/html/draft-probasco-paws-discovery-00

<= /div>

 

Kind Regards,

Scott & Raj

 

 

 <= /o:p>

_____________________= __________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws<= /p>

 

=

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

<= /div>

 

<= div>

_____________________________________________= __
paws mailing list
paws@ietf.org
https://www.ie= tf.org/mailman/listinfo/paws

 

= --_000_619CDADDCCD2B44380834BE8BF6F714140A8FD87D6EMV62UKRDdoma_-- From jmh@joelhalpern.com Wed Jul 11 14:48:14 2012 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 3B5CE21F84DF for ; Wed, 11 Jul 2012 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIluoSbpPK33 for ; Wed, 11 Jul 2012 14:48:13 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDF721F84EE for ; Wed, 11 Jul 2012 14:48:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 4C68355804F for ; Wed, 11 Jul 2012 14:48:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D02641C0B5D; Wed, 11 Jul 2012 14:48:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.105] (pool-71-161-51-33.clppva.btas.verizon.net [71.161.51.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6D5E61C089E; Wed, 11 Jul 2012 14:48:40 -0700 (PDT) Message-ID: <4FFDF49B.8040307@joelhalpern.com> Date: Wed, 11 Jul 2012 17:48:11 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: andy.sago@bt.com References: <14FA0A69-0245-4297-9B0A-FDD71AC6B87D@neustar.biz> <619CDADDCCD2B44380834BE8BF6F714140A8FD87D6@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140A8FD87D6@EMV62-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: paws@ietf.org Subject: Re: [paws] draft document for Discovery 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, 11 Jul 2012 21:48:14 -0000 It is pretty clear, and reasonable, that different domains are going to have different discovery rules. (I wish that regulators operating by defining their goals. There are other ways to achieve what ofcom wants. But that is a different rant.) The simplest answer from a protocol perspective seems to be to allow a provisioned starting point, and a recursion mechanism. Then it doesn't matter how many hops different domains require. Is it acceptable, in ofcom-like environments, for the device to call its vendor, in order to determine who to call next? (It is easy enough to design the referral to allow multiple stages of referral, as long as the regulations don't require that the master device must check with the regulator before checking with anyone else.) Yours, Joel On 7/11/2012 5:21 PM, andy.sago@bt.com wrote: > All > > Just to highlight that Ofcom requires that the list of available > databases (maintained by Ofcom) is consulted once every 24 hours (so > that misbehaving database operators can be removed from the list and > devices stop using their channel allocations). Ofcom doesn’t permit a > master device to have a pre-arrangement with a database (such as a > pre-programmed URI), or at least, the validity of any pre-programmed URI > has to be checked every 24 hours with Ofcom’s listing. The discovery > problem is similar to US, but two step through an intermediate listing. > > Regards > > Andy > > *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *scott.probasco@nokia.com > *Sent:* 10 July 2012 22:44 > *To:* paws@ietf.org > *Subject:* Re: [paws] draft document for Discovery > > Hi All, > > It is simple. Vendors could support it forever. And if for example the > roaming agreement becomes a preferred solution, the vendor could program > one or more addresses into the device (SW update, device management, > etc). In the use case & requirements document the assumption has been > that a simple case of discovery is hard-coded addresses in the device. > > Best Regards, > > Scott > > *From: *"ext Rosen, Brian" > > *Date: *Tue, 10 Jul 2012 17:17:46 -0400 > *To: *"ext com>" > > *Cc: *Scott Probasco >, "paws@ietf.org > " > > *Subject: *Re: [paws] draft document for Discovery > > That would work. > > This would happen every time the device booted. That could be a fair > amount of traffic for a high volume manufacturer. They have to support > this forever. > > It's simple. > > I wonder if the device mfg would agree to that? > > Brian > > On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote: > > > > on this topic a completely different approach would be for the device to > call home, to the manufacturer, with the ability for the manufacturer to > point it to the appropriate DB for that location. This works well, and > simply if we assume the device has the relationship with the DB. If it > is a user (Say network operator) then I would expect them to configure > their devices to go where they desire them to go. > > On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: > > When I do the discovery, I don't know which country I am in. I > can't know enough to query the right DS unless we put country > boundary polygons in the device. > > Of course, I forgot to add to this that if there is the U.S. model > of competing DBs, then the whole discovery mechanism falls apart, > and you need configuration, because if the device knows who its > business relationship is with, it can know the URI. > > Brian > > On Jul 10, 2012, at 3:38 PM, > > wrote: > > > > Hi Brian, > > Comments below: MSP-> > > Kind Regards, > > Scott > > *From: *"ext Rosen, Brian" > > *Date: *Mon, 9 Jul 2012 17:27:31 -0400 > *To: *Scott Probasco > > *Cc: *"paws@ietf.org " > > *Subject: *Re: [paws] draft document for Discovery > > This re-invents LoST without the extensive mechanisms for self > organizing databases. > > LoST has a query that sends location in, with a Service URN (which > for this use would be "I want a WSDB for this location" and you get > back (a list of) URIs. > > That's what you propose, without the service URN because you want a > special location based discovery mechanism just for WSDBs. > > What you don't deal with is how a WSDB DS finds out about all other > WSDB DSs. That's the LoST "Forest Guide". The FG works without a > root, and allows cooperating LoST servers to refer queries to the > right server. > > MSP->If each WSD vendor arranges a service level agreement with a > WSDB DS (or provides their own WSDB DS) then it is not obvious to me > why a WSDB DS would need to find out about other WSDB DSs. Each WSDB > DS is independent. If vendor X intends their WSD to operate in > Country Y, then WSDB DS used by vendor X must include appropriate > Country Y mapping information (location to WSDB or WSDB listing > server) in their WSDB DS. > > It's not really a great idea to bake a URI into a device. Who knows > what will happen over the life of a device? > > MSP->Including an address in the device does not imply that the > address cannot be changed if needed. SW updates, device management > or similar can allow for changes if needed. I take your point, these > changes should be exceptions rather than regular events. > > The existing LoST discovery mechanism is built for widespread > deployment in ISPs. We may need something that works well without > that. There aren't a lot of good mechanisms that really work well - > you either have a root of some sort, or, as you propose, a starting > seed. The root problem is who runs the root, and the starting seed > problem is the lifetime of the seed. You note that the seed gets > nothing out of the exchange - it doesn't get to serve the query, it > only gets to refer to someone who does. > > MSP->It is not clear to me what business model would support a > sophisticated infrastructure as described in the LoST Architecture & > Framework RFC 5582. > > I actually think this is not an important problem to solve really > well. The most common deployment model is going to be a tower and > clients. The tower can be configured, and either the clients learn > from the tower, or the tower handles the database query itself. > Client discovery in that case could be the LoST discovery mechanism. > > We have to handle the self organizing case (say a MANET) where one > or more devices have some other path to the Internet to get to the > WSDB. They will need real discovery and may not have a cooperating > ISP. While I really don't like configuration, it may be the only > viable way to do it. > > MSP->Configuration is pragmatic and can be easily deployed > > Brian > > On Jul 9, 2012, at 5:04 PM, > wrote: > > > > Hello All, > > Please find a link below to a draft submission for the Discovery > process as described in the Use Cases & Requirements document. We > are looking forward to your review and comments as well as > discussion at IETF#84. > > Abstract: > > A white space master device needs to query a white space > database and > > obtain information about available spectrum/channels prior to > > operation. White space databases which contain information about > > available spectrum/channels are associated with a regulatory domain. > > A white space master device needs to discover the relevant white > > space database(s) given its current location and in which regulatory > > domain that it is operating. The white space database discovery is > > the preliminary step that a white space master device has to > perform. > > URL: > http://www.ietf.org/internet-drafts/draft-probasco-paws-discovery-00.txt > > Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-00 > > Kind Regards, > > Scott & Raj > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From andy.sago@bt.com Wed Jul 11 23:28:53 2012 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 18DCF21F8702 for ; Wed, 11 Jul 2012 23:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 nvGH9UJukYRh for ; Wed, 11 Jul 2012 23:28:51 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFDA21F8701 for ; Wed, 11 Jul 2012 23:28:51 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 12 Jul 2012 07:29:23 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.29]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 12 Jul 2012 07:29:22 +0100 From: To: Date: Thu, 12 Jul 2012 07:29:19 +0100 Thread-Topic: [paws] draft document for Discovery Thread-Index: Ac1frvJEhji+zkKhSTOISpwfViYWOgASDzTw Message-ID: <619CDADDCCD2B44380834BE8BF6F714140A8FD880C@EMV62-UKRD.domain1.systemhost.net> References: <14FA0A69-0245-4297-9B0A-FDD71AC6B87D@neustar.biz> <619CDADDCCD2B44380834BE8BF6F714140A8FD87D6@EMV62-UKRD.domain1.systemhost.net> <4FFDF49B.8040307@joelhalpern.com> In-Reply-To: <4FFDF49B.8040307@joelhalpern.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] draft document for Discovery 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, 12 Jul 2012 06:28:53 -0000 Joel >From a regulatory perspective, yes the device can call its vendor or call a= friend (another WSD say) first, as long as nothing happens over the TVWS c= hannel until the regulator's listing has been checked. Regards Andy -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: 11 July 2012 22:48 To: Sago,AJ,Andy,COD R Cc: scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] draft document for Discovery It is pretty clear, and reasonable, that different domains are going to hav= e different discovery rules. (I wish that regulators operating by defining= their goals. There are other ways to achieve what ofcom wants.=20 But that is a different rant.) The simplest answer from a protocol perspective seems to be to allow a prov= isioned starting point, and a recursion mechanism. Then it doesn't matter = how many hops different domains require. Is it acceptable, in ofcom-like environments, for the device to call its ve= ndor, in order to determine who to call next? (It is easy enough to design= the referral to allow multiple stages of referral, as long as the regulati= ons don't require that the master device must check with the regulator befo= re checking with anyone else.) Yours, Joel On 7/11/2012 5:21 PM, andy.sago@bt.com wrote: > All > > Just to highlight that Ofcom requires that the list of available=20 > databases (maintained by Ofcom) is consulted once every 24 hours (so=20 > that misbehaving database operators can be removed from the list and=20 > devices stop using their channel allocations). Ofcom doesn't permit a=20 > master device to have a pre-arrangement with a database (such as a=20 > pre-programmed URI), or at least, the validity of any pre-programmed=20 > URI has to be checked every 24 hours with Ofcom's listing. The=20 > discovery problem is similar to US, but two step through an intermediate = listing. > > Regards > > Andy > > *From:*paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf=20 > Of *scott.probasco@nokia.com > *Sent:* 10 July 2012 22:44 > *To:* paws@ietf.org > *Subject:* Re: [paws] draft document for Discovery > > Hi All, > > It is simple. Vendors could support it forever. And if for example the=20 > roaming agreement becomes a preferred solution, the vendor could=20 > program one or more addresses into the device (SW update, device=20 > management, etc). In the use case & requirements document the=20 > assumption has been that a simple case of discovery is hard-coded address= es in the device. > > Best Regards, > > Scott > > *From: *"ext Rosen, Brian" > > *Date: *Tue, 10 Jul 2012 17:17:46 -0400 > *To: *"ext com>" > > *Cc: *Scott Probasco >, "paws@ietf.org=20 > " > > *Subject: *Re: [paws] draft document for Discovery > > That would work. > > This would happen every time the device booted. That could be a fair > amount of traffic for a high volume manufacturer. They have to support > this forever. > > It's simple. > > I wonder if the device mfg would agree to that? > > Brian > > On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote: > > > > on this topic a completely different approach would be for the device=20 > to call home, to the manufacturer, with the ability for the=20 > manufacturer to point it to the appropriate DB for that location. This=20 > works well, and simply if we assume the device has the relationship=20 > with the DB. If it is a user (Say network operator) then I would=20 > expect them to configure their devices to go where they desire them to go= . > > On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: > > When I do the discovery, I don't know which country I am in. I > can't know enough to query the right DS unless we put country > boundary polygons in the device. > > Of course, I forgot to add to this that if there is the U.S. model > of competing DBs, then the whole discovery mechanism falls apart, > and you need configuration, because if the device knows who its > business relationship is with, it can know the URI. > > Brian > > On Jul 10, 2012, at 3:38 PM, > > wrote: > > > > Hi Brian, > > Comments below: MSP-> > > Kind Regards, > > Scott > > *From: *"ext Rosen, Brian" > > *Date: *Mon, 9 Jul 2012 17:27:31 -0400 > *To: *Scott Probasco > > *Cc: *"paws@ietf.org " > > *Subject: *Re: [paws] draft document for Discovery > > This re-invents LoST without the extensive mechanisms for self > organizing databases. > > LoST has a query that sends location in, with a Service URN (which > for this use would be "I want a WSDB for this location" and you get > back (a list of) URIs. > > That's what you propose, without the service URN because you want a > special location based discovery mechanism just for WSDBs. > > What you don't deal with is how a WSDB DS finds out about all other > WSDB DSs. That's the LoST "Forest Guide". The FG works without a > root, and allows cooperating LoST servers to refer queries to the > right server. > > MSP->If each WSD vendor arranges a service level agreement with a > WSDB DS (or provides their own WSDB DS) then it is not obvious to me > why a WSDB DS would need to find out about other WSDB DSs. Each WSDB > DS is independent. If vendor X intends their WSD to operate in > Country Y, then WSDB DS used by vendor X must include appropriate > Country Y mapping information (location to WSDB or WSDB listing > server) in their WSDB DS. > > It's not really a great idea to bake a URI into a device. Who knows > what will happen over the life of a device? > > MSP->Including an address in the device does not imply that the > address cannot be changed if needed. SW updates, device management > or similar can allow for changes if needed. I take your point, these > changes should be exceptions rather than regular events. > > The existing LoST discovery mechanism is built for widespread > deployment in ISPs. We may need something that works well without > that. There aren't a lot of good mechanisms that really work well - > you either have a root of some sort, or, as you propose, a starting > seed. The root problem is who runs the root, and the starting seed > problem is the lifetime of the seed. You note that the seed gets > nothing out of the exchange - it doesn't get to serve the query, it > only gets to refer to someone who does. > > MSP->It is not clear to me what business model would support a > sophisticated infrastructure as described in the LoST Architecture & > Framework RFC 5582. > > I actually think this is not an important problem to solve really > well. The most common deployment model is going to be a tower and > clients. The tower can be configured, and either the clients learn > from the tower, or the tower handles the database query itself. > Client discovery in that case could be the LoST discovery mechanism= . > > We have to handle the self organizing case (say a MANET) where one > or more devices have some other path to the Internet to get to the > WSDB. They will need real discovery and may not have a cooperating > ISP. While I really don't like configuration, it may be the only > viable way to do it. > > MSP->Configuration is pragmatic and can be easily deployed > > Brian > > On Jul 9, 2012, at 5:04 PM, > wrote: > > > > Hello All, > > Please find a link below to a draft submission for the Discovery > process as described in the Use Cases & Requirements document. We > are looking forward to your review and comments as well as > discussion at IETF#84. > > Abstract: > > A white space master device needs to query a white space > database and > > obtain information about available spectrum/channels prior to > > operation. White space databases which contain information=20 > about > > available spectrum/channels are associated with a regulatory doma= in. > > A white space master device needs to discover the relevant=20 > white > > space database(s) given its current location and in which=20 > regulatory > > domain that it is operating. The white space database=20 > discovery is > > the preliminary step that a white space master device has to > perform. > > URL: > =20 > http://www.ietf.org/internet-drafts/draft-probasco-paws-discovery-00.t > xt > > Htmlized:=20 > http://tools.ietf.org/html/draft-probasco-paws-discovery-00 > > Kind Regards, > > Scott & Raj > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From ben@blindcreek.com Thu Jul 12 12:23:46 2012 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 66DA011E80CD for ; Thu, 12 Jul 2012 12:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 7XU4abxi11PR for ; Thu, 12 Jul 2012 12:23:43 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 4460611E809B for ; Thu, 12 Jul 2012 12:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=T/+jN63akEp/+jj8JTofw3lncas4BDiJEEyY+O8yVzs=; b=J3dXKQwOM0lM01xfyY0Xvx8TbeniJcFZvImz9c7UbuYU8xZij14ApH4r/zS447ny+0uXw6+4VakpJ9sT0T+lgkD/UmOyCwyflc+cj1nmEECokTIgjDN0KqWNPz0tXC42; Received: from c-50-136-165-25.hsd1.ca.comcast.net ([50.136.165.25]:64180 helo=[192.168.1.112]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1SpOzl-0005hr-JY for paws@ietf.org; Thu, 12 Jul 2012 14:24:14 -0500 Message-ID: <4FFF245F.60609@blindcreek.com> Date: Thu, 12 Jul 2012 12:24:15 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <14FA0A69-0245-4297-9B0A-FDD71AC6B87D@neustar.biz> <619CDADDCCD2B44380834BE8BF6F714140A8FD87D6@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140A8FD87D6@EMV62-UKRD.domain1.systemhost.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] draft document for Discovery 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, 12 Jul 2012 19:23:46 -0000 Thanks Andy,
So in this case the is it expected the device knows the URI for Ofcom's list and should start there?
-Ben

All

 

Just to highlight that Ofcom requires that the list of available databases (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving database operators can be removed from the list and devices stop using their channel allocations). Ofcom doesn’t permit a master device to have a pre-arrangement with a database (such as a pre-programmed URI), or at least, the validity of any pre-programmed URI has to be checked every 24 hours with Ofcom’s listing. The discovery problem is similar to US, but two step through an intermediate listing.

 

Regards

 

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: 10 July 2012 22:44
To: paws@ietf.org
Subject: Re: [paws] draft document for Discovery

 

Hi All,

 

It is simple. Vendors could support it forever. And if for example the roaming agreement becomes a preferred solution, the vendor could program one or more addresses into the device (SW update, device management, etc). In the use case & requirements document the assumption has been that a simple case of discovery is hard-coded addresses in the device.

 

Best Regards,

Scott

 

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Tue, 10 Jul 2012 17:17:46 -0400
To: "ext com>" <peter@spectrumbridge.com>
Cc: Scott Probasco <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

 

That would work.

 

This would happen every time the device booted.  That could be a fair amount of traffic for a high volume manufacturer.   They have to support this forever.

 

It's simple.

 

I wonder if the device mfg would agree to that?

 

Brian

 

On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote:



on this topic a completely different approach would be for the device to call home, to the manufacturer, with the ability for the manufacturer to point it to the appropriate DB for that location. This works well, and simply if we assume the device has the relationship with the DB. If it is a user (Say network operator) then I would expect them to configure their devices to go where they desire them to go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

When I do the discovery, I don't know which country I am in.  I can't know enough to query the right DS unless we put country boundary polygons in the device.

 

Of course, I forgot to add to this that if there is the U.S. model of competing DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is with, it can know the URI.

 

Brian

 

 

On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:



Hi Brian,

 

Comments below: MSP->

 

Kind Regards,

Scott

 

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Mon, 9 Jul 2012 17:27:31 -0400
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

 

This re-invents LoST without the extensive mechanisms for self organizing databases.

LoST has a query that sends location in, with a Service URN (which for this use would be "I want a WSDB for this location" and you get back (a list of) URIs.  

 

That's what you propose, without the service URN because you want a special location based discovery mechanism just for WSDBs.

 

What you don't deal with is how a WSDB DS finds out about all other WSDB DSs.  That's the LoST "Forest Guide".  The FG works without a root, and allows cooperating LoST servers to  refer queries to the right server.

MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (or provides their own WSDB DS) then it is not obvious to me why a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is independent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include appropriate Country Y mapping information (location to WSDB or WSDB listing server) in their WSDB DS.

 

It's not really a great idea to bake a URI into a device.  Who knows what will happen over the life of a device?

MSP->Including an address in the device does not imply that the address cannot be changed if needed. SW updates, device management or similar can allow for changes if needed. I take your point, these changes should be exceptions rather than regular events.

 

The existing LoST discovery mechanism is built for widespread deployment in ISPs.   We may need something that works well without that.  There aren't a lot of good mechanisms that really work well - you either have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the starting seed problem is the lifetime of the seed.  You note that the seed gets nothing out of the exchange - it doesn't get to serve the query, it only gets to refer to someone who does.  

MSP->It is not clear to me what business model would support a sophisticated infrastructure as described in the LoST Architecture & Framework RFC 5582.

 

I actually think this is not an important problem to solve really well.  The most common deployment model is going to be a tower and clients.  The tower can be configured, and either the clients learn from the tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery mechanism.

 

We have to handle the self organizing case (say a MANET) where one or more devices have some other path to the Internet to get to the WSDB.  They will need real discovery and may not have a cooperating ISP.  While I really don't like configuration, it may be the only viable way to do it.

MSP->Configuration is pragmatic and can be easily deployed

 

Brian

 

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:



Hello All,

 

Please find a link below to a draft submission for the Discovery process as described in the Use Cases & Requirements document. We are looking forward to your review and comments as well as discussion at IETF#84.

 

Abstract:

   A white space master device needs to query a white space database and

   obtain information about available spectrum/channels prior to

   operation.  White space databases which contain information about

   available spectrum/channels are associated with a regulatory domain.

   A white space master device needs to discover the relevant white

   space database(s) given its current location and in which regulatory

   domain that it is operating.  The white space database discovery is

   the preliminary step that a white space master device has to perform.

 

 

 

Kind Regards,

Scott & Raj

 

 

 

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

 

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

 

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

 


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

From scott.probasco@nokia.com Thu Jul 12 12:27:03 2012 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 1996211E80E9 for ; Thu, 12 Jul 2012 12:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 PhnXi+P8-DU5 for ; Thu, 12 Jul 2012 12:27:01 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 066D411E80EF for ; Thu, 12 Jul 2012 12:26:55 -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 q6CJRNQP001958 for ; Thu, 12 Jul 2012 22:27:24 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jul 2012 22:27:49 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Thu, 12 Jul 2012 21:27:22 +0200 From: To: Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsam1igeb9LkGV+JKNCiTfyJcibuGAgAAGioCAAFdFAIAAFjWAgAACRwD//7NSgIAB/r4ggAFS4oD//60SAA== Date: Thu, 12 Jul 2012 19:27:21 +0000 Message-ID: In-Reply-To: <4FFF245F.60609@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [172.19.40.91] Content-Type: multipart/alternative; boundary="_000_CC248ECDDCFFscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2012 19:27:49.0521 (UTC) FILETIME=[6C65A810:01CD6064] X-Nokia-AV: Clean Subject: Re: [paws] draft document for Discovery 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, 12 Jul 2012 19:27:03 -0000 --_000_CC248ECDDCFFscottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ben, If the WSD will never have the possibility to be turned on outside the UK, = this could work. But about the case where the device is carried to another = regulatory domain somewhere in the world? Discovery is needed for this case= ; to find an authorized database no matter where the device is when turned = on (assuming white space is authorized in the country where the device is t= urned on). Kind Regards, Scott From: "ext Benjamin A. Rolfe" > Date: Thu, 12 Jul 2012 12:24:15 -0700 To: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery Thanks Andy, So in this case the is it expected the device knows the URI for Ofcom's lis= t and should start there? -Ben All Just to highlight that Ofcom requires that the list of available databases = (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving= database operators can be removed from the list and devices stop using the= ir channel allocations). Ofcom doesn=92t permit a master device to have a p= re-arrangement with a database (such as a pre-programmed URI), or at least,= the validity of any pre-programmed URI has to be checked every 24 hours wi= th Ofcom=92s listing. The discovery problem is similar to US, but two step = through an intermediate listing. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: 10 July 2012 22:44 To: paws@ietf.org Subject: Re: [paws] draft document for Discovery Hi All, It is simple. Vendors could support it forever. And if for example the roam= ing agreement becomes a preferred solution, the vendor could program one or= more addresses into the device (SW update, device management, etc). In the= use case & requirements document the assumption has been that a simple cas= e of discovery is hard-coded addresses in the device. Best Regards, Scott From: "ext Rosen, Brian" > Date: Tue, 10 Jul 2012 17:17:46 -0400 To: "ext com>" > Cc: Scott Probasco >, "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery That would work. This would happen every time the device booted. That could be a fair amoun= t of traffic for a high volume manufacturer. They have to support this fo= rever. It's simple. I wonder if the device mfg would agree to that? Brian On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote: on this topic a completely different approach would be for the device to ca= ll home, to the manufacturer, with the ability for the manufacturer to poin= t it to the appropriate DB for that location. This works well, and simply i= f we assume the device has the relationship with the DB. If it is a user (S= ay network operator) then I would expect them to configure their devices to= go where they desire them to go. On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.orghttps://www.ietf.org/mailman/listinfo/pa= ws _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CC248ECDDCFFscottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0961E54306AE1C4BA919C428760C80F7@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi Ben,

If the WSD will never have the possibility to be turned on outside the= UK, this could work. But about the case where the device is carried to ano= ther regulatory domain somewhere in the world? Discovery is needed for this= case; to find an authorized database no matter where the device is when turned on (assuming white space is auth= orized in the country where the device is turned on).

Kind Regards,
Scott

From: "ext Benjamin A. Rolfe&q= uot; <ben@blindcreek.com> Date: Thu, 12 Jul 2012 12:24:15 -07= 00
To: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] draft document = for Discovery

Thanks Andy,
So in this case the is it expected the device knows the URI for Ofcom's lis= t and should start there?
-Ben

All

 

Just to highlight that Ofcom requires that the list= of available databases (maintained by Ofcom) is consulted once every 24 ho= urs (so that misbehaving database operators can be removed from the list and devices stop using their channel allocati= ons). Ofcom doesn=92t permit a master device to have a pre-arrangement with= a database (such as a pre-programmed URI), or at least, the validity of an= y pre-programmed URI has to be checked every 24 hours with Ofcom=92s listing. The discovery problem is similar to= US, but two step through an intermediate listing.

 

Regards

 

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: 10 July 2012 22:44
To: paws@ietf.org
Subject: Re: [paws] draft document for Discovery

 

Hi All,

 

It is simple. Vendors could support it fore= ver. And if for example the roaming agreement becomes a preferred solution,= the vendor could program one or more addresses into the device (SW update, device management, etc). In the use = case & requirements document the assumption has been that a simple case= of discovery is hard-coded addresses in the device.

 

Best Regards,

Scott

 

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>=
Date: Tue, 10 Jul 2012 17:17:46 -0400
To: "ext com>" <peter@spectrumbridge.com>
Cc: Scott Probasco <scott.probasco@nokia.com>, "paws@ietf.org" <= paws@ietf.org= >
Subject: Re: [paws] draft document for Discovery

 

That would work.

 

This would happen every time the device boo= ted.  That could be a fair amount of traffic for a high volume manufac= turer.   They have to support this forever.

 

It's simple.

 

I wonder if the device mfg would agree to t= hat?

 

Brian

 

On Jul 10, 2012, at 5:09 PM, Peter Stanfort= h wrote:



on this topi= c a completely different approach would be for the device to call home, to = the manufacturer, with the ability for the manufacturer to point it to the appropriate DB for that location. This= works well, and simply if we assume the device has the relationship with t= he DB. If it is a user (Say network operator) then I would expect them to c= onfigure their devices to go where they desire them to go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz<= /a>> wrote:

When I do the discovery, I don't know which= country I am in.  I can't know enough to query the right DS unless we= put country boundary polygons in the device.

 

Of course, I forgot to add to this that if = there is the U.S. model of competing DBs, then the whole discovery mechanis= m falls apart, and you need configuration, because if the device knows who its business relationship is with, it can = know the URI.

 

Brian

 

 



Hi Brian,

 

Comments below: MSP-><= /p>

 

Kind Regards,

Scott

 

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>=
Date: Mon, 9 Jul 2012 17:27:31 -0400
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "= paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

 

This re-invents LoST without the extensive = mechanisms for self organizing databases.

LoST has a query that sends location in, wi= th a Service URN (which for this use would be "I want a WSDB for this = location" and you get back (a list of) URIs.  

 

That's what you propose, without the servic= e URN because you want a special location based discovery mechanism just fo= r WSDBs.

 

What you don't deal with is how a WSDB DS f= inds out about all other WSDB DSs.  That's the LoST "Forest Guide= ".  The FG works without a root, and allows cooperating LoST servers to  refer queries to the right server.=

MSP->If each WSD vendor arranges a servi= ce level agreement with a WSDB DS (or provides their own WSDB DS) then= it is not obvious to me why a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is independent. If ven= dor X intends their WSD to operate in Country Y, then WSDB DS used by vendo= r X must include appropriate Country Y mapping information (location to WSD= B or WSDB listing server) in their WSDB DS.

 

It's not really a great idea to bake a URI = into a device.  Who knows what will happen over the life of a device?<= o:p>

MSP->Including an address in the device = does not imply that the address cannot be changed if needed. SW updates, de= vice management or similar can allow for changes if needed. I take your point, these changes should be exceptions r= ather than regular events.

 

The existing LoST discovery mechanism is bu= ilt for widespread deployment in ISPs.   We may need something that wo= rks well without that.  There aren't a lot of good mechanisms that really work well - you either have a root of some = sort, or, as you propose, a starting seed.  The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. &nb= sp;You note that the seed gets nothing out of the exchange - it doesn't get to serve the query, it only gets to refer= to someone who does.  

MSP->It is not clear to me what business= model would support a sophisticated infrastructure as described in the LoS= T Architecture & Framework RFC 5582.

 

I actually think this is not an important p= roblem to solve really well.  The most common deployment model is goin= g to be a tower and clients.  The tower can be configured, and either the clients learn from the tower, or the tower h= andles the database query itself.  Client discovery in that case could= be the LoST discovery mechanism.

 

We have to handle the self organizing case = (say a MANET) where one or more devices have some other path to the Interne= t to get to the WSDB.  They will need real discovery and may not have a cooperating ISP.  While I really do= n't like configuration, it may be the only viable way to do it.<= /span>

MSP->Configuration is pragmatic and can = be easily deployed

 

Brian

 

On Jul 9, 2012, at 5:04 PM, <scott.probasco@no= kia.com> wrote:



Hello All,

 

Please find a link below to a draft submiss= ion for the Discovery process as described in the Use Cases & Requireme= nts document. We are looking forward to your review and comments as well as discussion at IETF#84.

 

Abstract:

   A white space master device ne= eds to query a white space database and

   obtain information about avail= able spectrum/channels prior to

   operation.  White sp= ace databases which contain information about

   available spectrum/channels ar= e associated with a regulatory domain.

   A white space master device ne= eds to discover the relevant white

   space database(s) given its cu= rrent location and in which regulatory

   domain that it is operating.&n= bsp; The white space database discovery is

   the preliminary step that a wh= ite space master device has to perform.

 

 

 =

Kind Regards,

Scott & Raj

 

 

 

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

 

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

 

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

 


_______________________________________________
paws mailing list
paws@ie=
tf.orghttps://www.ietf.org/mailman/listinfo/paws

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CC248ECDDCFFscottprobasconokiacom_-- From ben@blindcreek.com Thu Jul 12 12:55:56 2012 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 939CA21F86A7 for ; Thu, 12 Jul 2012 12:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 Vxk-evON5QTK for ; Thu, 12 Jul 2012 12:55:55 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id A078221F8611 for ; Thu, 12 Jul 2012 12:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=LHIfNaK/exFr9SebBTlD1trfk0KztDihRjIhqwmbC90=; b=S/NiL9YJa574IhxW2KXflzg7MVFWhrbx4JAV4U3QhSUl583fopXrGi55+oEc6Hp04zS/EuMXpwoj4CW5Yv4QGcZHJOoWnY5WnCnRc+7c+kPiKKBGMkMjFhZDeMJPRrmz; Received: from c-50-136-165-25.hsd1.ca.comcast.net ([50.136.165.25]:64251 helo=[192.168.1.112]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1SpPUu-0002tj-He for paws@ietf.org; Thu, 12 Jul 2012 14:56:26 -0500 Message-ID: <4FFF2BE9.7060906@blindcreek.com> Date: Thu, 12 Jul 2012 12:56:25 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: In-Reply-To: Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] draft document for Discovery 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, 12 Jul 2012 19:55:56 -0000 Thanks Scott,
Yes, there is an presumption that the WSD knows where it is located on earth.  It has to know this to make a database request of course.  What we're looking for then is a global means to determine what the initial contact needs to be depending on location.  It seems like the steps necessary to find a database may be different region by region. That should make it fun!

-Ben


Hi Ben,

If the WSD will never have the possibility to be turned on outside the UK, this could work. But about the case where the device is carried to another regulatory domain somewhere in the world? Discovery is needed for this case; to find an authorized database no matter where the device is when turned on (assuming white space is authorized in the country where the device is turned on).

Kind Regards,
Scott

From: "ext Benjamin A. Rolfe" <ben@blindcreek.com>
Date: Thu, 12 Jul 2012 12:24:15 -0700
To: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

Thanks Andy,
So in this case the is it expected the device knows the URI for Ofcom's list and should start there?
-Ben

All

 

Just to highlight that Ofcom requires that the list of available databases (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving database operators can be removed from the list and devices stop using their channel allocations). Ofcom doesn’t permit a master device to have a pre-arrangement with a database (such as a pre-programmed URI), or at least, the validity of any pre-programmed URI has to be checked every 24 hours with Ofcom’s listing. The discovery problem is similar to US, but two step through an intermediate listing.

 

Regards

 

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: 10 July 2012 22:44
To: paws@ietf.org
Subject: Re: [paws] draft document for Discovery

 

Hi All,

 

It is simple. Vendors could support it forever. And if for example the roaming agreement becomes a preferred solution, the vendor could program one or more addresses into the device (SW update, device management, etc). In the use case & requirements document the assumption has been that a simple case of discovery is hard-coded addresses in the device.

 

Best Regards,

Scott

 

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Tue, 10 Jul 2012 17:17:46 -0400
To: "ext com>" <peter@spectrumbridge.com>
Cc: Scott Probasco <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

 

That would work.

 

This would happen every time the device booted.  That could be a fair amount of traffic for a high volume manufacturer.   They have to support this forever.

 

It's simple.

 

I wonder if the device mfg would agree to that?

 

Brian

 

On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote:



on this topic a completely different approach would be for the device to call home, to the manufacturer, with the ability for the manufacturer to point it to the appropriate DB for that location. This works well, and simply if we assume the device has the relationship with the DB. If it is a user (Say network operator) then I would expect them to configure their devices to go where they desire them to go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

When I do the discovery, I don't know which country I am in.  I can't know enough to query the right DS unless we put country boundary polygons in the device.

 

Of course, I forgot to add to this that if there is the U.S. model of competing DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is with, it can know the URI.

 

Brian

 

 

On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <scott.probasco@nokia.com> wrote:



Hi Brian,

 

Comments below: MSP->

 

Kind Regards,

Scott

 

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Mon, 9 Jul 2012 17:27:31 -0400
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

 

This re-invents LoST without the extensive mechanisms for self organizing databases.

LoST has a query that sends location in, with a Service URN (which for this use would be "I want a WSDB for this location" and you get back (a list of) URIs.  

 

That's what you propose, without the service URN because you want a special location based discovery mechanism just for WSDBs.

 

What you don't deal with is how a WSDB DS finds out about all other WSDB DSs.  That's the LoST "Forest Guide".  The FG works without a root, and allows cooperating LoST servers to  refer queries to the right server.

MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (or provides their own WSDB DS) then it is not obvious to me why a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is independent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include appropriate Country Y mapping information (location to WSDB or WSDB listing server) in their WSDB DS.

 

It's not really a great idea to bake a URI into a device.  Who knows what will happen over the life of a device?

MSP->Including an address in the device does not imply that the address cannot be changed if needed. SW updates, device management or similar can allow for changes if needed. I take your point, these changes should be exceptions rather than regular events.

 

The existing LoST discovery mechanism is built for widespread deployment in ISPs.   We may need something that works well without that.  There aren't a lot of good mechanisms that really work well - you either have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the starting seed problem is the lifetime of the seed.  You note that the seed gets nothing out of the exchange - it doesn't get to serve the query, it only gets to refer to someone who does.  

MSP->It is not clear to me what business model would support a sophisticated infrastructure as described in the LoST Architecture & Framework RFC 5582.

 

I actually think this is not an important problem to solve really well.  The most common deployment model is going to be a tower and clients.  The tower can be configured, and either the clients learn from the tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery mechanism.

 

We have to handle the self organizing case (say a MANET) where one or more devices have some other path to the Internet to get to the WSDB.  They will need real discovery and may not have a cooperating ISP.  While I really don't like configuration, it may be the only viable way to do it.

MSP->Configuration is pragmatic and can be easily deployed

 

Brian

 

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrote:



Hello All,

 

Please find a link below to a draft submission for the Discovery process as described in the Use Cases & Requirements document. We are looking forward to your review and comments as well as discussion at IETF#84.

 

Abstract:

   A white space master device needs to query a white space database and

   obtain information about available spectrum/channels prior to

   operation.  White space databases which contain information about

   available spectrum/channels are associated with a regulatory domain.

   A white space master device needs to discover the relevant white

   space database(s) given its current location and in which regulatory

   domain that it is operating.  The white space database discovery is

   the preliminary step that a white space master device has to perform.

 

 

 

Kind Regards,

Scott & Raj

 

 

 

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

 

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

 

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

 


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

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

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

From SiewYoon.Tan@ofcom.org.uk Thu Jul 12 13:02:18 2012 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 98CF421F86EB for ; Thu, 12 Jul 2012 13:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf9RjsNn5fTv for ; Thu, 12 Jul 2012 13:02:12 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1481921F8611 for ; Thu, 12 Jul 2012 13:02:11 -0700 (PDT) Received: from [85.158.143.35:43433] by server-3.bemta-4.messagelabs.com id F2/7B-05808-56D2FFF4; Thu, 12 Jul 2012 20:02:45 +0000 X-Env-Sender: SiewYoon.Tan@ofcom.org.uk X-Msg-Ref: server-2.tower-21.messagelabs.com!1342123364!5388613!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31710 invoked from network); 12 Jul 2012 20:02:44 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-2.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jul 2012 20:02:44 -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; Thu, 12 Jul 2012 21:02:44 +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; Thu, 12 Jul 2012 21:02:40 +0100 From: Siew Yoon Tan To: "Benjamin A. Rolfe" , "paws@ietf.org" Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNXhmsyrw5iFI/q0OpvWK1evuW3JcibuGAgAAGioCAAGgIAIAAFjWAgAACRwCAAAc9AIABjDeAgAFxf4CAABflsA== Date: Thu, 12 Jul 2012 20:02:38 +0000 Message-ID: References: <14FA0A69-0245-4297-9B0A-FDD71AC6B87D@neustar.biz> <619CDADDCCD2B44380834BE8BF6F714140A8FD87D6@EMV62-UKRD.domain1.systemhost.net> <4FFF245F.60609@blindcreek.com> In-Reply-To: <4FFF245F.60609@blindcreek.com> 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_C08077EB39F9304D8629FF0B0FF9FB16845B8698WOKINTRAEXC02in_" MIME-Version: 1.0 Subject: Re: [paws] draft document for Discovery 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, 12 Jul 2012 20:02:18 -0000 --_000_C08077EB39F9304D8629FF0B0FF9FB16845B8698WOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Just to clarify that Ofcom will include the URI for the list of approved da= tabase as part of our regulations, so that this could be 'discovered' by WS= Ds. We are agnostic on how this discovery mechanism would be implemented in= the WSD; either pre-programmed or through DNS server. However, it's a prerequisite that the validity of the database that WSD wis= h to connect to would have to be checked by WSD every 24 hours through con= nection to Ofcom listing to confirm that it's still approved. Hope this helps the discussion. Best regards, Siew Yoon :: Siew Yoon Tan Technical Regulation Specialist Spectrum Policy Group Direct : +44 (0) 20 7981 3066 Mobile : +44 (0) 78 1132 6573 siewyoon.tan@ofcom.org.uk :: Ofcom Riverside House 2a Southwark Bridge Road London SE1 9HA 020 7981 3000 www.ofcom.org.uk From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ben= jamin A. Rolfe Sent: 12 July 2012 20:24 To: paws@ietf.org Subject: Re: [paws] draft document for Discovery Thanks Andy, So in this case the is it expected the device knows the URI for Ofcom's lis= t and should start there? -Ben All Just to highlight that Ofcom requires that the list of available databases = (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving= database operators can be removed from the list and devices stop using the= ir channel allocations). Ofcom doesn't permit a master device to have a pre= -arrangement with a database (such as a pre-programmed URI), or at least, t= he validity of any pre-programmed URI has to be checked every 24 hours with= Ofcom's listing. The discovery problem is similar to US, but two step thro= ugh an intermediate listing. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: 10 July 2012 22:44 To: paws@ietf.org Subject: Re: [paws] draft document for Discovery Hi All, It is simple. Vendors could support it forever. And if for example the roam= ing agreement becomes a preferred solution, the vendor could program one or= more addresses into the device (SW update, device management, etc). In the= use case & requirements document the assumption has been that a simple cas= e of discovery is hard-coded addresses in the device. Best Regards, Scott From: "ext Rosen, Brian" > Date: Tue, 10 Jul 2012 17:17:46 -0400 To: "ext com>" > Cc: Scott Probasco >, "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery That would work. This would happen every time the device booted. That could be a fair amoun= t of traffic for a high volume manufacturer. They have to support this fo= rever. It's simple. I wonder if the device mfg would agree to that? Brian On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote: on this topic a completely different approach would be for the device to ca= ll home, to the manufacturer, with the ability for the manufacturer to poin= t it to the appropriate DB for that location. This works well, and simply i= f we assume the device has the relationship with the DB. If it is a user (S= ay network operator) then I would expect them to configure their devices to= go where they desire them to go. On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ________________________________ ***************************************************************************= *************************************** 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_C08077EB39F9304D8629FF0B0FF9FB16845B8698WOKINTRAEXC02in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Just to clarify that Of= com will include the URI for the list of approved database as part of our r= egulations, so that this could be ‘discovered’ by WSDs. We are agnostic on how this discovery mechanism would be implemented in th= e WSD; either pre-programmed or through DNS server.

 

However, it’s a p= rerequisite that the validity of the database that WSD wish to connect to w= ould have to be checked by WSD every 24 hours  through connection to Ofcom listing to confirm that it’s still approved.

 

Hope this helps the dis= cussion.

 

Best regards,

 

Siew Yoon

 

 

:: Siew Yoon Tan

   Technical= Regulation Specialist

   Spectrum Polic= y Group

   Direct : += 44 (0) 20 7981 3066

   Mobile : += 44 (0) 78 1132 6573

   = siewyoon.tan@ofcom.org.uk

 

:: Ofcom

   Riverside Hous= e

   2a Southwark B= ridge Road

   London SE1 9HA=

   020 7981 3000<= /span>

   www.ofcom.org.u= k

 

 

 

 

 

Fro= m: paws-bounces@ie= tf.org [mailto:paws-bounces@ietf.org] On Behalf Of Benjamin A. Rolfe
Sent: 12 July 2012 20:24
To: paws@ietf.org
Subject: Re: [paws] draft document for Discovery

 

Thanks Andy,
So in this case the is it expected the device knows the URI for Ofcom's lis= t and should start there?
-Ben


All

 

Just to highlight that Ofcom requires that the list of a= vailable databases (maintained by Ofcom) is consulted once every 24 hours (= so that misbehaving database operators can be removed from the list and devices stop using their channel allocations). Ofcom doesn= 217;t permit a master device to have a pre-arrangement with a database (suc= h as a pre-programmed URI), or at least, the validity of any pre-programmed= URI has to be checked every 24 hours with Ofcom’s listing. The discovery problem is similar to US, but tw= o step through an intermediate listing.

 

Regards

 

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.proba= sco@nokia.com
Sent: 10 July 2012 22:44
To: paws@ietf.org
Subject: Re: [paws] draft document for Discovery

 

Hi All,

 

It is simple. Vendors could support it= forever. And if for example the roaming agreement becomes a preferred solu= tion, the vendor could program one or more addresses into the device (SW update, device management, etc). In the use case & requ= irements document the assumption has been that a simple case of discovery i= s hard-coded addresses in the device.

 

Best Regards,

Scott

 

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Tue, 10 Jul 2012 17:17:46 -0400
To: "ext com>" <peter@spectrumbridge.com>
Cc: Scott Probasco <s= cott.probasco@nokia.com>, "paw= s@ietf.org" <paws@ietf.org= >
Subject: Re: [paws] draft document for Discovery

 

That would work.

 

This would happen every time the devic= e booted.  That could be a fair amount of traffic for a high volume ma= nufacturer.   They have to support this forever.

 

It's simple.

 

I wonder if the device mfg would agree= to that?

 

Brian

 

On Jul 10, 2012, at 5:09 PM, Peter Sta= nforth wrote:




on this= topic a completely different approach would be for the device to call home= , to the manufacturer, with the ability for the manufacturer to point it to the appropriate DB for that location. This works well, and = simply if we assume the device has the relationship with the DB. If it is a= user (Say network operator) then I would expect them to configure their de= vices to go where they desire them to go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

When I do the discovery, I don't know = which country I am in.  I can't know enough to query the right DS unle= ss we put country boundary polygons in the device.

 

Of course, I forgot to add to this tha= t if there is the U.S. model of competing DBs, then the whole discovery mec= hanism falls apart, and you need configuration, because if the device knows who its business relationship is with, it can know the= URI.

 

Brian

 

 

On Jul 10, 2012, at 3:38 PM, <scott.probasco@nokia.com> <= ;scott.probasco@nokia.com&g= t; wrote:




Hi Brian,

 

Comments below: MSP->

 

Kind Regards,

Scott

 

From: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Mon, 9 Jul 2012 17:27:31 -0400
To: Scott Probasco <s= cott.probasco@nokia.com>
Cc: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

 

This re-invents LoST without the exten= sive mechanisms for self organizing databases.

LoST has a query that sends location i= n, with a Service URN (which for this use would be "I want a WSDB for = this location" and you get back (a list of) URIs.  

 

That's what you propose, without the s= ervice URN because you want a special location based discovery mechanism ju= st for WSDBs.

 

What you don't deal with is how a WSDB= DS finds out about all other WSDB DSs.  That's the LoST "Forest = Guide".  The FG works without a root, and allows cooperating LoST servers to  refer queries to the right server.

MSP->If each WSD vendor arranges a = service level agreement with a WSDB DS (or provides their own WSDB DS)= then it is not obvious to me why a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is independent. If vendor X intends the= ir WSD to operate in Country Y, then WSDB DS used by vendor X must include = appropriate Country Y mapping information (location to WSDB or WSDB listing= server) in their WSDB DS.

 

It's not really a great idea to bake a= URI into a device.  Who knows what will happen over the life of a dev= ice?

MSP->Including an address in the de= vice does not imply that the address cannot be changed if needed. SW update= s, device management or similar can allow for changes if needed. I take your point, these changes should be exceptions rather than regular = events.

 

The existing LoST discovery mechanism = is built for widespread deployment in ISPs.   We may need something th= at works well without that.  There aren't a lot of good mechanisms that really work well - you either have a root of some sort, or, as you pr= opose, a starting seed.  The root problem is who runs the root, and th= e starting seed problem is the lifetime of the seed.  You note that th= e seed gets nothing out of the exchange - it doesn't get to serve the query, it only gets to refer to someone who do= es.  

MSP->It is not clear to me what bus= iness model would support a sophisticated infrastructure as described in th= e LoST Architecture & Framework RFC 5582.

 

I actually think this is not an import= ant problem to solve really well.  The most common deployment model is= going to be a tower and clients.  The tower can be configured, and either the clients learn from the tower, or the tower handles the data= base query itself.  Client discovery in that case could be the LoST di= scovery mechanism.

 

We have to handle the self organizing = case (say a MANET) where one or more devices have some other path to the In= ternet to get to the WSDB.  They will need real discovery and may not have a cooperating ISP.  While I really don't like config= uration, it may be the only viable way to do it.

MSP->Configuration is pragmatic and= can be easily deployed

 

Brian

 

On Jul 9, 2012, at 5:04 PM, <scott.probasco@nokia.com> wrot= e:




Hello All,

 

Please find a link below to a draft su= bmission for the Discovery process as described in the Use Cases & Requ= irements document. We are looking forward to your review and comments as well as discussion at IETF#84.

 

Abstract:

   A white space master devi= ce needs to query a white space database and

   obtain information about = available spectrum/channels prior to

   operation.  Whi= te space databases which contain information about

   available spectrum/channe= ls are associated with a regulatory domain.

   A white space master devi= ce needs to discover the relevant white

   space database(s) given i= ts current location and in which regulatory

   domain that it is operati= ng.  The white space database discovery is

   the preliminary step that= a white space master device has to perform.

 

 

 

Kind Regards,

Scott & Raj

 

 

 

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

 

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

 

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

 

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

 



***************************************************************************= ***************************************
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_C08077EB39F9304D8629FF0B0FF9FB16845B8698WOKINTRAEXC02in_-- From brian.rosen@neustar.biz Thu Jul 12 13:03:07 2012 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 EFCD321F852C for ; Thu, 12 Jul 2012 13:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.409, 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 De7yeIw9FZBE for ; Thu, 12 Jul 2012 13:03:04 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id AAA6021F8454 for ; Thu, 12 Jul 2012 13:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1342123283; x=1657482981; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=7yq+C6OEgNKLrSQsid9c1DPHhzWwjM/GCY167mMPVLE=; b=N/Z4Ni6QgJqyhlmC3/uC+h6fZhnP5g03w3U4wLSuKi2AAo1rbyL3jz3Ijuwt3U zYQzaS9z8LZ3C862IUnFeJSA== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.7268610; Thu, 12 Jul 2012 16:01:21 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 12 Jul 2012 16:02:59 -0400 From: "Rosen, Brian" To: "Benjamin A. Rolfe" Date: Thu, 12 Jul 2012 16:02:58 -0400 Thread-Topic: [paws] draft document for Discovery Thread-Index: Ac1gaVW3O2hd/0gWRA2yT+vbRcwLGw== Message-ID: <8C3DB983-C20A-4DAD-A6C2-F21959B09B18@neustar.biz> References: <4FFF2BE9.7060906@blindcreek.com> In-Reply-To: <4FFF2BE9.7060906@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: JX0ZaWLhSrIWwUufyN4Cmw== Content-Type: multipart/alternative; boundary="_000_8C3DB983C20A4DADA6C2F21959B09B18neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft document for Discovery 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, 12 Jul 2012 20:03:07 -0000 X-List-Received-Date: Thu, 12 Jul 2012 20:03:07 -0000 --_000_8C3DB983C20A4DADA6C2F21959B09B18neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A device needs to know its own location. However, as Scott points out, without a list of polygons representing the b= oundaries of every country, and suitable code, a device doesn't know what c= ountry it is in. So, we need a mechanism that given an arbitrary lat/lon, leads you to the r= ight database. That in turn means there is some kind of server you go to first, and it lea= ds you to country specific information. You can't start at the OFCOM serve= r because first you have to determine you are in the U.K. So this is some form of query with location in the query, and at list one, = or possibly a list of URIs to go to. There may be a couple of steps - the = URI you get may lead you to a list of URIs. Each one is the same - you que= ry with location, you get one or more URIs. The original discovery server= may lead you to the Ofcom server which leads you to one or more actual dat= abases. At some point, you need some way to choose between more than one URI when y= ou get that. This was called "policy" before. Brian On Jul 12, 2012, at 3:56 PM, Benjamin A. Rolfe wrote: Thanks Scott, Yes, there is an presumption that the WSD knows where it is located on eart= h. It has to know this to make a database request of course. What we're l= ooking for then is a global means to determine what the initial contact nee= ds to be depending on location. It seems like the steps necessary to find = a database may be different region by region. That should make it fun! -Ben Hi Ben, If the WSD will never have the possibility to be turned on outside the UK, = this could work. But about the case where the device is carried to another = regulatory domain somewhere in the world? Discovery is needed for this case= ; to find an authorized database no matter where the device is when turned = on (assuming white space is authorized in the country where the device is t= urned on). Kind Regards, Scott From: "ext Benjamin A. Rolfe" > Date: Thu, 12 Jul 2012 12:24:15 -0700 To: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery Thanks Andy, So in this case the is it expected the device knows the URI for Ofcom's lis= t and should start there? -Ben All Just to highlight that Ofcom requires that the list of available databases = (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving= database operators can be removed from the list and devices stop using the= ir channel allocations). Ofcom doesn=92t permit a master device to have a p= re-arrangement with a database (such as a pre-programmed URI), or at least,= the validity of any pre-programmed URI has to be checked every 24 hours wi= th Ofcom=92s listing. The discovery problem is similar to US, but two step = through an intermediate listing. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: 10 July 2012 22:44 To: paws@ietf.org Subject: Re: [paws] draft document for Discovery Hi All, It is simple. Vendors could support it forever. And if for example the roam= ing agreement becomes a preferred solution, the vendor could program one or= more addresses into the device (SW update, device management, etc). In the= use case & requirements document the assumption has been that a simple cas= e of discovery is hard-coded addresses in the device. Best Regards, Scott From: "ext Rosen, Brian" > Date: Tue, 10 Jul 2012 17:17:46 -0400 To: "ext com>" > Cc: Scott Probasco >, "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery That would work. This would happen every time the device booted. That could be a fair amoun= t of traffic for a high volume manufacturer. They have to support this fo= rever. It's simple. I wonder if the device mfg would agree to that? Brian On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote: on this topic a completely different approach would be for the device to ca= ll home, to the manufacturer, with the ability for the manufacturer to poin= t it to the appropriate DB for that location. This works well, and simply i= f we assume the device has the relationship with the DB. If it is a user (S= ay network operator) then I would expect them to configure their devices to= go where they desire them to go. On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" > wrote: When I do the discovery, I don't know which country I am in. I can't know = enough to query the right DS unless we put country boundary polygons in the= device. Of course, I forgot to add to this that if there is the U.S. model of compe= ting DBs, then the whole discovery mechanism falls apart, and you need conf= iguration, because if the device knows who its business relationship is wit= h, it can know the URI. Brian On Jul 10, 2012, at 3:38 PM, > > w= rote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" > Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing d= atabases. LoST has a query that sends location in, with a Service URN (which for this= use would be "I want a WSDB for this location" and you get back (a list of= ) URIs. That's what you propose, without the service URN because you want a special= location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DS= s. That's the LoST "Forest Guide". The FG works without a root, and allow= s cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (= or provides their own WSDB DS) then it is not obvious to me why a WSDB DS w= ould need to find out about other WSDB DSs. Each WSDB DS is independent. If= vendor X intends their WSD to operate in Country Y, then WSDB DS used by v= endor X must include appropriate Country Y mapping information (location to= WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what w= ill happen over the life of a device? MSP->Including an address in the device does not imply that the address can= not be changed if needed. SW updates, device management or similar can allo= w for changes if needed. I take your point, these changes should be excepti= ons rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in= ISPs. We may need something that works well without that. There aren't = a lot of good mechanisms that really work well - you either have a root of = some sort, or, as you propose, a starting seed. The root problem is who ru= ns the root, and the starting seed problem is the lifetime of the seed. Yo= u note that the seed gets nothing out of the exchange - it doesn't get to s= erve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticate= d infrastructure as described in the LoST Architecture & Framework RFC 5582= . I actually think this is not an important problem to solve really well. Th= e most common deployment model is going to be a tower and clients. The tow= er can be configured, and either the clients learn from the tower, or the t= ower handles the database query itself. Client discovery in that case coul= d be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more = devices have some other path to the Internet to get to the WSDB. They will= need real discovery and may not have a cooperating ISP. While I really do= n't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, > wrote: Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.orghttps://www.ietf.org/mailman/listinfo/pa= ws _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_8C3DB983C20A4DADA6C2F21959B09B18neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A device needs to know its= own location.

However, as Scott points out, without a l= ist of polygons representing the boundaries of every country, and suitable = code, a device doesn't know what country it is in.

So, we need a mechanism that given an arbitrary lat/lon, leads you to the = right database.

That in turn means there is some k= ind of server you go to first, and it leads you to country specific informa= tion.  You can't start at the OFCOM server because first you have to d= etermine you are in the U.K.

So this is some form = of query with location in the query, and at list one, or possibly a list of= URIs to go to.  There may be a couple of steps - the URI you get may = lead you to a list of URIs.  Each one is the same - you query with loc= ation, you get one or more URIs.   The original discovery server may l= ead you to the Ofcom server which leads you to one or more actual databases= .

At some point, you need some way to choose betwe= en more than one URI when you get that.  This was called "policy" befo= re.

Brian


O= n Jul 12, 2012, at 3:56 PM, Benjamin A. Rolfe wrote:

=20 =20
Thanks Scott,
Yes, there is an presumption that the WSD knows where it is located on earth.  It has to know this to make a database request of course.  What we're looking for then is a global means to determin= e what the initial contact needs to be depending on location.  It seems like the steps necessary to find a database may be different region by region. That should make it fun!

-Ben


Hi Ben,

If the WSD will never have the possibility to be turned on outside the UK, this could work. But about the case where the device is carried to another regulatory domain somewhere in the world? Discovery is needed for this case; to find an authorized database no matter where the device is when turned on (assuming white space is authorized in the country where the device is turned on).

Kind Regards,
Scott

From: "ext Benjamin A. Rolfe" <ben@blindcreek.com>
Date: Thu, 12 Jul 2012 12:24:15 -0700
To: "paws@ietf.org" <paw= s@ietf.org>
Subject: Re: [paws] draft document for Discovery

Thanks Andy,
So in this case the is it expected the device knows the URI for Ofcom's list and should start there?
-Ben

All<= /span>

 

Just to highlight that Ofcom requires that the list of available databases (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving database operators can be removed from the list and devices stop using their channel allocations). Ofcom doesn=92t permit a master device to have a pre-arrangement with a database (such as a pre-programmed URI), or at least, the validity of any pre-programmed URI has to be checked every 24 hours with Ofcom=92s listing. The discovery problem is similar to US, but two step through an intermediate listing.

 

Regards

 

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.or= g] On Behalf Of sc= ott.probasco@nokia.com
Sent: 10 July 2012 22:44
To: paws@ietf.org
Subject: Re: [paws] draft document for Discovery

 

Hi All,

=  

It is simple. Vendors could support it forever. And if for example the roaming agreement becomes a preferred solution, the vendor could program one or more addresses into the device (SW update, device management, etc). In the use case & requirements document the assumption has been that a simple case of discovery is hard-coded addresses in the device.

=  

Best Regards,

Scott=

=  

Fro= m: "ext Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Tue, 10 Jul 2012 17:17:46 -0400
To: "ext com>" <peter@spectrumbridge.com&g= t;
Cc: Scott Probasco <scott.probasco@nokia.com&= gt;, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

=  

Tha= t would work.

 

This would happen every time the device booted.  That could be a fai= r amount of traffic for a high volume manufacturer.   They have to support this forever.

 

It's simple.

 

I wonder if the device mfg would agree to that?

 

Brian

 

On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote:



on this topic a completely different approach would be for the device to call home, to the manufacturer, with the ability for the manufacturer to point it to the appropriate DB for that location. This works well, and simply if we assume the device has the relationship with the DB. If it is a user (Say network operator) then I would expect them to configure their devices to go where they desire them to go.  

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

When I do the discovery, I don't know which country I am in.  I can't know enough to query the right DS unless we put country boundary polygons in the device.

 <= /span>

Of course, I forgot to add to this that if there is the U.S. model of competing DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is with, it can know the URI.

 <= /span>

Brian

 <= /span>

 <= /span>

On Jul 10, 2012, at 3:38 PM, <scott.probasc= o@nokia.com> <scott.probasco@nokia.com> wrote:



Hi Brian,

&= nbsp;

Commen= ts below: MSP-><= /span>

 = ;

Kind Regards,

Scott<= o:p>

&= nbsp;

From= : "ext Rosen, Brian" <Brian.Rosen@neus= tar.biz>
Date: Mon, 9 Jul 2012 17:27:31 -0400
To: Scott Probasco <scott.probasco@nokia= .com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft document for Discovery

&= nbsp;

This re-invents LoST without the extensive mechanisms for self organizing databases.

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;">Lo= ST has a query that sends location in, with a Service URN (which for this use would be "I want a WSDB for this location" and you get back (a list of) URIs.  =

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;"> 

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;">Th= at's what you propose, without the service URN because you want a special location based discovery mechanism just for WSDBs.

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;"> 

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;">Wh= at you don't deal with is how a WSDB DS finds out about all other WSDB DSs.  That's the LoST "Forest Guide".  T= he FG works without a root, and allows cooperating LoST servers to  refer queries to the right server.

MSP-&g= t;If each WSD vendor arranges a service level agreement with a WSDB DS (or provides their own WSDB DS) then it is not obvious to me why a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is independent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include appropriate Country Y mapping information (location to WSDB or WSDB listing server) in their WSDB DS.

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;"> 

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;">It= 's not really a great idea to bake a URI into a device.  Wh= o knows what will happen over the life of a device?=

MSP-&g= t;Including an address in the device does not imply that the address cannot be changed if needed. SW updates, device management or similar can allow for changes if needed. I take your point, these changes should be exceptions rather than regular events.

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;"> 

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;">Th= e existing LoST discovery mechanism is built for widespread deployment in ISPs.   We may need something that works well without that.  There aren't a lo= t of good mechanisms that really work well - you either have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the starting seed problem is the lifetime of the seed.  You note th= at the seed gets nothing out of the exchange - it doesn't get to serve the query, it only gets to refer to someone who does.  = ;

MSP-&g= t;It is not clear to me what business model would support a sophisticated infrastructure as described in the LoST Architecture & Framework RFC 5582.

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;"> 

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;">I actually think this is not an important problem to solve really well.  The most common deployment model is going to be a tower and clients.  The tower can be configured, and either the clients learn from the tower, or the tower handles the database query itself.  Client discovery = in that case could be the LoST discovery mechanism.

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;"> 

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;">We have to handle the self organizing case (say a MANET) where one or more devices have some other path to the Internet to get to the WSDB.  They will need re= al discovery and may not have a cooperating ISP.  While I really don't like configuration, it may be the only viable way to do it.

MSP->Co= nfiguration is pragmatic and can be easily deployed

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;"> 

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;">Br= ian

<= span style=3D"font-size: 10.5pt; color: black; font-family: Calibri,sans-serif;"> 

scott.probas= co@nokia.com> wrote:

=

Hello All,

 

Please find a link below to a draft submission for the Discovery process as described in the Use Cases & Requirements document. We are looking forward to your review and comments as well as discussion at IETF#84.

 

Abstract:

   A white space master device needs to query a white space database and

   obtain information about available spectrum/channels prior to

   operation. &= nbsp;White space databases which contain information about

   available spectrum/channels are associated with a regulatory domain.

   A white space master device needs to discover the relevant white

   space database(s) given its current location and in which regulatory=

   domain that it is operating. &= nbsp;The white space database discovery is

   the preliminary step that a white space master device has to perform.

 

 

Htmlized:        http://tools.ietf.org/html/draft-probasco-paws-discove= ry-00

 

Kind Regards,

Scott & Raj

 

 

 

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

 

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

 

____________________= ___________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinf= o/paws

 


_______________________________________________
paws mailing list
paws@ietf.orghtt=
ps://www.ietf.org/mailman/listinfo/paws

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

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

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mai= lman/listinfo/paws

= --_000_8C3DB983C20A4DADA6C2F21959B09B18neustarbiz_-- From sdas@appcomsci.com Sat Jul 14 07:35:51 2012 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 50BE921F8692 for ; Sat, 14 Jul 2012 07:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 xgfr0yt6WHjt for ; Sat, 14 Jul 2012 07:35:50 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id DFC8C21F85A3 for ; Sat, 14 Jul 2012 07:35:49 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q6EEaScO024996; Sat, 14 Jul 2012 10:36:28 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q6EEaSFG019117; Sat, 14 Jul 2012 10:36:28 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Sat, 14 Jul 2012 10:36:27 -0400 From: "Das, Subir" To: "paws@ietf.org" Thread-Topic: New Version Notification for draft-das-paws-protocol-02.txt Thread-Index: AQHNYc03DuuurbnoH0iPYpIGqo/ByZco151w Date: Sat, 14 Jul 2012 14:36:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 14:35:51 -0000 RGVhciBDaGFpcnMsDQpXZSBoYXZlIHVwZGF0ZWQgb3VyIGRyYWZ0IGFuZCB3b3VsZCBsaWtlIHRv IHJlcXVlc3QgYSBzbG90IGluIElFVEYtODQgdG8gcHJlc2VudCBpdC4NCg0KUmVnYXJkcywgDQpf U3ViaXIgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU2F0 dXJkYXksIEp1bHkgMTQsIDIwMTIgMTA6MzAgQU0NClRvOiBEYXMsIFN1YmlyDQpDYzogam1hbHlh ckB0ZWxjb3JkaWEuY29tOyBkLmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb20NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4 dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN1YmlyIERhcyBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZGFzLXBhd3MtcHJv dG9jb2wNClJldmlzaW9uOgkgMDINClRpdGxlOgkJIERldmljZSB0byBEYXRhYmFzZSBQcm90b2Nv bCBmb3IgV2hpdGUgU3BhY2UNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTE0DQpXRyBJRDoJCSBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMzINClVSTDogICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGFzLXBhd3MtcHJv dG9jb2wtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDINCkRpZmY6ICAgICAg ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1kYXMtcGF3cy1w cm90b2NvbC0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBg UHJvdG9jb2wgdG8gQWNjZXNzIFdoaXRlIFNwYWNlIGRhdGFiYXNlDQogICAoUEFXUyknIHRoYXQg dXNlcyBIVFRQL1RMUyBhcyB0cmFuc3BvcnQuICBUaGUgcHJvdG9jb2wgaXMgdXNlZCBmb3INCiAg IHJldHJpZXZpbmcgdGhlIG5lY2Vzc2FyeSBUViB3aGl0ZSBzcGFjZSBpbmZvcm1hdGlvbiAoZS5n LiwgY2hhbm5lbCwNCiAgIGZyZXF1ZW5jeSwgdHJhbnNtaXR0ZWQgcG93ZXIpIGF0IGEgZ2l2ZW4g bG9jYXRpb24gYW5kIHRpbWUgZnJvbSBhDQogICBkYXRhYmFzZSB0aGF0IGlzIG9wZXJhdGluZyB1 bmRlciBhIHJlZ3VsYXRvcnkgZG9tYWluLiAgVGhlIGRvY3VtZW50DQogICBpbmNsdWRlcyB0aGUg cHJvdG9jb2wgZnVuY3Rpb25hbGl0aWVzLCBpdHMgZWxlbWVudHMsIGNvcnJlc3BvbmRpbmcNCiAg IGRhdGEgbW9kZWwgYW5kIHJlY29tbWVuZHMgaXRzIGVuY29kaW5nIHNjaGVtZS4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From Gabor.Bajko@nokia.com Mon Jul 16 12:47:40 2012 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 1A4BD11E812B for ; Mon, 16 Jul 2012 12:47:40 -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 Fr9FwTK72mF8 for ; Mon, 16 Jul 2012 12:47:39 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id AE33611E8088 for ; Mon, 16 Jul 2012 12:47:38 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GJmK2V018940 for ; Mon, 16 Jul 2012 22:48:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 22:48:51 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.99]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Mon, 16 Jul 2012 21:48:19 +0200 From: To: Thread-Topic: slot request for the Vancouver meeting Thread-Index: Ac1ji4uoG3cAezwLRbynOjjPvidfGw== Date: Mon, 16 Jul 2012 19:48:19 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F7EEBF@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [63.133.198.20] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F7EEBF008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2012 19:48:51.0055 (UTC) FILETIME=[05FB77F0:01CD638C] X-Nokia-AV: Clean Subject: [paws] slot request for the Vancouver meeting 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, 16 Jul 2012 19:47:40 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F7EEBF008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Everyone, The Vancouver IETF meeting agenda has been published, see: https://datatra= cker.ietf.org/meeting/84/agenda.html PAWS got an 1.5 hour slot on Monday afternoon 15:40pm to 17:10pm. If you'd like to present, please send slot requests to the chairs. I already received the request from Subir, so you're on the agenda. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F7EEBF008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Everyone,

 

The Vancouver  IETF meeting agenda has been = published, see: https://dat= atracker.ietf.org/meeting/84/agenda.html

PAWS got an 1.5 hour slot on Monday afternoon 15:= 40pm to 17:10pm.

If you'd like to present, please send slot reques= ts to the chairs.

 

I already received the request from Subir, so you= 217;re on the agenda.

 

-     &= nbsp;    Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F7EEBF008AM1MPN1007mg_-- From Peter.McCann@huawei.com Mon Jul 16 13:17:13 2012 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 776E411E8241 for ; Mon, 16 Jul 2012 13:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSb5sk3rywLS for ; Mon, 16 Jul 2012 13:17:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A21411E80A5 for ; Mon, 16 Jul 2012 13:17:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU66793; Mon, 16 Jul 2012 16:17:56 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 13:16:37 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.75]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 13:16:31 -0700 From: Peter McCann To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: slot request for the Vancouver meeting Thread-Index: Ac1ji4uoG3cAezwLRbynOjjPvidfGwABEmMA Date: Mon, 16 Jul 2012 20:16:30 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E1761D@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F7EEBF@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F7EEBF@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] slot request for the Vancouver meeting 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, 16 Jul 2012 20:17:13 -0000 Hi, Gabor, I'd also like a slot to present our protocol proposal draft. -Pete Gabor.Bajko@nokia.com wrote: > Everyone, >=20 >=20 >=20 > The Vancouver IETF meeting agenda has been published, see: > https://datatracker.ietf.org/meeting/84/agenda.html >=20 > PAWS got an 1.5 hour slot on Monday afternoon 15:40pm to 17:10pm. >=20 > If you'd like to present, please send slot requests to the chairs. >=20 >=20 >=20 > I already received the request from Subir, so you're on the agenda. >=20 >=20 >=20 > - Gabor >=20 > From scott.probasco@nokia.com Mon Jul 16 13:39:17 2012 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 56F4A11E8118 for ; Mon, 16 Jul 2012 13:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, 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 HfwSDeF7qzAV for ; Mon, 16 Jul 2012 13:39:16 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1511E8160 for ; Mon, 16 Jul 2012 13:39:15 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GKe0ZV028677 for ; Mon, 16 Jul 2012 23:40:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jul 2012 23:40:30 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.132]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0283.004; Mon, 16 Jul 2012 22:39:59 +0200 From: To: Thread-Topic: [paws] draft document for Discovery Thread-Index: AQHNY5MqOnrfOQ6Kr06kfydURKebMA== Date: Mon, 16 Jul 2012 20:39:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [172.19.40.42] Content-Type: multipart/alternative; boundary="_000_CC29E545DDB3scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2012 20:40:30.0918 (UTC) FILETIME=[3DA50660:01CD6393] X-Nokia-AV: Clean Subject: Re: [paws] draft document for Discovery 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, 16 Jul 2012 20:39:17 -0000 --_000_CC29E545DDB3scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, We have made a minor update to the draft based on received comments. We hav= e clarified that the discovery server has global scope, ie. that a unique d= iscovery server is not required for each regulatory domain. Also we have ci= ted the appropriate requirements which this draft fulfills and provided som= e high level view of the messaging. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-01.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-probasco-paws-d= iscovery-01 Kind Regards, Scott & Raj From: Scott Probasco > Date: Mon, 9 Jul 2012 21:04:47 +0000 To: "paws@ietf.org" > Subject: [paws] draft document for Discovery Hello All, Please find a link below to a draft submission for the Discovery process as= described in the Use Cases & Requirements document. We are looking forward= to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-di= scovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-0= 0 Kind Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CC29E545DDB3scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9F45144C88D24343A9E61279CD2894FC@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hello All,

We have made a mi= nor update to the draft based on received comments. We have clarified that = the discovery server has global scope, ie. that a unique discovery server i= s not required for each regulatory domain. Also we have cited the appropriate requirements which this draft f= ulfills and provided some high level view of the messaging.


Kind Regards,
Scott & Raj

From: Scott Probasco <scott.probasco@nokia.com>
Date: Mon, 9 Jul 2012 21:04:47 += ;0000
To: "paws@ietf.org" <paws@i= etf.org>
Subject: [paws] draft document for = Discovery

Hello All,

Please find a link below to a draft submission for the Discovery proce= ss as described in the Use Cases & Requirements document. We are lookin= g forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to que= ry a white space database and
   obtain information about available spect= rum/channels prior to
   operation.  White space databa= ses which contain information about
   available spectrum/channels are associat= ed with a regulatory domain.
   A white space master device needs to dis= cover the relevant white
   space database(s) given its current loca= tion and in which regulatory
   domain that it is operating.  = The white space database discovery is
   the preliminary step that a white space = master device has to perform.



Kind Regards,
Scott & Raj



_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CC29E545DDB3scottprobasconokiacom_-- From Basavaraj.Patil@nokia.com Mon Jul 16 14:18:53 2012 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 E1E3E11E8161 for ; Mon, 16 Jul 2012 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 RbqkYPoXdgDc for ; Mon, 16 Jul 2012 14:18:53 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3C311E8194 for ; Mon, 16 Jul 2012 14:18:51 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6GLJVQ6002294 for ; Tue, 17 Jul 2012 00:19:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jul 2012 00:20:02 +0300 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.164]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Mon, 16 Jul 2012 23:19:30 +0200 From: To: , Thread-Topic: [paws] slot request for the Vancouver meeting Thread-Index: Ac1ji4uoG3cAezwLRbynOjjPvidfG///pPkA Date: Mon, 16 Jul 2012 21:19:29 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F7EEBF@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [172.19.40.29] Content-Type: multipart/alternative; boundary="_000_CC29EF402131Fbasavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2012 21:20:02.0641 (UTC) FILETIME=[C34D3C10:01CD6398] X-Nokia-AV: Clean Subject: Re: [paws] slot request for the Vancouver meeting 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, 16 Jul 2012 21:18:54 -0000 --_000_CC29EF402131Fbasavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gabor, I would like to request a 10 minute slot to present the following I-D: Title: Protocol to Access White Space database: Discovery URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-discovery-01.= txt Thanks. -Raj From: Gabor Bajko > Date: Monday, July 16, 2012 2:48 PM To: "paws@ietf.org" > Subject: [paws] slot request for the Vancouver meeting Everyone, The Vancouver IETF meeting agenda has been published, see: https://datatra= cker.ietf.org/meeting/84/agenda.html PAWS got an 1.5 hour slot on Monday afternoon 15:40pm to 17:10pm. If you'd like to present, please send slot requests to the chairs. I already received the request from Subir, so you=92re on the agenda. - Gabor --_000_CC29EF402131Fbasavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <554A228EE9204B4EA9262055DC8D9B0A@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Hi Gabor= ,

I would = like to request a 10 minute slot to present the following I-D:
Title:&n= bsp;Protocol to Access White Space datab= ase: Discovery


Thanks.<= /div>
-Raj

From: Gabor Bajko <gabor.bajko@nokia.com>
Date: Monday, July 16, 2012 2:48 PM=
To: "paws@ietf.org" <paws@i= etf.org>
Subject: [paws] slot request for th= e Vancouver meeting

Everyone,

 

The Vancouver  IETF meeting agenda has been = published, see: https://dat= atracker.ietf.org/meeting/84/agenda.html

PAWS got an 1.5 hour slot on Monday afternoon 15:= 40pm to 17:10pm.

If you'd like to present, please send slot reques= ts to the chairs.

 

I already received the request from Subir, so you=92= re on the agenda.

 

-     = ;     Gabor

 

 --_000_CC29EF402131Fbasavarajpatilnokiacom_-- From cuiyang@huawei.com Tue Jul 17 20:16:22 2012 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 D894611E80C2 for ; Tue, 17 Jul 2012 20:16:22 -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 pfnG1QFnDHC9 for ; Tue, 17 Jul 2012 20:16:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6934F11E80AE for ; Tue, 17 Jul 2012 20:16:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIC69557; Tue, 17 Jul 2012 23:17:10 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Jul 2012 20:14:22 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Jul 2012 20:14:20 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.245]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Wed, 18 Jul 2012 11:14:09 +0800 From: Cuiyang To: "Gabor.Bajko@nokia.com" Thread-Topic: Re: [paws] slot request for the Vancouver meeting Thread-Index: Ac1kk2SLbZ3zncXzT86EjR3tgz+Q4Q== Date: Wed, 18 Jul 2012 03:14:07 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2163684D2CE@SZXEML508-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.119] Content-Type: multipart/alternative; boundary="_000_8CC0CB0BCAE52F46882E17828A9AE2163684D2CESZXEML508MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , Wuyizhuang Subject: Re: [paws] slot request for the Vancouver meeting 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, 18 Jul 2012 03:16:23 -0000 --_000_8CC0CB0BCAE52F46882E17828A9AE2163684D2CESZXEML508MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Gabor, I would like to borrow 5-10 mins to present our PAWS security draft, thanks= ! -------------------- A new version of I-D, draft-wu-paws-secutity-00.txt has been successfully s= ubmitted by Yizhuang Wu and posted to the IETF repository. Filename: draft-wu-paws-secutity Revision: 00 Title: Protocol to Access White Space database: security c= onsiderations Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-wu-paws-secutity= -00.txt Status: http://datatracker.ietf.org/doc/draft-wu-paws-secutity Htmlized: http://tools.ietf.org/html/draft-wu-paws-secutity-00 -------------------- -Yang =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Yang Cui, Ph.D. Huawei Technologies cuiyang@huawei.com Gabor.Bajko at nokia.com wrote: > Everyone, > > The Vancouver IETF meeting agenda has been published, see: > https://datatracker.ietf.org/meeting/84/agenda.html > > PAWS got an 1.5 hour slot on Monday afternoon 15:40pm to 17:10pm. > > If you'd like to present, please send slot requests to the chairs. > > > > I already received the request from Subir, so you're on the agenda. > > > > - Gabor > --_000_8CC0CB0BCAE52F46882E17828A9AE2163684D2CESZXEML508MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, Gabor,
 
I would like to borrow 5-10 mins to present our PAWS securi=
ty draft, thanks!
 
--------------------

A new version of I-D, draft-= wu-paws-secutity-00.txt has been successfully submitted by Yizhuang Wu and = posted to the IETF repository.

 

Filename:   &= nbsp;      draft-wu-paws-secutity

Revision:  00

Title:   &nbs= p;            &= nbsp; Protocol to Access White Space database: security considerations=

Creation date: 2012-07-09

WG ID:   &nbs= p;          Individual Submiss= ion

Number of pages: 16

URL:    =          http://www.ietf.org/internet-drafts/draft-wu-paws-secutity-00.txt<= /o:p>

Status:   &nb= sp;      http://datatracker.ietf.org/doc/draft-wu-paws-secutity

Htmlized:   &= nbsp;    http://tools.ietf.org/html/draft-wu-paws-secutity-00<= /p> 

--------------------
 
-Yang
 

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Yang= Cui,  Ph.D.

Huaw= ei Technologies

cuiy= ang@huawei.com

 
 
Gabor.Bajko at nokia.com wrote:
> Everyone,
> 
> The Vancouver  IETF meeting agenda has been publi=
shed, see:
> https://datatracker.ietf.org/meeting/84/agenda.html
> 
> PAWS got an 1.5 hour slot on Monday afternoon 15:40pm =
to 17:10pm.
> 
> If you'd like to present, please send slot requests to=
 the chairs.
> 
> 
> 
> I already received the request from Subir, so you're o=
n the agenda.
> 
> 
> 
> -         =
; Gabor

> 

 

--_000_8CC0CB0BCAE52F46882E17828A9AE2163684D2CESZXEML508MBSchi_-- From brian.rosen@neustar.biz Wed Jul 18 05:51:12 2012 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 A556921F86B3 for ; Wed, 18 Jul 2012 05:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.306, 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 rBr8fI2E+Vxs for ; Wed, 18 Jul 2012 05:51:11 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 26FA321F860F for ; Wed, 18 Jul 2012 05:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1342616169; x=1657973121; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=4qg5FiCZ8FNlFRRCfx9psal708HsbgkIOspe+bEhnxE=; b=ZgVczjd5LpB0WbBybUSkGLj/HTp6r5WjZjZTW3ZzNqnzRhvHyf2SbBXxssuk0C FM6IGNdhSVDixLi+bNvMoChQ== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.12047731; Wed, 18 Jul 2012 08:56:08 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 18 Jul 2012 08:51:48 -0400 From: "Rosen, Brian" Date: Wed, 18 Jul 2012 08:51:48 -0400 Thread-Topic: [paws] slot request for the Vancouver meeting Thread-Index: Ac1k5Bg71w3naIg/RfyTzAr7zBgJVw== Message-ID: <54C006F4-9135-40B5-AAF6-9A85DD9B65AC@neustar.biz> References: <8CC0CB0BCAE52F46882E17828A9AE2163684D2CE@SZXEML508-MBS.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE2163684D2CE@SZXEML508-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Jh6F9M4l0+k1NUcM60tH2A== Content-Type: multipart/alternative; boundary="_000_54C006F4913540B5AAF69A85DD9B65ACneustarbiz_" MIME-Version: 1.0 To: Cuiyang Cc: "paws@ietf.org" , Wuyizhuang Subject: Re: [paws] slot request for the Vancouver meeting 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, 18 Jul 2012 12:51:12 -0000 --_000_54C006F4913540B5AAF69A85DD9B65ACneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, can't resist, undoubtedly a minor english-chinese translation proble= m: You want to "Borrow" 5-10 minutes of the meeting? Will you return it? As there has not been any list discussion on this draft, we would only give= you a slot if we have time at the end. We will let you know. Brian On Jul 17, 2012, at 11:14 PM, Cuiyang wrote: Hi, Gabor, I would like to borrow 5-10 mins to present our PAWS security draft, thanks= ! -------------------- A new version of I-D, draft-wu-paws-secutity-00.txt has been successfully s= ubmitted by Yizhuang Wu and posted to the IETF repository. Filename: draft-wu-paws-secutity Revision: 00 Title: Protocol to Access White Space database: security c= onsiderations Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-wu-paws-secutity= -00.txt Status: http://datatracker.ietf.org/doc/draft-wu-paws-secutity Htmlized: http://tools.ietf.org/html/draft-wu-paws-secutity-00 -------------------- -Yang =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Yang Cui, Ph.D. Huawei Technologies cuiyang@huawei.com Gabor.Bajko at nokia.com wrote: > Everyone, > > The Vancouver IETF meeting agenda has been published, see: > https://datatracker.ietf.org/meeting/84/agenda.html > > PAWS got an 1.5 hour slot on Monday afternoon 15:40pm to 17:10pm. > > If you'd like to present, please send slot requests to the chairs. > > > > I already received the request from Subir, so you're on the agenda. > > > > - Gabor > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_54C006F4913540B5AAF69A85DD9B65ACneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As there has not been an= y list discussion on this draft, we would only give you a slot if we have t= ime at the end.  We will let you know.

Brian<= /div>

On Jul 17, 2012, at 11:14 PM, Cuiyang wr= ote:

Hi, Gabor,
 
I would like to borrow 5-10 mins to present=
 our PAWS security draft, thanks!
 
--------------------
A new version of I-D, draft-wu-paws-secutity-00.txt =
has been successfully submitted by Yizhuang Wu and posted to the IETF repos=
itory.
 
Filename:       &=
nbsp;  draft-wu-paws-secutity
Revision:  00
Title: =
            &nb=
sp;    Protocol to Access White Space database: security con=
siderations
Creation date: 2012-0=
7-09
WG ID:   &nbs=
p;          Individual Submiss=
ion
Number of pages: 16
Htmlized: &=
nbsp;     &n=
bsp;http://tools.ietf.org/=
html/draft-wu-paws-secutity-00
--------------------
 <=
/pre>
-Yang
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Huawei Technologies
cuiyang@huawei.com
 
 
<=
pre style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-b=
ottom: 0.0001pt; font-size: 12pt; font-family: SimSun; ">Gabor.Bajko at nokia.=
com wrote:
> Everyone,
> 
> The Vancouver  IETF meeting agenda has=
 been published, see:
> https://da=
tatracker.ietf.org/meeting/84/agenda.html
> 
> PAWS got an 1.5 hour slo=
t on Monday afternoon 15:40pm to 17:10pm.
> 
> If you'd like to present, p=
lease send slot requests to the chairs.
> 
> 
>
= 
> I already received th=
e request from Subir, so you're on the agenda.
>
> 
> 
> -  &nbs=
p;       Gabor
> 
 
_______= ________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/li= stinfo/paws

= --_000_54C006F4913540B5AAF69A85DD9B65ACneustarbiz_-- From Gabor.Bajko@nokia.com Wed Jul 18 14:59:03 2012 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 8656A11E8157 for ; Wed, 18 Jul 2012 14:59: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 2yui94O4DsCH for ; Wed, 18 Jul 2012 14:59:03 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 982B711E8087 for ; Wed, 18 Jul 2012 14:59:02 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6ILxqjQ017597 for ; Thu, 19 Jul 2012 00:59:52 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jul 2012 01:00:25 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.99]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Wed, 18 Jul 2012 23:59:51 +0200 From: To: Thread-Topic: draft agenda for Vancouver meeting posted Thread-Index: Ac1lMLCDUaXVJUstT0Ct7KipNYAoWg== Date: Wed, 18 Jul 2012 21:59:50 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F848A8@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [63.133.198.20] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F848A8008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2012 22:00:25.0548 (UTC) FILETIME=[BC4B00C0:01CD6530] X-Nokia-AV: Clean Subject: [paws] draft agenda for Vancouver meeting posted X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:59:03 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F848A8008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/84/slides/slides-84-paws-0.txt --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F848A8008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/84/slides/slides-84-= paws-0.txt

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F848A8008AM1MPN1007mg_-- From Gabor.Bajko@nokia.com Wed Jul 18 16:19:54 2012 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 702DF11E81AF for ; Wed, 18 Jul 2012 16:19:54 -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 ex79RpdAE5y0 for ; Wed, 18 Jul 2012 16:19:53 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6943111E80CE for ; Wed, 18 Jul 2012 16:19:53 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6INKh6J028949 for ; Thu, 19 Jul 2012 02:20:43 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jul 2012 02:21:15 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.99]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Thu, 19 Jul 2012 01:20:41 +0200 From: To: Thread-Topic: remote participation to the Vancouver F2F Thread-Index: Ac1lO3cYBZdmcJnuRGaTYBWlOBkrUQ== Date: Wed, 18 Jul 2012 23:20:41 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F84925@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [63.133.198.20] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F84925008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2012 23:21:15.0865 (UTC) FILETIME=[074EA490:01CD653C] X-Nokia-AV: Clean Subject: [paws] remote participation to the Vancouver F2F 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, 18 Jul 2012 23:19:54 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F84925008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some people contacted me offline to ask about the remote participation poss= ibilities for the PAWS session at the Vancouver F2F on Monday, July 30th, 1= 5:40 to 17:10 pm PST. I requested support from the Meetecho team for video broadcast and presenta= tion sharing, while voice will be provided by Skype. Once details are avail= able, I'll forward it to the list. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F84925008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some people contacted me offline to ask about the re= mote participation possibilities for the PAWS session at the Vancouver F2F = on Monday, July 30th, 15:40 to 17:10 pm PST.

 

I requested support from the Meetecho team for video= broadcast and presentation sharing, while voice will be provided by Skype.= Once details are available, I’ll forward it to the list.<= /p>

 

-     &= nbsp;    Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F84925008AM1MPN1007mg_-- From cuiyang@huawei.com Wed Jul 18 17:48:01 2012 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 728C511E80E3 for ; Wed, 18 Jul 2012 17:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 mvEXkN4DO9LW for ; Wed, 18 Jul 2012 17:48:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7748711E80CC for ; Wed, 18 Jul 2012 17:48:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW51902; Wed, 18 Jul 2012 20:48:52 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 17:47:06 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 17:47:11 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.245]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Thu, 19 Jul 2012 08:46:59 +0800 From: Cuiyang To: "Rosen, Brian" Thread-Topic: [paws] slot request for the Vancouver meeting Thread-Index: AQHNZOQheFtQOaMhs0m+hxf42lcwMpcvxCMQ Date: Thu, 19 Jul 2012 00:46:58 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2163684D462@SZXEML508-MBS.china.huawei.com> References: <8CC0CB0BCAE52F46882E17828A9AE2163684D2CE@SZXEML508-MBS.china.huawei.com> <54C006F4-9135-40B5-AAF6-9A85DD9B65AC@neustar.biz> In-Reply-To: <54C006F4-9135-40B5-AAF6-9A85DD9B65AC@neustar.biz> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.119] Content-Type: multipart/alternative; boundary="_000_8CC0CB0BCAE52F46882E17828A9AE2163684D462SZXEML508MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , Wuyizhuang Subject: [paws] =?gb2312?b?tPC4tDogIHNsb3QgcmVxdWVzdCBmb3IgdGhlIFZhbmNv?= =?gb2312?b?dXZlciBtZWV0aW5n?= 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, 19 Jul 2012 00:48:01 -0000 --_000_8CC0CB0BCAE52F46882E17828A9AE2163684D462SZXEML508MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VyZSwgaWYgeW91IHdhbnQgbXkgdGltZSwgSSBjYW4gobByZXR1cm6hsSB5b3UgZGVmaW5pdGVs eSA7LSkNCkFuZCBJIGRvbqGvdCB0aGluayBpdCBpcyBhIHRyYW5zbGF0aW9uIHByb2JsZW0sIGF0 IGFsbC4NCg0KPkFzIHRoZXJlIGhhcyBub3QgYmVlbiBhbnkgbGlzdCBkaXNjdXNzaW9uIG9uIHRo aXMgZHJhZnQsIHdlIHdvdWxkIG9ubHkgZ2l2ZSB5b3UgYSBzbG90IGlmIHdlIGhhdmUgdGltZSBh dCB0aGUgZW5kLiAgV2Ugd2lsbCBsZXQgeW91IGtub3cuDQpObyBwcm9ibGVtLCB0aGFua3MhDQoN CkJSLA0KWWFuZw0KPT09PT09PT09PT09PT09PT09DQpZYW5nIEN1aSwgIFBoLkQuDQpIdWF3ZWkg VGVjaG5vbG9naWVzDQpjdWl5YW5nQGh1YXdlaS5jb20NCg0Kt6K8/sjLOiBSb3NlbiwgQnJpYW4g W21haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpel0NCreiy83KsbzkOiAyMDEyxOo31MIxOMjV IDIwOjUyDQrK1bz+yMs6IEN1aXlhbmcNCrOty806IGdhYm9yLmJhamtvQG5va2lhLmNvbTsgcGF3 c0BpZXRmLm9yZzsgV3V5aXpodWFuZw0K1vfM4jogUmU6IFtwYXdzXSBzbG90IHJlcXVlc3QgZm9y IHRoZSBWYW5jb3V2ZXIgbWVldGluZw0KDQpTb3JyeSwgY2FuJ3QgcmVzaXN0LCB1bmRvdWJ0ZWRs eSBhIG1pbm9yIGVuZ2xpc2gtY2hpbmVzZSB0cmFuc2xhdGlvbiBwcm9ibGVtOg0KDQpZb3Ugd2Fu dCB0byAiQm9ycm93IiA1LTEwIG1pbnV0ZXMgb2YgdGhlIG1lZXRpbmc/ICBXaWxsIHlvdSByZXR1 cm4gaXQ/DQoNCkFzIHRoZXJlIGhhcyBub3QgYmVlbiBhbnkgbGlzdCBkaXNjdXNzaW9uIG9uIHRo aXMgZHJhZnQsIHdlIHdvdWxkIG9ubHkgZ2l2ZSB5b3UgYSBzbG90IGlmIHdlIGhhdmUgdGltZSBh dCB0aGUgZW5kLiAgV2Ugd2lsbCBsZXQgeW91IGtub3cuDQoNCkJyaWFuDQoNCk9uIEp1bCAxNywg MjAxMiwgYXQgMTE6MTQgUE0sIEN1aXlhbmcgd3JvdGU6DQoNCg0KDQpIaSwgR2Fib3IsDQoNCg0K DQpJIHdvdWxkIGxpa2UgdG8gYm9ycm93IDUtMTAgbWlucyB0byBwcmVzZW50IG91ciBQQVdTIHNl Y3VyaXR5IGRyYWZ0LCB0aGFua3MhDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LXBhd3Mtc2VjdXRpdHktMDAudHh0IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWWl6aHVhbmcgV3UgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgICAgZHJhZnQtd3UtcGF3cy1zZWN1dGl0 eQ0KUmV2aXNpb246ICAwMA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgUHJvdG9jb2wgdG8gQWNj ZXNzIFdoaXRlIFNwYWNlIGRhdGFiYXNlOiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KQ3JlYXRp b24gZGF0ZTogMjAxMi0wNy0wOQ0KV0cgSUQ6ICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCk51bWJlciBvZiBwYWdlczogMTYNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtcGF3cy1zZWN1dGl0eS0wMC50eHQNClN0 YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1w YXdzLXNlY3V0aXR5DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXd1LXBhd3Mtc2VjdXRpdHktMDANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoN Ci1ZYW5nDQoNCg0KPT09PT09PT09PT09PT09PT09DQpZYW5nIEN1aSwgIFBoLkQuDQpIdWF3ZWkg VGVjaG5vbG9naWVzDQpjdWl5YW5nQGh1YXdlaS5jb208bWFpbHRvOmN1aXlhbmdAaHVhd2VpLmNv bT4NCg0KDQoNCg0KDQpHYWJvci5CYWprbyBhdCBub2tpYS5jb208aHR0cDovL25va2lhLmNvbT4g d3JvdGU6DQoNCj4gRXZlcnlvbmUsDQoNCj4NCg0KPiBUaGUgVmFuY291dmVyICBJRVRGIG1lZXRp bmcgYWdlbmRhIGhhcyBiZWVuIHB1Ymxpc2hlZCwgc2VlOg0KDQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbWVldGluZy84NC9hZ2VuZGEuaHRtbA0KDQo+DQoNCj4gUEFXUyBnb3QgYW4g MS41IGhvdXIgc2xvdCBvbiBNb25kYXkgYWZ0ZXJub29uIDE1OjQwcG0gdG8gMTc6MTBwbS4NCg0K Pg0KDQo+IElmIHlvdSdkIGxpa2UgdG8gcHJlc2VudCwgcGxlYXNlIHNlbmQgc2xvdCByZXF1ZXN0 cyB0byB0aGUgY2hhaXJzLg0KDQo+DQoNCj4NCg0KPg0KDQo+IEkgYWxyZWFkeSByZWNlaXZlZCB0 aGUgcmVxdWVzdCBmcm9tIFN1YmlyLCBzbyB5b3UncmUgb24gdGhlIGFnZW5kYS4NCg0KPg0KDQo+ DQoNCj4NCg0KPiAtICAgICAgICAgIEdhYm9yDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9y ZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGF3cw0KDQo= --_000_8CC0CB0BCAE52F46882E17828A9AE2163684D462SZXEML508MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Sure, if y= ou want my time, I can =A1=B0return=A1=B1 you definitely ;-)

And I don= =A1=AFt think it is a translation problem, at all.

 = ;

>As there has not been any list discussion on this draft, we would only giv= e you a slot if we have time at the end.  We will let you know.=

No problem= , thanks!

 = ;

BR,

Yang<= /o:p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Yang Cui,  Ph.D.<= /o:p>

Huawei Technologies

cuiyang@huawei.com

 = ;

=B7=A2=BC=FE=C8=CB: Rosen, = Brian [mailto:Brian.Rosen@neustar.biz]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C218=C8=D5 20:52
=CA=D5=BC=FE=C8=CB: Cuiyang
=B3=AD=CB=CD: gabor.bajko@nokia.com; paws@ietf.org; Wuyizhuang
=D6=F7=CC=E2: Re: [paws] slot request for the Vancouver meeting

 

Sorry, can't resist, undoubtedl= y a minor english-chinese translation problem:

 

You want to "Borrow" = 5-10 minutes of the meeting?  Will you return it?

 

As there has not been any list = discussion on this draft, we would only give you a slot if we have time at = the end.  We will let you know.

 

Brian

 

On Jul 17, 2012, at 11:14 PM, C= uiyang wrote:



Hi, Gabor,
 
I would like to borrow 5-10 mins to presen=
t our PAWS security draft, thanks!
 
--------------------

A new version of I-D, dr= aft-wu-paws-secutity-00.txt has been successfully submitted by Yizhuang Wu = and posted to the IETF repository.

 =

Filename:  &nb= sp;       draft-wu-paws-secutity

Revision:  00<= /o:p>

Title:   =             &nb= sp;  Protocol to Access White Space database: security considerations<= o:p>

Creation date: 2012-07-0= 9

WG ID:   =            Individual Sub= mission

Number of pages: 16=

Status:   = ;      =  http://datatracker.ietf.org/doc/draft-wu-paws-secutity<= /span>

--------------------
 
-Yang
 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Yang Cui,  Ph.D.

Huawei Technologies

cui= yang@huawei.com 

 
 
Gabor.Bajko at nokia.com wrote:
> Everyone,

> 


> The Vancouver  IETF meeting agen=
da has been published, see:


> https://datatracker.ietf.org/meeting/84/agenda.h=
tml


> 


> PAWS got an 1.5 hour slot on Monday a=
fternoon 15:40pm to 17:10pm.


> 


> If you'd like to present, please send=
 slot requests to the chairs.


> 


> 


> 


> I already received the request from S=
ubir, so you're on the agenda.


> 


> 


> 


> -      =
    Gabor


> 


 


______________________=
_________________________

paws mailing list

paws@ietf.org

https://www.ietf.org/mailman/listinfo/paws

 

--_000_8CC0CB0BCAE52F46882E17828A9AE2163684D462SZXEML508MBSchi_-- From Gabor.Bajko@nokia.com Sat Jul 21 16:29:41 2012 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 0BB2E21F854A for ; Sat, 21 Jul 2012 16:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLS9JBSxZqC4 for ; Sat, 21 Jul 2012 16:29:40 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8121F8559 for ; Sat, 21 Jul 2012 16:29:38 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6LNUakU001901 for ; Sun, 22 Jul 2012 02:30:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 22 Jul 2012 02:31:12 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.99]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Sun, 22 Jul 2012 01:30:35 +0200 From: To: Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlg== Date: Sat, 21 Jul 2012 23:30:35 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.118.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jul 2012 23:31:12.0892 (UTC) FILETIME=[EA66FBC0:01CD6798] X-Nokia-AV: Clean Subject: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 23:29:41 -0000 It would be beneficial if there were discussions on the drafts to submitted= ahead of the F2F presentations. Thus, I've taken the initiative to read the draft and provide some initial = comments: 1. I do not understand the purpose of the initialization process and why me= ssages INT-REQ and INT-RESP are necessary. The capability exchange can be d= one during the registration process. We may even consider merging the registration process with the DB query pro= cess, there doesn't seem to be any reason to have them as separate messages= . 2. you may need a section where you map your newly defined messages to exis= ting http protocol messages. I saw that you have an example section, but a = normative section would be more desirable. 3. the data model part needs some more work. The structure is not very clea= r to me, and some of the attributes reference obsolete RFC.=20 Eg, RFC3825 is referenced for the longitude/latitude attributes. I think yo= u should be better of using an element for geo-location, with the structure= as defined in RFC5491, a separate element for the civic location, with the= structure as defined in RFC5139, etc. Instead of the DeviceOwner object, I would use a vCard element, with the st= ructure as defined in RFC2426. You may also need an iCalendar element (RFC5545) to specify the channel ava= ilability time (eg, when the channel is not available for the full 24H). Etc. More comments are welcome. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Das, Subir Sent: Saturday, July 14, 2012 7:36 AM To: paws@ietf.org Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-02= .txt Dear Chairs, We have updated our draft and would like to request a slot in IETF-84 to pr= esent it. Regards,=20 _Subir=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Saturday, July 14, 2012 10:30 AM To: Das, Subir Cc: jmalyar@telcordia.com; d.joslyn@spectrumbridge.com Subject: New Version Notification for draft-das-paws-protocol-02.txt A new version of I-D, draft-das-paws-protocol-02.txt has been successfully = submitted by Subir Das and posted to the IETF repository. Filename: draft-das-paws-protocol Revision: 02 Title: Device to Database Protocol for White Space Creation date: 2012-07-14 WG ID: Individual Submission Number of pages: 32 URL: http://www.ietf.org/internet-drafts/draft-das-paws-protoco= l-02.txt Status: http://datatracker.ietf.org/doc/draft-das-paws-protocol Htmlized: http://tools.ietf.org/html/draft-das-paws-protocol-02 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-das-paws-protoc= ol-02 Abstract: This document describes the `Protocol to Access White Space database (PAWS)' that uses HTTP/TLS as transport. The protocol is used for retrieving the necessary TV white space information (e.g., channel, frequency, transmitted power) at a given location and time from a database that is operating under a regulatory domain. The document includes the protocol functionalities, its elements, corresponding data model and recommends its encoding scheme. = =20 The IETF Secretariat _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Sat Jul 21 16:51:58 2012 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 9BA5921F8508 for ; Sat, 21 Jul 2012 16:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m99gCgqKNjPf for ; Sat, 21 Jul 2012 16:51:57 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5978E21F8507 for ; Sat, 21 Jul 2012 16:51:57 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6LNqsNK015417; Sun, 22 Jul 2012 02:52:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 22 Jul 2012 02:53:30 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.99]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Sun, 22 Jul 2012 01:52:53 +0200 From: To: , Thread-Topic: comments on draft-wei-paws-framework Thread-Index: Ac1nmhNVz1HsZYziSImhJzAJNzwUww== Date: Sat, 21 Jul 2012 23:52:52 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884CF@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.118.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jul 2012 23:53:30.0386 (UTC) FILETIME=[079C5F20:01CD679C] X-Nokia-AV: Clean Subject: [paws] comments on draft-wei-paws-framework 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, 21 Jul 2012 23:51:58 -0000 This is also a quite well written draft, which addresses the same solution = space as draft-das-paws-protocol-02, with quite significant similarities to= that draft. The main differences I could observe is that it has slightly more detailed = description on white spaces purpose, it does not define the INT-REQ and INT= -RESP messages which draft-das-paws does (and which purpose I did not under= stand), and it uses xml for the data model description, while draft-das-paw= s uses json. But all the comments I had on the data model described in draft-das-paws ap= ply for this draft as well. During the last F2F both drafts (or a previous reincarnation of them) were = presented, and there was a request that the authors come up with a merged d= raft, rather than having two separate drafts with quite big overlap. That did not happen for some reason, so we'll possibly need to decide which= one of the two very similar drafts will the wg proceed forward. So I'd enc= ourage people to read the drafts before the F2F. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Peter McCann Sent: Tuesday, July 10, 2012 7:31 AM To: paws@ietf.org Subject: [paws] New draft on a protocol framework for PAWS Hi, all, Yesterday we submitted a draft protocol framework for PAWS that defines an = XML schema for messages and data elements between a master device and a dat= abase. You can find it here: http://tools.ietf.org/html/draft-wei-paws-framework-00 For now the draft is kind of hand-wavy about database discovery and the sec= urity model, especially the security model for validating slave devices. These issues probably need to be addressed in separate documents. -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 U= SA _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Sat Jul 21 18:06:16 2012 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 4AB6621F8599 for ; Sat, 21 Jul 2012 18:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 NUvIjg0eiLJm for ; Sat, 21 Jul 2012 18:06:15 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 37F9A21F859A for ; Sat, 21 Jul 2012 18:06:09 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sat, 21 Jul 2012 21:07:09 -0400 From: Peter Stanforth To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Date: Sat, 21 Jul 2012 21:07:02 -0400 Thread-Topic: [paws] comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nplEzZGVG/e9fR2O0Q/tO5gxCFA== Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 01:06:16 -0000 Gabor. This draft represents the merger of two submitted proposals, one from Das/Gabor from Telcordia and one from Peter/Don from SBI prior to the last meeting. These individuals have worked to create a single proposal for this upcoming meeting. This attempt at a merger was a request from the last meeting and was acted upon so I do not understand why you think there has been no discussion. I do not agree with your assertion that the data model needs more work. For example your assumption that an iCalander element is needed. You assume that a 24 hour channel map is provided. There is no reason to require this. In fact there is ongoing discussion in the US to migrating to much shorter channel allocations and it is reasonable to have a channel map that is valid for a duration until such time as something changes. In other words the DB provides a channel map that is valid from now until some time in the future, which may be much less than 24 hours. Peter S. On SatJul/21/12 Sat Jul 21, 7:30 PM, "Gabor.Bajko@nokia.com" wrote: >It would be beneficial if there were discussions on the drafts to >submitted ahead of the F2F presentations. >Thus, I've taken the initiative to read the draft and provide some >initial comments: > >1. I do not understand the purpose of the initialization process and why >messages INT-REQ and INT-RESP are necessary. The capability exchange can >be done during the registration process. >We may even consider merging the registration process with the DB query >process, there doesn't seem to be any reason to have them as separate >messages. > >2. you may need a section where you map your newly defined messages to >existing http protocol messages. I saw that you have an example section, >but a normative section would be more desirable. > >3. the data model part needs some more work. The structure is not very >clear to me, and some of the attributes reference obsolete RFC. >Eg, RFC3825 is referenced for the longitude/latitude attributes. I think >you should be better of using an element for geo-location, with the >structure as defined in RFC5491, a separate element for the civic >location, with the structure as defined in RFC5139, etc. >Instead of the DeviceOwner object, I would use a vCard element, with the >structure as defined in RFC2426. >You may also need an iCalendar element (RFC5545) to specify the channel >availability time (eg, when the channel is not available for the full >24H). >Etc. > >More comments are welcome. >- Gabor > > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >ext Das, Subir >Sent: Saturday, July 14, 2012 7:36 AM >To: paws@ietf.org >Subject: [paws] FW: New Version Notification for >draft-das-paws-protocol-02.txt > >Dear Chairs, >We have updated our draft and would like to request a slot in IETF-84 to >present it. > >Regards,=20 >_Subir=20 > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Saturday, July 14, 2012 10:30 AM >To: Das, Subir >Cc: jmalyar@telcordia.com; d.joslyn@spectrumbridge.com >Subject: New Version Notification for draft-das-paws-protocol-02.txt > > >A new version of I-D, draft-das-paws-protocol-02.txt has been >successfully submitted by Subir Das and posted to the IETF repository. > >Filename: draft-das-paws-protocol >Revision: 02 >Title: Device to Database Protocol for White Space >Creation date: 2012-07-14 >WG ID: Individual Submission >Number of pages: 32 >URL: =20 >http://www.ietf.org/internet-drafts/draft-das-paws-protocol-02.txt >Status: http://datatracker.ietf.org/doc/draft-das-paws-protocol >Htmlized: http://tools.ietf.org/html/draft-das-paws-protocol-02 >Diff: =20 >http://tools.ietf.org/rfcdiff?url2=3Ddraft-das-paws-protocol-02 > >Abstract: > This document describes the `Protocol to Access White Space database > (PAWS)' that uses HTTP/TLS as transport. The protocol is used for > retrieving the necessary TV white space information (e.g., channel, > frequency, transmitted power) at a given location and time from a > database that is operating under a regulatory domain. The document > includes the protocol functionalities, its elements, corresponding > data model and recommends its encoding scheme. > > =20 > =20 > > >The IETF Secretariat >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Sun Jul 22 04:17:53 2012 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 5F83C21F8564 for ; Sun, 22 Jul 2012 04:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kkkYfr59NMje for ; Sun, 22 Jul 2012 04:17:52 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2C11921F8559 for ; Sun, 22 Jul 2012 04:17:51 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sun, 22 Jul 2012 07:18:52 -0400 From: Peter Stanforth To: "Gabor.Bajko@nokia.com" Date: Sun, 22 Jul 2012 07:22:16 -0400 Thread-Topic: [paws] comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1n+8WOyGK/HvpGThCV1X9TPztuAA== Message-ID: <5E06DA64-8E37-44ED-A6DB-625D1FE732DC@spectrumbridge.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 11:17:53 -0000 Sorry I got my naming/timing wrong. John Malyar and Don Joslyn submitted dr= afts to the last F2F. Subir Das and Don Joslyn combined them for this F2F Peter S. On Jul 21, 2012, at 7:30 PM, "Gabor.Bajko@nokia.com" wrote: > It would be beneficial if there were discussions on the drafts to submitt= ed ahead of the F2F presentations. > Thus, I've taken the initiative to read the draft and provide some initia= l comments: >=20 > 1. I do not understand the purpose of the initialization process and why = messages INT-REQ and INT-RESP are necessary. The capability exchange can be= done during the registration process. > We may even consider merging the registration process with the DB query p= rocess, there doesn't seem to be any reason to have them as separate messag= es. >=20 > 2. you may need a section where you map your newly defined messages to ex= isting http protocol messages. I saw that you have an example section, but = a normative section would be more desirable. >=20 > 3. the data model part needs some more work. The structure is not very cl= ear to me, and some of the attributes reference obsolete RFC.=20 > Eg, RFC3825 is referenced for the longitude/latitude attributes. I think = you should be better of using an element for geo-location, with the structu= re as defined in RFC5491, a separate element for the civic location, with t= he structure as defined in RFC5139, etc. > Instead of the DeviceOwner object, I would use a vCard element, with the = structure as defined in RFC2426. > You may also need an iCalendar element (RFC5545) to specify the channel a= vailability time (eg, when the channel is not available for the full 24H). > Etc. >=20 > More comments are welcome. > - Gabor >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of e= xt Das, Subir > Sent: Saturday, July 14, 2012 7:36 AM > To: paws@ietf.org > Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-= 02.txt >=20 > Dear Chairs, > We have updated our draft and would like to request a slot in IETF-84 to = present it. >=20 > Regards,=20 > _Subir=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Saturday, July 14, 2012 10:30 AM > To: Das, Subir > Cc: jmalyar@telcordia.com; d.joslyn@spectrumbridge.com > Subject: New Version Notification for draft-das-paws-protocol-02.txt >=20 >=20 > A new version of I-D, draft-das-paws-protocol-02.txt has been successfull= y submitted by Subir Das and posted to the IETF repository. >=20 > Filename: draft-das-paws-protocol > Revision: 02 > Title: Device to Database Protocol for White Space > Creation date: 2012-07-14 > WG ID: Individual Submission > Number of pages: 32 > URL: http://www.ietf.org/internet-drafts/draft-das-paws-proto= col-02.txt > Status: http://datatracker.ietf.org/doc/draft-das-paws-protocol > Htmlized: http://tools.ietf.org/html/draft-das-paws-protocol-02 > Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-das-paws-prot= ocol-02 >=20 > Abstract: > This document describes the `Protocol to Access White Space database > (PAWS)' that uses HTTP/TLS as transport. The protocol is used for > retrieving the necessary TV white space information (e.g., channel, > frequency, transmitted power) at a given location and time from a > database that is operating under a regulatory domain. The document > includes the protocol functionalities, its elements, corresponding > data model and recommends its encoding scheme. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From jmalyar@telcordia.com Sun Jul 22 08:44:22 2012 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 9417A21F8648 for ; Sun, 22 Jul 2012 08:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HQ5Q+U6u0G9V for ; Sun, 22 Jul 2012 08:44:21 -0700 (PDT) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7298021F8646 for ; Sun, 22 Jul 2012 08:44:21 -0700 (PDT) Received: from pya-dte-bms01.telcordia.com (pya-dte-bms01.cc.telcordia.com [128.96.37.48]) by dnsmx2pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id q6MFjGms010137; Sun, 22 Jul 2012 11:45:17 -0400 (EDT) X-AuditID: 80602530-b7ff16d0000026a6-ca-500c200cb13e Received: from rrc-dte-exhb1.dte.telcordia.com (rrc-dte-exhb1.cc.telcordia.com [128.96.20.12]) by pya-dte-bms01.telcordia.com (Symantec Messaging Gateway) with SMTP id 28.41.09894.C002C005; Sun, 22 Jul 2012 11:45:17 -0400 (EDT) Received: from RRC-DTE-EXHB3.dte.telcordia.com (128.96.105.72) by rrc-dte-exhb1.dte.telcordia.com (128.96.20.12) with Microsoft SMTP Server (TLS) id 8.3.245.1; Sun, 22 Jul 2012 11:45:16 -0400 Received: from RRC-DTE-EXMB4.dte.telcordia.com ([fe80::8ad:5ccb:8fe0:2314]) by rrc-dte-exhb3.dte.telcordia.com ([2002:8060:6948::8060:6948]) with mapi id 14.01.0339.001; Sun, 22 Jul 2012 11:45:16 -0400 From: "Malyar, John P" To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgAhqfGI Date: Sun, 22 Jul 2012 15:45:15 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.96.150.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsXSkCDCo8urwBNgcPo4m8X/0z9YLQ70zGV2 YPJYsuQnk8fdW5eYApiiuGxSUnMyy1KL9O0SuDLa9v9iKWhTq9h/uIG1gbFdvouRk0NCwESi ceVydghbTOLCvfVsILaQwFNGic/ziroYuYDsw4wSre//sEI4Zxkltp+cxAxSxSagJ3HrXydY t4hAmETDvb+MILawgIVE6/MOqLilxOkV61ggbCOJ1tnvwOIsAqoSL/ongtm8AiESbct+MkFs DpeY+vcCWJxTIEKi+9MpsF2MQNd9P7UGrIZZQFzi1pP5TBBXC0gs2XOeGcIWlXj5+B8rhK0k cbXjNBtEvY7Egt2foGxtiWULXzND7BWUODnzCQvEXiWJ///PsE1gFJ+FZMUsJO2zkLTPQtK+ gJFlFaN0QWWibkpJqm5SbrGBoV5Jak5yflFKZqJecn7uJkZwlKka7GDc/Uv9EKMAB6MSD6+R O3eAEGtiWXFl7iFGCQ5mJRHey9eBQrwpiZVVqUX58UWlOanFhxilOViUxHm36Pv7CAmkJ5ak ZqemFqQWwWSZODilGhjXnbAouHlow5m633GffitNzXryuO3jFla1i1+s9x5b+eLf2YoNC8+e d7uzLXt6WOEqWQOnICvNg28/G/HzJKrxpzx9qHis97uW+bsI4ZS7YVOl69NY/LZZeB7Yfbf4 2PXvczMjkjKZYtkVeF57LVcOzFG0nrLlSap/Fp/K/CjZRTySLt/vrOBWYinOSDTUYi4qTgQA KayxP64CAAA= Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 15:44:22 -0000 Gabor, Thanks for your comments. We separated the two sets of functions to allow f= or (as described in the document) the general ability for the Master Device= to establish communications with the Database in the INT-REQ and used the = REG-REQ for the specific purpose of supporting the requirement for a Fixed = Device to register its location and owner information as per the FCC rules.= They could be combined; however, it seemed clearer to separate out the opt= ional requirement of the Fixed Device registration into a separate well def= ined function. Regarding the data model using vCard and iCalendar are reasonable implement= ations however including these packages may be cumbersome and overkill for = the one or two elements that need to be communicated. One of the design pri= nciples we were considering in the draft proposal was to keep the interface= light weight. Looking forward to the discussion in Vancouver. Regards, John Malyar =20 ________________________________________ From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of Gabor.Bajk= o@nokia.com [Gabor.Bajko@nokia.com] Sent: Saturday, July 21, 2012 7:30 PM To: paws@ietf.org Subject: [paws] comments on draft-das-paws-protocol-02.txt It would be beneficial if there were discussions on the drafts to submitted= ahead of the F2F presentations. Thus, I've taken the initiative to read the draft and provide some initial = comments: 1. I do not understand the purpose of the initialization process and why me= ssages INT-REQ and INT-RESP are necessary. The capability exchange can be d= one during the registration process. We may even consider merging the registration process with the DB query pro= cess, there doesn't seem to be any reason to have them as separate messages= . 2. you may need a section where you map your newly defined messages to exis= ting http protocol messages. I saw that you have an example section, but a = normative section would be more desirable. 3. the data model part needs some more work. The structure is not very clea= r to me, and some of the attributes reference obsolete RFC. Eg, RFC3825 is referenced for the longitude/latitude attributes. I think yo= u should be better of using an element for geo-location, with the structure= as defined in RFC5491, a separate element for the civic location, with the= structure as defined in RFC5139, etc. Instead of the DeviceOwner object, I would use a vCard element, with the st= ructure as defined in RFC2426. You may also need an iCalendar element (RFC5545) to specify the channel ava= ilability time (eg, when the channel is not available for the full 24H). Etc. More comments are welcome. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Das, Subir Sent: Saturday, July 14, 2012 7:36 AM To: paws@ietf.org Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-02= .txt Dear Chairs, We have updated our draft and would like to request a slot in IETF-84 to pr= esent it. Regards, _Subir -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Saturday, July 14, 2012 10:30 AM To: Das, Subir Cc: jmalyar@telcordia.com; d.joslyn@spectrumbridge.com Subject: New Version Notification for draft-das-paws-protocol-02.txt A new version of I-D, draft-das-paws-protocol-02.txt has been successfully = submitted by Subir Das and posted to the IETF repository. Filename: draft-das-paws-protocol Revision: 02 Title: Device to Database Protocol for White Space Creation date: 2012-07-14 WG ID: Individual Submission Number of pages: 32 URL: http://www.ietf.org/internet-drafts/draft-das-paws-protoco= l-02.txt Status: http://datatracker.ietf.org/doc/draft-das-paws-protocol Htmlized: http://tools.ietf.org/html/draft-das-paws-protocol-02 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-das-paws-protoc= ol-02 Abstract: This document describes the `Protocol to Access White Space database (PAWS)' that uses HTTP/TLS as transport. The protocol is used for retrieving the necessary TV white space information (e.g., channel, frequency, transmitted power) at a given location and time from a database that is operating under a regulatory domain. The document includes the protocol functionalities, its elements, corresponding data model and recommends its encoding scheme. The IETF Secretariat _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws= From lei.zhu@huawei.com Mon Jul 23 03:44:23 2012 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 D7B0521F8665 for ; Mon, 23 Jul 2012 03:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 vZtfxTAD1rXQ for ; Mon, 23 Jul 2012 03:44:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F41FC21F84FC for ; Mon, 23 Jul 2012 03:44:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIG48036; Mon, 23 Jul 2012 06:44:22 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 03:41:51 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 03:41:52 -0700 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.92]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Mon, 23 Jul 2012 18:41:42 +0800 From: Zhulei To: "Gabor.Bajko@nokia.com" , Peter McCann , "paws@ietf.org" Thread-Topic: comments on draft-wei-paws-framework Thread-Index: Ac1nmhNVz1HsZYziSImhJzAJNzwUwwBGCjsQ Date: Mon, 23 Jul 2012 10:41:40 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE6252495E5F8@szxeml504-mbs.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884CF@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884CF@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] comments on draft-wei-paws-framework 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, 23 Jul 2012 10:44:24 -0000 SGkgR2Fib3IgYW5kIGFsbCwNCg0KSSB0aGluayB0aGF0IHlvdSBhcmUgY29ycmVjdCB0aGF0IHRo aXMgcHJvcG9zYWwgaXMgb25lIG9mIHR3byBwcmVzZW50YXRpb25zIGluIGxhc3QgSUVURiBmMmYg bWVldGluZy4gVGhlIGRpZmZlcmVuY2VzIGhhcyBiZWVuIG5hcnJvd2VkIGR1cmluZyB0aGlzIGll dGYgbWVldGluZyBkdXJhdGlvbi4gRm9yIHRoZSByZWFzb25zIHRoYXQgSSBhbSBvcGVuIHRvIG1l cmdlIHByb3Bvc2FscyBiYXNlZCBvbiB0aGUgY29uc2Vuc3VzIG9mIHdvcmsgZ3JvdXAsIGl0IGlz IHRvIHNlZSB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0d28uDQoNClRoZXJlIGFyZSBhIG51bWJl ciBvZiBkaWZmZXJlbmNlcyBiZXR3ZWVuIGRyYWZ0LXdlaS1wYXdzLWZyYW1ld29yayBbcGF3cyBm cmFtZXdvcmtdIGFuZCBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMiBbcGF3cyBwcm90b2NvbF0u IA0KDQoxKSBGaXJzdCBvZiBhbGwsIFtwYXdzIGZyYW1ld29ya10gZGVzY3JpYmVzIHRoZSBwcmlu Y2lwbGVzIG9mIERCIGRpc2NvdmVyeSBhbmQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2hpY2gg YXJlIHJlcXVpcmVkIGJ5IGNoYXJ0ZXIgYW5kIHJlcXVpcmVtZW50IGRvY3VtZW50LiBCdXQsIHNl ZW1zIFtwYXdzIGZyYW1ld29ya10gb3V0bGluZSB0aGUgY29uY2VwdHMgb2YgdGhlbSwgYW5kIHNl cGFyYXRlIG1vcmUgZGV0YWlsIGRvY3VtZW50cyBhcmUgZXhwZWN0ZWQuIEl0IHdvdWxkIGJlIGhl bHBmdWwgaW4gY2FzZSB0aGF0IHRoZSByZWd1bGF0b3J5IGhhcyBkaWZmZXJlbnQgdW5kZXJzdGFu ZGluZyBpZiB3b3VsZCBoYXZlIGRpc2NvdmVyeSBvciBmdWxsIHNlY3VyaXR5IG1lY2hhbmlzbXMg dG8gcGF3cyBhcHBsaWNhdGlvbi4gVGhlbiwgY29yZSBwYXJ0IG9mIHBhd3MgcHJvdG9jb2wgc3Vw cG9ydGluZyBpbnRlcm9wZXJhYmlsaXR5IGlzIHF1aXRlIGNsZWFuIHRvIGJlIHJldXNlZCwgYW5k IHNhdGlzZnkgdGhlIG90aGVyIG5lZWRzIGF0IHRoZSBzYW1lIHRpbWUuDQoNCjIpIFRoZSBtZXNz YWdlcyBvZiBJTlQtUkVRIGFuZCBJTlQtUkVTUCBpbiBbcGF3cyBwcm90b2NvbF0gYXJlIGludmlz aWJsZSB0byBbcGF3cyBmcmFtZXdvcmtdLiBUaGUgcmVhc29uIHRvIGVzdGFibGlzaCB0Y3AgY29u bmVjdGlvbiBpcyBub3Qgc3VyZSB0byBtZS4gVGhlIGluZm9ybWF0aW9uIHB1dCBpbiBJTlQtUkVR IGFuZCBJTlQtUkVTUCBpcyBkdXBsaWNhdGVkIGlmIGNvbXBhcmUgdG8gcmVnaXN0cmF0aW9uIHBy b2Nlc3MsIGl0IGlzIGFsc28gbm90IHN1cmUgdG8gbWUuIFNvLCB0aGVzZSB0d28gbWVzc2FnZXMg Y2FuIGJlIG1vdmVkIGlmIHdlIGFyZSBnb2luZyBtZXJnaW5nIHdnIGRvYywgb3Igb25lIG9mIHRo ZW0uDQoNCjMpIEkgdGhpbmsgdGhhdCByZWd1bGF0b3J5IHNob3duIHRoZSBuZWVkIGFuZCBlLW1h aWwgbGlzdCB3YW50cyB0aGlzIHByb2NlZHVyZSBpbiBmcmFtZXdvcmsgYW5kIHdvdWxkIGxpa2Ug dG8ga2VlcCB1cGRhdGUgbWVzc2FnZXMgcGFydCBpbiBbcGF3cyBmcmFtZXdvcmtdLiBOb3Qgc3Vy ZSB0aGUgcmVhc29ucyBub3QgdG8gc2F0aXNmeSB0aGUgbmVlZCB0byB1cGRhdGUgd2hpdGUgc3Bh Y2UgY2hhbm5lbCBpbmZvcm1hdGlvbiBpbiBbcGF3cyBwcm90b2NvbF0uDQoNCjQpIFRoZSBzZWN1 cml0eSBpcyBub3QgZGlzY3Vzc2VkIGluIGRldGFpbCBpbiBbcGF3cyBmcmFtZXdvcmtdLCB0aGUg c2VjdXJpdHktcmVsYXRlZCBpbmZvcm1hdGlvbiBpcyBub3QgaW5jbHVkZWQgaW4gcGF3cyBsYXll ciwgd2UgY29uc2lkZXIgdGhlIHNlY3VyaXR5IHNob3VsZCBiZSB0b3RhbGx5IGRlYWx0IGluIEhU VFBTLCBUTFMgbGF5ZXIgaXMgaW4gY2hhcmdlIG9mIHRoZSBjb25maWRlbnRpYWxpdHksIGludGVn cml0eSBwcm90ZWN0aW9uIGFuZCBhdXRoZW50aWNhdGlvbi4gU28sIFtwYXdzIGZyYW1ld29ya10g ZG9lcyBub3QgaW5jbHVkZSBzaGFyZWQga2V5IGFuZCBkaWdlc3QgYXV0aGVudGljYXRpb24gaW5m b3JtYXRpb24gaW4geG1sIHNjaGVtZS4gUGxlYXNlIHJlZmVyIHRoZSBmaXJzdCBwb2ludCBmb3Ig dGhpcyBzZWN1cml0eSBjb25zaWRlcmF0aW9uLg0KDQo1KSBBYm91dCB0aGUgdmFsaWRhdGlvbiBw cm9jZWR1cmUsIGluIFtwYXdzIGZyYW1ld29ya10ganVzdCBvbmUgc2xhdmUgZGV2aWNlIHdpbGwg YmUgaW5jbHVkZWQgaW4gZWFjaCB2YWxpZGF0aW9uIHByb2NlZHVyZSwgbm90IGFzIGEgbGlzdCBv ZiBzbGF2ZSBkZXZpY2VzIGRlc2NyaWJlZCBpbiBbcGF3cyBwcm90b2NvbF0uIA0KDQo2KSBBcyB5 b3UgZmlndXJlIG91dCB0aGF0IFtwYXdzIGZyYW1ld29ya10gdXNlcyB4bWwgZm9ybWF0IGRhdGEg bW9kZWwgYW5kIFtwYXdzIHByb3RvY29sXSB1c2VzIEpTT04gZGF0YSBtb2RlLiBJIHRoaW5rIHRo YXQgdGhlc2UgdHdvIHByb3Bvc2FscyBhbGwgd29yayBwYXdzLiBObyBjb21tZW50cyBvbiB0aGlz Lg0KDQo3KSBJIHRoaW5rIHRoYXQgZGlzY292ZXJ5IHByb2NlZHVyZSBtaWdodCBiZSBkaXNjdXNz ZWQgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCB3aGF0ZXZlciB0aGUgbmVlZCBkb2luZyBkaXNjb3Zl cnksIHNvIHRoZXJlIGlzIG9ubHkgYSBzaG9ydCBkaXNjdXNzaW9uIGZvciBkaXNjb3ZlcnkgaW4g W3Bhd3MgZnJhbWV3b3JrXSBhbmQgW3Bhd3MgcHJvdG9jb2xdLg0KDQpCZXN0IHJlZ2FyZHMsDQpa aHUgTGVpDQoNClpodSBMZWkNCkh1YXdlaQ0KV2lyZWxlc3MgbmV0d29yayByZXNlYXJjaCBkZXBh cnRtZW50IA0KRS1tYWlsIGFkZHJlc3M6IGxlaS56aHVAaHVhd2VpLmNvbQ0KUGhvbmU6ICs4Ni0x MC02MDYxMTk2MQ0KTW9iaWxlOiArODYtMTM5MTAxNTcwMjANCg0KLS0tLS3Tyrz+1K28/i0tLS0t DQq3orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBHYWJvci5CYWprb0Bub2tpYS5jb20NCreiy83KsbzkOiAyMDEyxOo31MIyMsjV IDc6NTMNCsrVvP7IyzogUGV0ZXIgTWNDYW5uOyBwYXdzQGlldGYub3JnDQrW98ziOiBbcGF3c10g Y29tbWVudHMgb24gZHJhZnQtd2VpLXBhd3MtZnJhbWV3b3JrDQoNClRoaXMgaXMgYWxzbyBhIHF1 aXRlIHdlbGwgd3JpdHRlbiBkcmFmdCwgd2hpY2ggYWRkcmVzc2VzIHRoZSBzYW1lIHNvbHV0aW9u IHNwYWNlIGFzIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLCB3aXRoIHF1aXRlIHNpZ25pZmlj YW50IHNpbWlsYXJpdGllcyB0byB0aGF0IGRyYWZ0Lg0KDQpUaGUgbWFpbiBkaWZmZXJlbmNlcyBJ IGNvdWxkIG9ic2VydmUgaXMgdGhhdCBpdCBoYXMgc2xpZ2h0bHkgbW9yZSBkZXRhaWxlZCBkZXNj cmlwdGlvbiBvbiB3aGl0ZSBzcGFjZXMgcHVycG9zZSwgaXQgZG9lcyBub3QgZGVmaW5lIHRoZSBJ TlQtUkVRIGFuZCBJTlQtUkVTUCBtZXNzYWdlcyB3aGljaCBkcmFmdC1kYXMtcGF3cyBkb2VzIChh bmQgd2hpY2ggcHVycG9zZSBJIGRpZCBub3QgdW5kZXJzdGFuZCksIGFuZCBpdCB1c2VzIHhtbCBm b3IgdGhlIGRhdGEgbW9kZWwgZGVzY3JpcHRpb24sIHdoaWxlIGRyYWZ0LWRhcy1wYXdzIHVzZXMg anNvbi4NCkJ1dCBhbGwgdGhlIGNvbW1lbnRzIEkgaGFkIG9uIHRoZSBkYXRhIG1vZGVsIGRlc2Ny aWJlZCBpbiBkcmFmdC1kYXMtcGF3cyBhcHBseSBmb3IgdGhpcyBkcmFmdCBhcyB3ZWxsLg0KDQpE dXJpbmcgdGhlIGxhc3QgRjJGIGJvdGggZHJhZnRzIChvciBhIHByZXZpb3VzIHJlaW5jYXJuYXRp b24gb2YgdGhlbSkgd2VyZSBwcmVzZW50ZWQsIGFuZCB0aGVyZSB3YXMgYSByZXF1ZXN0IHRoYXQg dGhlIGF1dGhvcnMgY29tZSB1cCB3aXRoIGEgbWVyZ2VkIGRyYWZ0LCByYXRoZXIgdGhhbiBoYXZp bmcgdHdvIHNlcGFyYXRlIGRyYWZ0cyB3aXRoIHF1aXRlIGJpZyBvdmVybGFwLg0KVGhhdCBkaWQg bm90IGhhcHBlbiBmb3Igc29tZSByZWFzb24sIHNvIHdlJ2xsIHBvc3NpYmx5IG5lZWQgdG8gZGVj aWRlIHdoaWNoIG9uZSBvZiB0aGUgdHdvIHZlcnkgc2ltaWxhciBkcmFmdHMgd2lsbCB0aGUgd2cg cHJvY2VlZCBmb3J3YXJkLiBTbyBJJ2QgZW5jb3VyYWdlIHBlb3BsZSB0byByZWFkIHRoZSBkcmFm dHMgYmVmb3JlIHRoZSBGMkYuDQoNCi0gR2Fib3INCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgUGV0ZXIgTWNDYW5uDQpTZW50OiBUdWVzZGF5LCBK dWx5IDEwLCAyMDEyIDc6MzEgQU0NClRvOiBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBbcGF3c10g TmV3IGRyYWZ0IG9uIGEgcHJvdG9jb2wgZnJhbWV3b3JrIGZvciBQQVdTDQoNCkhpLCBhbGwsDQoN Clllc3RlcmRheSB3ZSBzdWJtaXR0ZWQgYSBkcmFmdCBwcm90b2NvbCBmcmFtZXdvcmsgZm9yIFBB V1MgdGhhdCBkZWZpbmVzIGFuIFhNTCBzY2hlbWEgZm9yIG1lc3NhZ2VzIGFuZCBkYXRhIGVsZW1l bnRzIGJldHdlZW4gYSBtYXN0ZXIgZGV2aWNlIGFuZCBhIGRhdGFiYXNlLiAgWW91IGNhbiBmaW5k IGl0IGhlcmU6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlaS1wYXdzLWZy YW1ld29yay0wMA0KDQpGb3Igbm93IHRoZSBkcmFmdCBpcyBraW5kIG9mIGhhbmQtd2F2eSBhYm91 dCBkYXRhYmFzZSBkaXNjb3ZlcnkgYW5kIHRoZSBzZWN1cml0eSBtb2RlbCwgZXNwZWNpYWxseSB0 aGUgc2VjdXJpdHkgbW9kZWwgZm9yIHZhbGlkYXRpbmcgc2xhdmUgZGV2aWNlcy4NClRoZXNlIGlz c3VlcyBwcm9iYWJseSBuZWVkIHRvIGJlIGFkZHJlc3NlZCBpbiBzZXBhcmF0ZSBkb2N1bWVudHMu DQoNCi0tDQpQZXRlciBKLiBNY0Nhbm4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKFVTQSkNClBldGVy Lk1jQ2FubkBIdWF3ZWkuY29tDQorMSA5MDggNTQxIDM1NjMNClJtLiBDLTAxMDUsIDQwMCBDcm9z c2luZ3MgQmx2ZC4gKDJuZCBmbG9vciksIEJyaWRnZXdhdGVyLCBOSiAgMDg4MDctMjg2MyAgVVNB DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBh d3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= From cuiyang@huawei.com Mon Jul 23 05:47:19 2012 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 972E121F8707 for ; Mon, 23 Jul 2012 05:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 QrUNwzLJbFwL for ; Mon, 23 Jul 2012 05:47:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2AF21F8711 for ; Mon, 23 Jul 2012 05:47:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHZ59768; Mon, 23 Jul 2012 08:47:18 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 05:45:22 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 05:45:24 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.245]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Mon, 23 Jul 2012 20:45:16 +0800 From: Cuiyang To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQ Date: Mon, 23 Jul 2012 12:45:16 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.119] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 12:47:19 -0000 SGkgQWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBzb21lIGNvbW1lbnRzIHRvIHRoaXMg ZHJhZnQsIGZyb20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3Lg0KSG9wZSB0aGF0IGl0IHdpbGwg YmUgaGVscGZ1bC4NCg0KVGhlIFRMUyBhbmQgIkhUVFAgRGlnZXN0IEF1dGgiIGhhdmUgYmVlbiB1 c2VkLCBidXQgc2VlbSB1bmNsZWFyIGZvciBtZS4gQmVzaWRlcywgaXQgaXMgbm90IHJlY29tbWVu ZGVkIHRvIHVzZSB0aGUgbGF0dGVyIGZvciBzb21lIHJlYXNvbnMgbGlzdGVkIGJlbG93Lg0KLSBJ dCBpcyBzYWlkIHRoYXQgdGhlIEhUVFAvVExTIHByb3RvY29sIGlzIGRlcGxveWVkIGZvciBtdXR1 YWwgYXV0aGVudGljYXRpb24uIEhvd2V2ZXIsICJIVFRQIGRpZ2VzdCBhdXRoZW50aWNhdGlvbiIg aXMgYWN0dWFsbHkgdXNlZCBmb3IgYXV0aGVudGljYXRpbmcgdGhlIGRldmljZSwgd2hpY2ggaXMg dHlwaWNhbGx5IHdlYWtlciB0aGFuIG5vcm1hbCBUTFMuIE9ubHkgdGhlIHNlcnZlciBzaWRlIGF1 dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCBieSBUTFMgY2VydGlmaWNhdGUtYmFzZWQgY3J5cHRv IG1ldGhvZC4NCi0gSXQgYXBwZWFycyB0aGF0IGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgaW4gZGlm ZmVyZW50IGxheWVycywgaS5lLiwgZGV2aWNlIGlzIGRvbmUgaW4gUEFXUyBsYXllciBieSAiSFRU UCBkaWdlc3QgYXV0aCIgYW5kIHNlcnZlciBpcyBhY2hpZXZlZCBpbiBUTFMgbGF5ZXIgYnkgY2Vy dGlmaWNhdGUuIEkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IHNlY3VyaXR5IGlzIGRvbmUgaW4gbWl4 ZWQgbGF5ZXJzPw0KLSBJdCBpcyBzYWlkIHRoYXQgY29uZmlkZW50aWFsaXR5IGlzIHByb3RlY3Rl ZCBpbiBIVFRQUyBsYXllciwgYnV0IGlmIGF1dGhlbnRpY2F0aW5nIGRldmljZSBpcyBhY2hpZXZl ZCBpbiBkaWZmZXJlbnQgbGF5ZXIgKGkuZS4gaW4gUEFXUyBsYXllciksIGhvdyBjYW4gdGhlIGRl dmljZSBhbmQgc2VydmVyIG5lZ290aWF0ZSB0aGUgc2Vzc2lvbiBrZXk/DQotIE9yLCBpZiBteSBh Ym92ZSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nIGFuZCBtdXR1YWwgYXV0aGVudGljYXRpb24gaXMg aW5kZWVkIGRvbmUgaW4gVExTIGxheWVyLCB3aHkgZG9lcyBpdCBuZWVkIHRvIGhhdmUgYWRkaXRp b25hbCAiSFRUUCBkaWdlc3QgYXV0aCIgaW4gUEFXUyBsYXllcj8NCi0gIkhUVFAgZGlnZXN0IGF1 dGgiIG9ubHkgcHJvdmlkZXMgYSBoYXNoLWJhc2VkIHByb3RlY3Rpb24gZm9yIHNlY3JldHMgbGlr ZSBwYXNzd29yZCBhbmQgSUQsIGFuZCBpcyBrbm93biB0byBiZSB2dWxuZXJhYmxlIHRvIE1pdE0g KE1hbi1pbi10aGUtTWlkZGxlKSBhdHRhY2tzLiBTaW5jZSBhY2NvcmRpbmcgdG8gdGhlIFBBV1Mg V0cgZG9jdW1lbnQsIGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMt MDYsIENoYXB0ZXIgOCwgdGhyZWF0IDcsIE1pdE0gYXR0YWNrIHNob3VsZCBiZSB0aHdhcnRlZC4g VGhpcyBkcmFmdCB1c2luZyAiSFRUUCBkaWdlc3QgYXV0aCIgb2J2aW91c2x5IGRvZXMgbm90IHNh dGlzZnkgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50Lg0KLSAiSFRUUCBkaWdlc3QgYXV0aCIgZGlm ZmVycyBmcm9tIEhUVFAgb3ZlciBUTFMsIHdoZXJlIHRoZSBmb3JtZXIgcHJvdmlkZXMgbm8gZW5j cnlwdGlvbiBmb3IgY29udGVudCwgYnV0IHRoZSBsYXR0ZXIgY2FuIGVuY3J5cHQgdGhlIGNvbnRl bnQgYnkgUHVibGljIEtleSBjcnlwdG8uIFRodXMgVExTIGlzIHByZWZlcnJlZC4NCi0gIkhUVFAg ZGlnZXN0IGF1dGgiIGRvZXMgbm90IHN1cHBvcnQgSE1BQyBhbGdvcml0aG0gKHNvLWNhbGxlZCBL ZXllZCBIYXNoKSwgdGh1cyBpdCBpcyB5ZXQgYSBsaXR0bGUgcmlza3kgdG8gdXNlIFNIQS0xIHRv IHJlcGxhY2UgY3VycmVudCBNRDUgYWxnb3JpdGhtLCBiZWNhdXNlIE5JU1QgaGFzIG5vdCByZWNv bW1lbmRlZCB0byB1c2UgdGhlIGNvbGxpc2lvbiByZXNpc3RhbmNlIG9mIFNIQS0xIChidXQgSE1B Qy1TSEExIGlzIGZpbmUpLiBJbiBjb250cmFzdCwgVExTIHN1cHBvcnRzIEhNQUMgYW5kIGRvZXMg bm90IGhhdmUgc3VjaCBhIHByb2JsZW0uDQoNCkZyb20gdGhlIGFib3ZlIGFuYWx5c2lzLCBpdCBp cyBjbGVhciB0byBzZWUgdGhhdCB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgb2YgUEFXUyBpcyBu b3Qgc3RyYWlnaHRmb3J3YXJkIGFuZCBuZWVkcyB0byBiZSBjYXJlZnVsbHkgaW52ZXN0aWdhdGVk LCBmb3IgZGVzaWduIGFuZCBpbXBsZW1lbnRhdGlvbi4NCkl0IGlzIGFsc28gdGhlIHJlYXNvbiB3 aHkgd2UgaGF2ZSBzdWJtaXR0ZWQgYW4gaW5kZXBlbmRlbnQgZHJhZnQgZm9yIFBBV1Mgc2VjdXJp dHksIHRvIHByb3ZpZGUgYSBiYXNlIGZvciBkaXNjdXNzaW9uLg0KDQpCUiwNCllhbmcNCj09PT09 PT09PT09PT09PT09PQ0KIFlhbmcgQ3VpLCAgUGguRC4NCiBIdWF3ZWkgVGVjaG5vbG9naWVzDQog Y3VpeWFuZ0BodWF3ZWkuY29tDQoNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBw YXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0N Cj4gR2Fib3IuQmFqa29Abm9raWEuY29tDQo+ILeiy83KsbzkOiAyMDEyxOo31MIyMsjVIDc6MzEN Cj4gytW8/sjLOiBwYXdzQGlldGYub3JnDQo+INb3zOI6IFtwYXdzXSBjb21tZW50cyBvbiBkcmFm dC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCj4gDQo+IEl0IHdvdWxkIGJlIGJlbmVmaWNpYWwg aWYgdGhlcmUgd2VyZSBkaXNjdXNzaW9ucyBvbiB0aGUgZHJhZnRzIHRvIHN1Ym1pdHRlZA0KPiBh aGVhZCBvZiB0aGUgRjJGIHByZXNlbnRhdGlvbnMuDQo+IFRodXMsIEkndmUgdGFrZW4gdGhlIGlu aXRpYXRpdmUgdG8gcmVhZCB0aGUgZHJhZnQgYW5kIHByb3ZpZGUgc29tZSBpbml0aWFsDQo+IGNv bW1lbnRzOg0KPiANCj4gMS4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGUg aW5pdGlhbGl6YXRpb24gcHJvY2VzcyBhbmQgd2h5DQo+IG1lc3NhZ2VzIElOVC1SRVEgYW5kIElO VC1SRVNQIGFyZSBuZWNlc3NhcnkuIFRoZSBjYXBhYmlsaXR5IGV4Y2hhbmdlIGNhbg0KPiBiZSBk b25lIGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuDQo+IFdlIG1heSBldmVuIGNvbnNp ZGVyIG1lcmdpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIHdpdGggdGhlIERCIHF1ZXJ5DQo+ IHByb2Nlc3MsIHRoZXJlIGRvZXNuJ3Qgc2VlbSB0byBiZSBhbnkgcmVhc29uIHRvIGhhdmUgdGhl bSBhcyBzZXBhcmF0ZQ0KPiBtZXNzYWdlcy4NCj4gDQo+IDIuIHlvdSBtYXkgbmVlZCBhIHNlY3Rp b24gd2hlcmUgeW91IG1hcCB5b3VyIG5ld2x5IGRlZmluZWQgbWVzc2FnZXMgdG8NCj4gZXhpc3Rp bmcgaHR0cCBwcm90b2NvbCBtZXNzYWdlcy4gSSBzYXcgdGhhdCB5b3UgaGF2ZSBhbiBleGFtcGxl IHNlY3Rpb24sIGJ1dCBhDQo+IG5vcm1hdGl2ZSBzZWN0aW9uIHdvdWxkIGJlIG1vcmUgZGVzaXJh YmxlLg0KPiANCj4gMy4gdGhlIGRhdGEgbW9kZWwgcGFydCBuZWVkcyBzb21lIG1vcmUgd29yay4g VGhlIHN0cnVjdHVyZSBpcyBub3QgdmVyeSBjbGVhcg0KPiB0byBtZSwgYW5kIHNvbWUgb2YgdGhl IGF0dHJpYnV0ZXMgcmVmZXJlbmNlIG9ic29sZXRlIFJGQy4NCj4gRWcsIFJGQzM4MjUgaXMgcmVm ZXJlbmNlZCBmb3IgdGhlIGxvbmdpdHVkZS9sYXRpdHVkZSBhdHRyaWJ1dGVzLiBJIHRoaW5rIHlv dQ0KPiBzaG91bGQgYmUgYmV0dGVyIG9mIHVzaW5nIGFuIGVsZW1lbnQgZm9yIGdlby1sb2NhdGlv biwgd2l0aCB0aGUgc3RydWN0dXJlIGFzDQo+IGRlZmluZWQgaW4gUkZDNTQ5MSwgYSBzZXBhcmF0 ZSBlbGVtZW50IGZvciB0aGUgY2l2aWMgbG9jYXRpb24sIHdpdGggdGhlDQo+IHN0cnVjdHVyZSBh cyBkZWZpbmVkIGluIFJGQzUxMzksIGV0Yy4NCj4gSW5zdGVhZCBvZiB0aGUgRGV2aWNlT3duZXIg b2JqZWN0LCBJIHdvdWxkIHVzZSBhIHZDYXJkIGVsZW1lbnQsIHdpdGggdGhlDQo+IHN0cnVjdHVy ZSBhcyBkZWZpbmVkIGluIFJGQzI0MjYuDQo+IFlvdSBtYXkgYWxzbyBuZWVkIGFuIGlDYWxlbmRh ciBlbGVtZW50IChSRkM1NTQ1KSB0byBzcGVjaWZ5IHRoZSBjaGFubmVsDQo+IGF2YWlsYWJpbGl0 eSB0aW1lIChlZywgd2hlbiB0aGUgY2hhbm5lbCBpcyBub3QgYXZhaWxhYmxlIGZvciB0aGUgZnVs bCAyNEgpLg0KPiBFdGMuDQo+IA0KPiBNb3JlIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiAtIEdh Ym9yDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGF3cy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gZXh0IERhcywgU3ViaXINCj4gU2VudDogU2F0dXJkYXksIEp1bHkgMTQsIDIwMTIgNzoz NiBBTQ0KPiBUbzogcGF3c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbcGF3c10gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+ IA0KPiBEZWFyIENoYWlycywNCj4gV2UgaGF2ZSB1cGRhdGVkIG91ciBkcmFmdCBhbmQgd291bGQg bGlrZSB0byByZXF1ZXN0IGEgc2xvdCBpbiBJRVRGLTg0IHRvDQo+IHByZXNlbnQgaXQuDQo+IA0K PiBSZWdhcmRzLA0KPiBfU3ViaXINCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NCj4gU2VudDogU2F0dXJkYXksIEp1bHkgMTQsIDIwMTIgMTA6MzAgQU0NCj4gVG86 IERhcywgU3ViaXINCj4gQ2M6IGptYWx5YXJAdGVsY29yZGlhLmNvbTsgZC5qb3NseW5Ac3BlY3Ry dW1icmlkZ2UuY29tDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkN Cj4gc3VibWl0dGVkIGJ5IFN1YmlyIERhcyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sDQo+IFJldmlzaW9u OgkgMDINCj4gVGl0bGU6CQkgRGV2aWNlIHRvIERhdGFiYXNlIFByb3RvY29sIGZvciBXaGl0ZSBT cGFjZQ0KPiBDcmVhdGlvbiBkYXRlOgkgMjAxMi0wNy0xNA0KPiBXRyBJRDoJCSBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAzMg0KPiBVUkw6DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0K PiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt ZGFzLXBhd3MtcHJvdG9jb2wNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMg0KPiBEaWZmOiAgICAgICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wt MDINCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgYFBy b3RvY29sIHRvIEFjY2VzcyBXaGl0ZSBTcGFjZSBkYXRhYmFzZQ0KPiAgICAoUEFXUyknIHRoYXQg dXNlcyBIVFRQL1RMUyBhcyB0cmFuc3BvcnQuICBUaGUgcHJvdG9jb2wgaXMgdXNlZCBmb3INCj4g ICAgcmV0cmlldmluZyB0aGUgbmVjZXNzYXJ5IFRWIHdoaXRlIHNwYWNlIGluZm9ybWF0aW9uIChl LmcuLCBjaGFubmVsLA0KPiAgICBmcmVxdWVuY3ksIHRyYW5zbWl0dGVkIHBvd2VyKSBhdCBhIGdp dmVuIGxvY2F0aW9uIGFuZCB0aW1lIGZyb20gYQ0KPiAgICBkYXRhYmFzZSB0aGF0IGlzIG9wZXJh dGluZyB1bmRlciBhIHJlZ3VsYXRvcnkgZG9tYWluLiAgVGhlIGRvY3VtZW50DQo+ICAgIGluY2x1 ZGVzIHRoZSBwcm90b2NvbCBmdW5jdGlvbmFsaXRpZXMsIGl0cyBlbGVtZW50cywgY29ycmVzcG9u ZGluZw0KPiAgICBkYXRhIG1vZGVsIGFuZCByZWNvbW1lbmRzIGl0cyBlbmNvZGluZyBzY2hlbWUu DQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwYXdzIG1haWxpbmcgbGlzdA0K PiBwYXdzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBwYXdzIG1haWxpbmcgbGlzdA0KPiBwYXdzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K From sdas@appcomsci.com Mon Jul 23 16:19:15 2012 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 3D59511E80E7 for ; Mon, 23 Jul 2012 16:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 dl6Yb7GPJx8q for ; Mon, 23 Jul 2012 16:19:14 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4901221F85CC for ; Mon, 23 Jul 2012 16:19:14 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q6NNJDnW018272; Mon, 23 Jul 2012 19:19:13 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q6NNJCpE030788; Mon, 23 Jul 2012 19:19:12 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Mon, 23 Jul 2012 19:19:12 -0400 From: "Das, Subir" To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBlXaew Date: Mon, 23 Jul 2012 23:19:11 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 23:19:15 -0000 Thanks for your comments. I will answer your following point that was not c= overed by John and Peter:=20 2. you may need a section where you map your newly defined messages to exis= ting http protocol messages. I saw that you have an example section, but a = normative section would be more desirable. SD> Yes, we would be happy do that in next version.=20 -Subir=20 -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: Saturday, July 21, 2012 7:31 PM To: paws@ietf.org Subject: [paws] comments on draft-das-paws-protocol-02.txt It would be beneficial if there were discussions on the drafts to submitted= ahead of the F2F presentations. Thus, I've taken the initiative to read the draft and provide some initial = comments: 1. I do not understand the purpose of the initialization process and why me= ssages INT-REQ and INT-RESP are necessary. The capability exchange can be d= one during the registration process. We may even consider merging the registration process with the DB query pro= cess, there doesn't seem to be any reason to have them as separate messages= . 2. you may need a section where you map your newly defined messages to exis= ting http protocol messages. I saw that you have an example section, but a = normative section would be more desirable. 3. the data model part needs some more work. The structure is not very clea= r to me, and some of the attributes reference obsolete RFC.=20 Eg, RFC3825 is referenced for the longitude/latitude attributes. I think yo= u should be better of using an element for geo-location, with the structure= as defined in RFC5491, a separate element for the civic location, with the= structure as defined in RFC5139, etc. Instead of the DeviceOwner object, I would use a vCard element, with the st= ructure as defined in RFC2426. You may also need an iCalendar element (RFC5545) to specify the channel ava= ilability time (eg, when the channel is not available for the full 24H). Etc. More comments are welcome. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Das, Subir Sent: Saturday, July 14, 2012 7:36 AM To: paws@ietf.org Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-02= .txt Dear Chairs, We have updated our draft and would like to request a slot in IETF-84 to pr= esent it. Regards,=20 _Subir=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Saturday, July 14, 2012 10:30 AM To: Das, Subir Cc: jmalyar@telcordia.com; d.joslyn@spectrumbridge.com Subject: New Version Notification for draft-das-paws-protocol-02.txt A new version of I-D, draft-das-paws-protocol-02.txt has been successfully = submitted by Subir Das and posted to the IETF repository. Filename: draft-das-paws-protocol Revision: 02 Title: Device to Database Protocol for White Space Creation date: 2012-07-14 WG ID: Individual Submission Number of pages: 32 URL: http://www.ietf.org/internet-drafts/draft-das-paws-protoco= l-02.txt Status: http://datatracker.ietf.org/doc/draft-das-paws-protocol Htmlized: http://tools.ietf.org/html/draft-das-paws-protocol-02 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-das-paws-protoc= ol-02 Abstract: This document describes the `Protocol to Access White Space database (PAWS)' that uses HTTP/TLS as transport. The protocol is used for retrieving the necessary TV white space information (e.g., channel, frequency, transmitted power) at a given location and time from a database that is operating under a regulatory domain. The document includes the protocol functionalities, its elements, corresponding data model and recommends its encoding scheme. = =20 The IETF Secretariat _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From sdas@appcomsci.com Mon Jul 23 16:46:13 2012 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 C974B11E80F4 for ; Mon, 23 Jul 2012 16:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=-2.064, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 9Et2JDZsHIuR for ; Mon, 23 Jul 2012 16:46:11 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id CFB5D11E80F1 for ; Mon, 23 Jul 2012 16:46:04 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q6NNjxBc019781; Mon, 23 Jul 2012 19:46:01 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q6NNjwSh030915; Mon, 23 Jul 2012 19:45:58 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Mon, 23 Jul 2012 19:45:58 -0400 From: "Das, Subir" To: Cuiyang , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQAB/KozA= Date: Mon, 23 Jul 2012 23:45:57 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 23:46:14 -0000 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBTb21lIGFuc3dlcnMgaW5saW5lLg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3VpeWFuZw0KU2VudDogTW9uZGF5 LCBKdWx5IDIzLCAyMDEyIDg6NDUgQU0NClRvOiBHYWJvci5CYWprb0Bub2tpYS5jb207IHBhd3NA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF3c10gY29tbWVudHMgb24gZHJhZnQtZGFzLXBhd3Mt cHJvdG9jb2wtMDIudHh0DQoNCkhpIEFsbCwNCg0KSSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgc29t ZSBjb21tZW50cyB0byB0aGlzIGRyYWZ0LCBmcm9tIGEgc2VjdXJpdHkgcG9pbnQgb2Ygdmlldy4N CkhvcGUgdGhhdCBpdCB3aWxsIGJlIGhlbHBmdWwuDQoNClRoZSBUTFMgYW5kICJIVFRQIERpZ2Vz dCBBdXRoIiBoYXZlIGJlZW4gdXNlZCwgYnV0IHNlZW0gdW5jbGVhciBmb3IgbWUuIEJlc2lkZXMs IGl0IGlzIG5vdCByZWNvbW1lbmRlZCB0byB1c2UgdGhlIGxhdHRlciBmb3Igc29tZSByZWFzb25z IGxpc3RlZCBiZWxvdy4NCi0gSXQgaXMgc2FpZCB0aGF0IHRoZSBIVFRQL1RMUyBwcm90b2NvbCBp cyBkZXBsb3llZCBmb3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLiANCg0KU0Q+IFRoaXMgaXMgbm90 IGNvcnJlY3QuIA0KDQpIb3dldmVyLCAiSFRUUCBkaWdlc3QgYXV0aGVudGljYXRpb24iIGlzIGFj dHVhbGx5IHVzZWQgZm9yIGF1dGhlbnRpY2F0aW5nIHRoZSBkZXZpY2UsIA0KDQpTRD4gIERpZ2Vz dCBBdXRoZW50aWNhdGlvbiBpcyB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGF0IHRo ZSBQQVdTIGxheWVyLiANCg0Kd2hpY2ggaXMgdHlwaWNhbGx5IHdlYWtlciB0aGFuIG5vcm1hbCBU TFMuIA0KDQpTRD4gV2h5IGlzIGl0IHdlYWtlcj8gDQoNCk9ubHkgdGhlIHNlcnZlciBzaWRlIGF1 dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCBieSBUTFMgY2VydGlmaWNhdGUtYmFzZWQgY3J5cHRv IG1ldGhvZC4NCi0gSXQgYXBwZWFycyB0aGF0IGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgaW4gZGlm ZmVyZW50IGxheWVycywgaS5lLiwgZGV2aWNlIGlzIGRvbmUgaW4gUEFXUyBsYXllciBieSAiSFRU UCBkaWdlc3QgYXV0aCIgYW5kIHNlcnZlciBpcyBhY2hpZXZlZCBpbiBUTFMgbGF5ZXIgYnkgY2Vy dGlmaWNhdGUuIA0KDQpTRD4gWWVzLCBhdXRoZW50aWNhdGlvbiBpcyBkb25lIGF0IHRoZSBQQVdT IGxheWVyIGJ5IHVzaW5nIGRpZ2VzdCBhdXRoZW50aWNhdGlvbi4gDQoNCkkgZG8gbm90IHVuZGVy c3RhbmQgd2h5IHNlY3VyaXR5IGlzIGRvbmUgaW4gbWl4ZWQgbGF5ZXJzPw0KDQotIEl0IGlzIHNh aWQgdGhhdCBjb25maWRlbnRpYWxpdHkgaXMgcHJvdGVjdGVkIGluIEhUVFBTIGxheWVyLCBidXQg aWYgYXV0aGVudGljYXRpbmcgZGV2aWNlIGlzIGFjaGlldmVkIGluIGRpZmZlcmVudCBsYXllciAo aS5lLiBpbiBQQVdTIGxheWVyKSwgaG93IGNhbiB0aGUgZGV2aWNlIGFuZCBzZXJ2ZXIgbmVnb3Rp YXRlIHRoZSBzZXNzaW9uIGtleT8NCg0KU0Q+IER1cmluZyBub3JtYWwgVExTIG5lZ290aWF0aW9u LiANCg0KLSBPciwgaWYgbXkgYWJvdmUgdW5kZXJzdGFuZGluZyBpcyB3cm9uZyBhbmQgbXV0dWFs IGF1dGhlbnRpY2F0aW9uIGlzIGluZGVlZCBkb25lIGluIFRMUyBsYXllciwgd2h5IGRvZXMgaXQg bmVlZCB0byBoYXZlIGFkZGl0aW9uYWwgIkhUVFAgZGlnZXN0IGF1dGgiIGluIFBBV1MgbGF5ZXI/ DQoNClNEPiBPbmx5IGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBkb25lIGF0IHRoZSBQQVdTIGxh eWVyLiBPZiBjb3Vyc2UgY2xpZW50IGF1dGggY2FuIGJlIGRvbmUgYXQgdGhlIFRMUyBsYXllci4g VGhlbiBvbmUgbmVlZHMgdG8gaGF2ZSBjaGFubmVsIGJpbmRpbmcgYW5kIHRoYXQncyBhbm90aGVy IGFwcHJvYWNoLiAgIA0KDQotICJIVFRQIGRpZ2VzdCBhdXRoIiBvbmx5IHByb3ZpZGVzIGEgaGFz aC1iYXNlZCBwcm90ZWN0aW9uIGZvciBzZWNyZXRzIGxpa2UgcGFzc3dvcmQgYW5kIElELCBhbmQg aXMga25vd24gdG8gYmUgdnVsbmVyYWJsZSB0byBNaXRNIChNYW4taW4tdGhlLU1pZGRsZSkgYXR0 YWNrcy4gU2luY2UgYWNjb3JkaW5nIHRvIHRoZSBQQVdTIFdHIGRvY3VtZW50LCBkcmFmdC1pZXRm LXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTA2LCBDaGFwdGVyIDgsIHRocmVhdCA3 LCBNaXRNIGF0dGFjayBzaG91bGQgYmUgdGh3YXJ0ZWQuIFRoaXMgZHJhZnQgdXNpbmcgIkhUVFAg ZGlnZXN0IGF1dGgiIG9idmlvdXNseSBkb2VzIG5vdCBzYXRpc2Z5IHRoZSBzZWN1cml0eSByZXF1 aXJlbWVudC4NCg0KU0Q+ICBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoaXMuIEhUVFAvVExTIGlzIHVz ZWQgaW4gb3VyIHNjaGVtZS4gDQoNCi0gIkhUVFAgZGlnZXN0IGF1dGgiIGRpZmZlcnMgZnJvbSBI VFRQIG92ZXIgVExTLCB3aGVyZSB0aGUgZm9ybWVyIHByb3ZpZGVzIG5vIGVuY3J5cHRpb24gZm9y IGNvbnRlbnQsIGJ1dCB0aGUgbGF0dGVyIGNhbiBlbmNyeXB0IHRoZSBjb250ZW50IGJ5IFB1Ymxp YyBLZXkgY3J5cHRvLiBUaHVzIFRMUyBpcyBwcmVmZXJyZWQuDQotICJIVFRQIGRpZ2VzdCBhdXRo IiBkb2VzIG5vdCBzdXBwb3J0IEhNQUMgYWxnb3JpdGhtIChzby1jYWxsZWQgS2V5ZWQgSGFzaCks IHRodXMgaXQgaXMgeWV0IGEgbGl0dGxlIHJpc2t5IHRvIHVzZSBTSEEtMSB0byByZXBsYWNlIGN1 cnJlbnQgTUQ1IGFsZ29yaXRobSwgYmVjYXVzZSBOSVNUIGhhcyBub3QgcmVjb21tZW5kZWQgdG8g dXNlIHRoZSBjb2xsaXNpb24gcmVzaXN0YW5jZSBvZiBTSEEtMSAoYnV0IEhNQUMtU0hBMSBpcyBm aW5lKS4gSW4gY29udHJhc3QsIFRMUyBzdXBwb3J0cyBITUFDIGFuZCBkb2VzIG5vdCBoYXZlIHN1 Y2ggYSBwcm9ibGVtLg0KDQpTRD4gWWVzIGl0IHNob3VsZCBiZSBITUFDLVNIQTEuICANCg0KRnJv bSB0aGUgYWJvdmUgYW5hbHlzaXMsIGl0IGlzIGNsZWFyIHRvIHNlZSB0aGF0IHRoZSBzZWN1cml0 eSBhbmQgcHJpdmFjeSBvZiBQQVdTIGlzIG5vdCBzdHJhaWdodGZvcndhcmQgYW5kIG5lZWRzIHRv IGJlIGNhcmVmdWxseSBpbnZlc3RpZ2F0ZWQsIGZvciBkZXNpZ24gYW5kIGltcGxlbWVudGF0aW9u Lg0KSXQgaXMgYWxzbyB0aGUgcmVhc29uIHdoeSB3ZSBoYXZlIHN1Ym1pdHRlZCBhbiBpbmRlcGVu ZGVudCBkcmFmdCBmb3IgUEFXUyBzZWN1cml0eSwgdG8gcHJvdmlkZSBhIGJhc2UgZm9yIGRpc2N1 c3Npb24uDQoNCkJSLA0KWWFuZw0KPT09PT09PT09PT09PT09PT09DQogWWFuZyBDdWksICBQaC5E Lg0KIEh1YXdlaSBUZWNobm9sb2dpZXMNCiBjdWl5YW5nQGh1YXdlaS5jb20NCg0KDQo+IC0tLS0t 08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPiBHYWJvci5CYWprb0Bub2tpYS5jb20NCj4gt6LL zcqxvOQ6IDIwMTLE6jfUwjIyyNUgNzozMQ0KPiDK1bz+yMs6IHBhd3NAaWV0Zi5vcmcNCj4g1vfM 4jogW3Bhd3NdIGNvbW1lbnRzIG9uIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPiAN Cj4gSXQgd291bGQgYmUgYmVuZWZpY2lhbCBpZiB0aGVyZSB3ZXJlIGRpc2N1c3Npb25zIG9uIHRo ZSBkcmFmdHMgdG8gDQo+IHN1Ym1pdHRlZCBhaGVhZCBvZiB0aGUgRjJGIHByZXNlbnRhdGlvbnMu DQo+IFRodXMsIEkndmUgdGFrZW4gdGhlIGluaXRpYXRpdmUgdG8gcmVhZCB0aGUgZHJhZnQgYW5k IHByb3ZpZGUgc29tZSANCj4gaW5pdGlhbA0KPiBjb21tZW50czoNCj4gDQo+IDEuIEkgZG8gbm90 IHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhlIGluaXRpYWxpemF0aW9uIHByb2Nlc3MgYW5k IA0KPiB3aHkgbWVzc2FnZXMgSU5ULVJFUSBhbmQgSU5ULVJFU1AgYXJlIG5lY2Vzc2FyeS4gVGhl IGNhcGFiaWxpdHkgDQo+IGV4Y2hhbmdlIGNhbiBiZSBkb25lIGR1cmluZyB0aGUgcmVnaXN0cmF0 aW9uIHByb2Nlc3MuDQo+IFdlIG1heSBldmVuIGNvbnNpZGVyIG1lcmdpbmcgdGhlIHJlZ2lzdHJh dGlvbiBwcm9jZXNzIHdpdGggdGhlIERCIA0KPiBxdWVyeSBwcm9jZXNzLCB0aGVyZSBkb2Vzbid0 IHNlZW0gdG8gYmUgYW55IHJlYXNvbiB0byBoYXZlIHRoZW0gYXMgDQo+IHNlcGFyYXRlIG1lc3Nh Z2VzLg0KPiANCj4gMi4geW91IG1heSBuZWVkIGEgc2VjdGlvbiB3aGVyZSB5b3UgbWFwIHlvdXIg bmV3bHkgZGVmaW5lZCBtZXNzYWdlcyB0byANCj4gZXhpc3RpbmcgaHR0cCBwcm90b2NvbCBtZXNz YWdlcy4gSSBzYXcgdGhhdCB5b3UgaGF2ZSBhbiBleGFtcGxlIA0KPiBzZWN0aW9uLCBidXQgYSBu b3JtYXRpdmUgc2VjdGlvbiB3b3VsZCBiZSBtb3JlIGRlc2lyYWJsZS4NCj4gDQo+IDMuIHRoZSBk YXRhIG1vZGVsIHBhcnQgbmVlZHMgc29tZSBtb3JlIHdvcmsuIFRoZSBzdHJ1Y3R1cmUgaXMgbm90 IHZlcnkgDQo+IGNsZWFyIHRvIG1lLCBhbmQgc29tZSBvZiB0aGUgYXR0cmlidXRlcyByZWZlcmVu Y2Ugb2Jzb2xldGUgUkZDLg0KPiBFZywgUkZDMzgyNSBpcyByZWZlcmVuY2VkIGZvciB0aGUgbG9u Z2l0dWRlL2xhdGl0dWRlIGF0dHJpYnV0ZXMuIEkgDQo+IHRoaW5rIHlvdSBzaG91bGQgYmUgYmV0 dGVyIG9mIHVzaW5nIGFuIGVsZW1lbnQgZm9yIGdlby1sb2NhdGlvbiwgd2l0aCANCj4gdGhlIHN0 cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJGQzU0OTEsIGEgc2VwYXJhdGUgZWxlbWVudCBmb3IgdGhl IGNpdmljIA0KPiBsb2NhdGlvbiwgd2l0aCB0aGUgc3RydWN0dXJlIGFzIGRlZmluZWQgaW4gUkZD NTEzOSwgZXRjLg0KPiBJbnN0ZWFkIG9mIHRoZSBEZXZpY2VPd25lciBvYmplY3QsIEkgd291bGQg dXNlIGEgdkNhcmQgZWxlbWVudCwgd2l0aCANCj4gdGhlIHN0cnVjdHVyZSBhcyBkZWZpbmVkIGlu IFJGQzI0MjYuDQo+IFlvdSBtYXkgYWxzbyBuZWVkIGFuIGlDYWxlbmRhciBlbGVtZW50IChSRkM1 NTQ1KSB0byBzcGVjaWZ5IHRoZSANCj4gY2hhbm5lbCBhdmFpbGFiaWxpdHkgdGltZSAoZWcsIHdo ZW4gdGhlIGNoYW5uZWwgaXMgbm90IGF2YWlsYWJsZSBmb3IgdGhlIGZ1bGwgMjRIKS4NCj4gRXRj Lg0KPiANCj4gTW9yZSBjb21tZW50cyBhcmUgd2VsY29tZS4NCj4gLSBHYWJvcg0KPiANCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPiBPZiBleHQgRGFz LCBTdWJpcg0KPiBTZW50OiBTYXR1cmRheSwgSnVseSAxNCwgMjAxMiA3OjM2IEFNDQo+IFRvOiBw YXdzQGlldGYub3JnDQo+IFN1YmplY3Q6IFtwYXdzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciANCj4gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+IA0KPiBEZWFyIENo YWlycywNCj4gV2UgaGF2ZSB1cGRhdGVkIG91ciBkcmFmdCBhbmQgd291bGQgbGlrZSB0byByZXF1 ZXN0IGEgc2xvdCBpbiBJRVRGLTg0IA0KPiB0byBwcmVzZW50IGl0Lg0KPiANCj4gUmVnYXJkcywN Cj4gX1N1YmlyDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ IFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDE0LCAyMDEyIDEwOjMwIEFNDQo+IFRvOiBEYXMsIFN1Ymly DQo+IENjOiBqbWFseWFyQHRlbGNvcmRpYS5jb207IGQuam9zbHluQHNwZWN0cnVtYnJpZGdlLmNv bQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRhcy1wYXdz LXByb3RvY29sLTAyLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1k YXMtcGF3cy1wcm90b2NvbC0wMi50eHQgaGFzIGJlZW4gDQo+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgU3ViaXIgRGFzIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+ IEZpbGVuYW1lOgkgZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wNCj4gUmV2aXNpb246CSAwMg0KPiBU aXRsZToJCSBEZXZpY2UgdG8gRGF0YWJhc2UgUHJvdG9jb2wgZm9yIFdoaXRlIFNwYWNlDQo+IENy ZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTE0DQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KPiBOdW1iZXIgb2YgcGFnZXM6IDMyDQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+IFN0YXR1czog ICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kYXMtcGF3cy1w cm90b2NvbA0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyDQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMg0KPiANCj4g QWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBgUHJvdG9jb2wgdG8g QWNjZXNzIFdoaXRlIFNwYWNlIGRhdGFiYXNlDQo+ICAgIChQQVdTKScgdGhhdCB1c2VzIEhUVFAv VExTIGFzIHRyYW5zcG9ydC4gIFRoZSBwcm90b2NvbCBpcyB1c2VkIGZvcg0KPiAgICByZXRyaWV2 aW5nIHRoZSBuZWNlc3NhcnkgVFYgd2hpdGUgc3BhY2UgaW5mb3JtYXRpb24gKGUuZy4sIGNoYW5u ZWwsDQo+ICAgIGZyZXF1ZW5jeSwgdHJhbnNtaXR0ZWQgcG93ZXIpIGF0IGEgZ2l2ZW4gbG9jYXRp b24gYW5kIHRpbWUgZnJvbSBhDQo+ICAgIGRhdGFiYXNlIHRoYXQgaXMgb3BlcmF0aW5nIHVuZGVy IGEgcmVndWxhdG9yeSBkb21haW4uICBUaGUgZG9jdW1lbnQNCj4gICAgaW5jbHVkZXMgdGhlIHBy b3RvY29sIGZ1bmN0aW9uYWxpdGllcywgaXRzIGVsZW1lbnRzLCBjb3JyZXNwb25kaW5nDQo+ICAg IGRhdGEgbW9kZWwgYW5kIHJlY29tbWVuZHMgaXRzIGVuY29kaW5nIHNjaGVtZS4NCj4gDQo+IA0K PiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHBhd3MgbWFpbGluZyBsaXN0DQo+IHBhd3NAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHBhd3MgbWFp bGluZyBsaXN0DQo+IHBhd3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wYXdzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K From mksaji@yahoo.com Mon Jul 23 20:09:49 2012 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 4D7A821F84A6 for ; Mon, 23 Jul 2012 20:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.62 X-Spam-Level: X-Spam-Status: No, score=0.62 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, REPTO_QUOTE_YAHOO=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 Ot3YTtS4vZyd for ; Mon, 23 Jul 2012 20:09:47 -0700 (PDT) Received: from nm20-vm2.bullet.mail.ne1.yahoo.com (nm20-vm2.bullet.mail.ne1.yahoo.com [98.138.91.208]) by ietfa.amsl.com (Postfix) with SMTP id 8018621F84EC for ; Mon, 23 Jul 2012 20:09:47 -0700 (PDT) Received: from [98.138.90.53] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 24 Jul 2012 03:09:43 -0000 Received: from [98.138.89.161] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 24 Jul 2012 03:09:43 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 24 Jul 2012 03:09:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 469396.46381.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 75286 invoked by uid 60001); 24 Jul 2012 03:09:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1343099383; bh=bbZWd3ZF84lGl3h0cEgfj+MK3sLR+ChQZxAhWnp9FM4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=t57JnxBh+IfY+z1+dZkWXm4OT828Fvlo+XnYYq6xg9AzdIwXz62gtYSV27OLu4JKwhCZXlh8gBxn/JUdRGNS+TKPiepnTaOXhmWW4WIJHtQ0uX5+H1hLP1PVgX28Gop5VQT1MKNDMCkE59EG3U8HXk897yjW2FJXuVu/nLMNgAo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=eyB53apuJXDmkA0jPwBBWGdwKP5UaUpTTc6tyk3l3H04PRFN6bHXe4Ta+/zry4UOWNcnnWRt5DDSeTlaFdohyQxrjFDKMcO4v0/GB2QQH1vMEHMacht1aCrRK17Yy1L5v3Q5xT61ln2DJ1oIdbCLasTqX9N/d3yY8UcYUbwl2PE=; X-YMail-OSG: iLahI4YVM1k.iFxLv3FI4clwehLbasF3yZ0uorqhpw6sess Fs_0By8AfSTAmpXJwnA3KtEF9nWscUq_.cOjWkxCsRvXU.xgM8URzp557O9O 2i02dV95DX820EMCCSbdW7guYhJRt3YCVcEtt.3WiyqV.7VqiUGhcfS0nWrJ GoLKXVVBSblJYfXH4id_Ud8m.1pDLX_jw.QlmFOesnxNidzRtcnB.X2raJP6 EI.z71jLfLDaeSBQV9s9S_JdcDOkmTCzulIh0xdAdBHaH8fjUzlk8Pfb_CM3 InPGvGXW3NunFaULdimlUKuTKNEC5VOCm4EBtBpmJ_glnx_Liof4o182.qCH axvwcQyPr7PPRqYVg21IPAi6IDOArsrFhnHeOVBaE_Hu0_fsy3mKtwUC_Gez STYVOoazT0NvQPzx3crpLImuTXZkuyn1PLMcsZS65t2V3Y9AzsRPNjAUrQIw 5V.LQAgA7aGXv0o9UiH2AGDDvnzqS8rnco6RY681qmBJFuyJZ7OPyjz7GgSu dlUlAp3.TrMN1WyBjwQU9_WSfUBHSR4KBdqsgQrE65B5KbVBXARlGcHQLpzS g3QcaJ6bBfSfYvrqxGaerRo5EFLTennzxDzB2s5PtLuxI68lxCQ-- Received: from [117.192.24.136] by web120305.mail.ne1.yahoo.com via HTTP; Mon, 23 Jul 2012 20:09:43 PDT X-Mailer: YahooMailWebService/0.8.120.356233 Message-ID: <1343099383.72739.YahooMailNeo@web120305.mail.ne1.yahoo.com> Date: Mon, 23 Jul 2012 20:09:43 -0700 (PDT) From: "M.K.Sajeev" To: "paws@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1278015569-280871868-1343099383=:72739" Subject: [paws] http://tools.ietf.org/id/draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "M.K.Sajeev" List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 03:09:49 -0000 ---1278015569-280871868-1343099383=:72739 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=A0=0AFew comments on the protocol spec:=0A=A0=0A1. Use of term 'devi= ce' in the doc confuses in many places whether it is master or slave? Term = 'master' while refering master device looks better, leaving device for slav= e. As I understand master perhaps will be an equipment than device.=0A2. Ca= n DB initiate any kind of mesage exchanges with master, an active db scenar= io? For example polling whether a registered master is alive, or any failur= e scenarios etc?=0A=0A3. Is there a de-registration or destroy message flow= , when master shuts down or go inoperative?=0A=0A4. Is it sensible to have = all protocol messages having a common prefix like PAWS or similar? Eg:- PAW= S-REG-REQ, PAWS-INT-REQ, etc.=0A=0A6. Section 6.1: Data element optional/ma= ndatory description can follow the standard conventions described in sectio= n 1 of the spec=0A=0A=0ABest Regards,=0A=A0=0ASajeev Manikkoth=0AMobile: +9= 18792292002=0AEmail: mksaji@ieee.org=0Ahttp://www.linkedin.com/in/mksajeev ---1278015569-280871868-1343099383=:72739 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=
 
Few comments on the protocol= spec:
 
1. Use of term = 'device' in the doc confuses in many places whether it is master or slave? = Term 'master' while refering master device looks better, leaving device for= slave. As I understand master perhaps will be an equipment than device.

2. Can DB initiate any kind of mesage exchanges wi= th master, an active db scenario? For example polling whether a registered = master is alive, or any failure scenarios etc?

3. Is there a = de-registration or destroy message flow, when master shuts down or go inope= rative?

4. Is it sensible to have all protocol messages havin= g a common prefix like PAWS or similar? Eg:- PAWS-REG-REQ, PAWS-INT-REQ, etc.

6. Section 6.1: Data element optional/man= datory description can follow the standard conventions described in section= 1 of the spec
 
Best Regards,
 <= /div>
Sajeev Mani= kkoth
Mobile: +918792292002
Email: mksaji@ieee.org
http://= www.linkedin.com/in/mksajeev

---1278015569-280871868-1343099383=:72739-- From cuiyang@huawei.com Tue Jul 24 05:43:03 2012 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 E272D21F8647 for ; Tue, 24 Jul 2012 05:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 5gvF9m7MJNIu for ; Tue, 24 Jul 2012 05:43:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 53CC921F863B for ; Tue, 24 Jul 2012 05:43:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIA47159; Tue, 24 Jul 2012 08:43:02 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 05:41:08 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 05:41:10 -0700 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.245]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Tue, 24 Jul 2012 20:41:04 +0800 From: Cuiyang To: "Das, Subir" , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQAB/KozAAGpqGMA== Date: Tue, 24 Jul 2012 12:41:03 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2163684DD31@SZXEML508-MBS.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.119] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 12:43:04 -0000 VGhhbmtzIGZvciB5b3VyIGFuc3dlcnMuDQoNCkJ1dCB0aGVuIEkgcmVhbGl6ZWQgdGhhdCB0aGUg cHJvcG9zYWwgaXMgdXNpbmcgYSBraW5kIG9mIHR3by1sYXllciBhdXRoZW50aWNhdGlvbiBwcm90 b2NvbHMsIHMudC4gYW4gb3V0ZXIgbGF5ZXIgcHJvdG9jb2wgb2YgVExTIGF1dGhlbnRpY2F0aW9u IG9mIHNlcnZlciAoZGF0YWJhc2UpLCBhbmQgYW4gaW5uZXIgbGF5ZXIgcHJvdG9jb2wgYXV0aGVu dGljYXRpb24gb2YgY2xpZW50IChNYXN0ZXIgZGV2aWNlKS4NClVuZm9ydHVuYXRlbHksIGl0IGlz IGtub3duIHRoYXQgc3VjaCBhIG1peGVkIG1vZGUgb2YgYXV0aGVudGljYXRpb24gaXMgdnVsbmVy YWJsZSB0byBNaXRNLg0KSSBhbSBzZXJpb3VzbHkgY29uY2VybmVkIHRoYXQgdGhpcyBkcmFmdCBp cyBhbHNvIGluIHRoZSBjYXNlLg0KDQpJbiBwYXJ0aWN1bGFyLCBzdWNoIGEgY29tYmluYXRpb24g b2YgVExTIG9mIHNlcnZlciBhdXRoZW50aWNhdGlvbiBhbmQgSFRUUCBkaWdlc3QgYXV0aGVudGlj YXRpb24gb2YgY2xpZW50LCBpcyByYWlzZWQgYXMgYW4gaW5zZWN1cmUgZXhhbXBsZSBpbiBzZXZl cmFsIHBsYWNlcywgaW5jbHVkaW5nOg0KLSBSRkMgNDE2OQ0KLSBBc29rYW4tTmllbWktTnliZXJn IGF0dGFjayAyMDAyLCBodHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMDIvMTYzLnBkZg0KDQpRdW90 ZWQgZnJvbSBSRkMgNDE2OSwgU2VjIDQuMywgTWFuLWluLXRoZS1NaWRkbGUgQXR0YWNrLA0KCSIg Rm9yIGV4YW1wbGUsIHRoZSB1c2Ugb2YgVExTIHdpdGggSFRUUCBEaWdlc3QgYXV0aGVudGljYXRp b24gKGkuZS4sDQogICBUTFMgZm9yIHNlcnZlciBhdXRoZW50aWNhdGlvbiwgYW5kIHN1YnNlcXVl bnQgdXNlIG9mIEhUVFAgRGlnZXN0IGZvcg0KICAgY2xpZW50IGF1dGhlbnRpY2F0aW9uKSBpcyBh biBpbnN0YW5jZSBvZiBzdWNoIHNjZW5hcmlvLiAgSFRUUA0KICAgY2hhbGxlbmdlcyBhbmQgcmVz cG9uc2VzIGNhbiBiZSBmZXRjaGVkIGZyb20gYW5kIHRvIGRpZmZlcmVudCBUTFMNCiAgIHR1bm5l bHMgd2l0aG91dCBub3RpY2luZyB0aGVpciBvcmlnaW4uIg0KDQpBbHRob3VnaCB0aGUgYWJvdmUg YXR0YWNrIG5lZWRzIHNvbWUgY29uZGl0aW9ucywgc3VjaCBhIHVzZSBvZiBUTFMgYW5kIEhUVFAg ZGlnZXN0IGRvZXMgbGVhZCB0aGUgcHJvcG9zZWQgcHJvdG9jb2wgdG8gYSBkYW5nZXJvdXMgc2l0 dWF0aW9uLg0KSXQgaXMgbWFpbmx5IGJlY2F1c2UsIChkZXRhaWxzIGNvdWxkIGJlIGZvdW5kIGlu IEFzb2thbiBldCBhbCdzIHBhcGVyKQ0KLSBIVFRQIGRpZ2VzdCBhdXRoZW50aWNhdGlvbiBwcm90 b2NvbCBpcyB0b28gd2Vhay4gSXQgb25seSBoYXMgYSBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rp b24gdG8gcnVuIGEgb25lLXdheSBjb21wdXRhdGlvbiBvZiB0aGUgcGFzc3dvcmQsIGxhY2sgb2Yg c2VjcmV0IGtleSBiYXNlZCBvciBwdWJsaWMga2V5IGJhc2VkIHByb3RlY3Rpb24sIHVubGlrZSBU TFMuDQotIFRoZSBzZXNzaW9uIGtleSBpcyBuZWdvdGlhdGVkIGluIG91dGVyIFRMUyBwcm90b2Nv bCBzb2xlbHkuDQotIFRoZSBpbm5lciBwcm90b2NvbCBIVFRQIGRpZ2VzdCBhdXRoIGRvZXMgbm90 IHJlYWxpemUgdGhlIGV4aXN0ZW5jZSBvZiBvdXRlciBUTFMgcHJvdG9jb2wuDQoNCkEgcG9zc2li bGUgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtIG1pZ2h0IGJlIHRvIGNyeXB0b2dyYXBoaWNhbGx5 IGJpbmQgdGhlIGlubmVyIGFuZCBvdXRlciBwcm90b2NvbCwgZm9yIGV4YW1wbGUsIHRvIGdlbmVy YXRlIGEgc2Vzc2lvbiBrZXkgZm9yIGlubmVyIHByb3RvY29sLg0KSG93ZXZlciwgSFRUUCBkaWdl c3QgZG9lcyBub3QgdXNlIG5vciBnZW5lcmF0ZSBzZXNzaW9uIGtleS4uLg0KQWdhaW4sIElNSE8s IGl0IHNlZW1zIG5vdCBhIGdvb2QgaWRlYSB0byB1c2UgSFRUUCBkaWdlc3QgYXV0aCBwcm90b2Nv bCBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiBTb21lIG90aGVyIGNhbmRpZGF0ZXMgbmVlZCB0 byBiZSBjb25zaWRlcmVkLg0KDQpBbmQgYWdhaW4sIEkgZmVlbCB0aGF0IGl0IGlzIG5lY2Vzc2Fy eSB0byBzZXQgdXAgYW4gaW5kZXBlbmRlbnQgZHJhZnQgdGFraW5nIGNhcmUgb2YgUEFXUyBzZWN1 cml0eSwgd2hpY2ggbWF5IGhlbHAgZGVzaWduIGFuZCBpbXBsZW1lbnQgdGhlIFBBV1MgcHJvdG9j b2wuDQpIb3BlIHRoYXQgb3VyIGRyYWZ0LCBkcmFmdC13dS1wYXdzLXNlY3V0aXR5LTAwLCBjb3Vs ZCBiZSBhIHN0YXJ0aW5nIHBvaW50LiBBbnkgY29tbWVudCBpcyB3ZWxjb21lLg0KDQpCUiwNCllh bmcNCj09PT09PT09PT09PT09PT09PQ0KIFlhbmcgQ3VpLCAgUGguRC4NCiBIdWF3ZWkgVGVjaG5v bG9naWVzDQogY3VpeWFuZ0BodWF3ZWkuY29tDQoNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g t6K8/sjLOiBEYXMsIFN1YmlyIFttYWlsdG86c2Rhc0BhcHBjb21zY2kuY29tXQ0KPiC3osvNyrG8 5DogMjAxMsTqN9TCMjTI1SA3OjQ2DQo+IMrVvP7IyzogQ3VpeWFuZzsgR2Fib3IuQmFqa29Abm9r aWEuY29tOyBwYXdzQGlldGYub3JnDQo+INb3zOI6IFJFOiBjb21tZW50cyBvbiBkcmFmdC1kYXMt cGF3cy1wcm90b2NvbC0wMi50eHQNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gU29t ZSBhbnN3ZXJzIGlubGluZS4NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+IEN1aXlhbmcNCj4gU2VudDogTW9uZGF5LCBKdWx5IDIzLCAyMDEyIDg6 NDUgQU0NCj4gVG86IEdhYm9yLkJhamtvQG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3Bhd3NdIGNvbW1lbnRzIG9uIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4 dA0KPiANCj4gSGkgQWxsLA0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgc29tZSBjb21t ZW50cyB0byB0aGlzIGRyYWZ0LCBmcm9tIGEgc2VjdXJpdHkgcG9pbnQgb2YNCj4gdmlldy4NCj4g SG9wZSB0aGF0IGl0IHdpbGwgYmUgaGVscGZ1bC4NCj4gDQo+IFRoZSBUTFMgYW5kICJIVFRQIERp Z2VzdCBBdXRoIiBoYXZlIGJlZW4gdXNlZCwgYnV0IHNlZW0gdW5jbGVhciBmb3IgbWUuDQo+IEJl c2lkZXMsIGl0IGlzIG5vdCByZWNvbW1lbmRlZCB0byB1c2UgdGhlIGxhdHRlciBmb3Igc29tZSBy ZWFzb25zIGxpc3RlZA0KPiBiZWxvdy4NCj4gLSBJdCBpcyBzYWlkIHRoYXQgdGhlIEhUVFAvVExT IHByb3RvY29sIGlzIGRlcGxveWVkIGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24uDQo+IA0KPiBT RD4gVGhpcyBpcyBub3QgY29ycmVjdC4NCj4gDQo+IEhvd2V2ZXIsICJIVFRQIGRpZ2VzdCBhdXRo ZW50aWNhdGlvbiIgaXMgYWN0dWFsbHkgdXNlZCBmb3IgYXV0aGVudGljYXRpbmcgdGhlDQo+IGRl dmljZSwNCj4gDQo+IFNEPiAgRGlnZXN0IEF1dGhlbnRpY2F0aW9uIGlzIHVzZWQgdG8gYXV0aGVu dGljYXRlIHRoZSBjbGllbnQgYXQgdGhlIFBBV1MNCj4gbGF5ZXIuDQo+IA0KPiB3aGljaCBpcyB0 eXBpY2FsbHkgd2Vha2VyIHRoYW4gbm9ybWFsIFRMUy4NCj4gDQo+IFNEPiBXaHkgaXMgaXQgd2Vh a2VyPw0KPiANCj4gT25seSB0aGUgc2VydmVyIHNpZGUgYXV0aGVudGljYXRpb24gaXMgcGVyZm9y bWVkIGJ5IFRMUyBjZXJ0aWZpY2F0ZS1iYXNlZA0KPiBjcnlwdG8gbWV0aG9kLg0KPiAtIEl0IGFw cGVhcnMgdGhhdCBhdXRoZW50aWNhdGlvbiBpcyBkb25lIGluIGRpZmZlcmVudCBsYXllcnMsIGku ZS4sIGRldmljZSBpcyBkb25lDQo+IGluIFBBV1MgbGF5ZXIgYnkgIkhUVFAgZGlnZXN0IGF1dGgi IGFuZCBzZXJ2ZXIgaXMgYWNoaWV2ZWQgaW4gVExTIGxheWVyIGJ5DQo+IGNlcnRpZmljYXRlLg0K PiANCj4gU0Q+IFllcywgYXV0aGVudGljYXRpb24gaXMgZG9uZSBhdCB0aGUgUEFXUyBsYXllciBi eSB1c2luZyBkaWdlc3QNCj4gYXV0aGVudGljYXRpb24uDQo+IA0KPiBJIGRvIG5vdCB1bmRlcnN0 YW5kIHdoeSBzZWN1cml0eSBpcyBkb25lIGluIG1peGVkIGxheWVycz8NCj4gDQo+IC0gSXQgaXMg c2FpZCB0aGF0IGNvbmZpZGVudGlhbGl0eSBpcyBwcm90ZWN0ZWQgaW4gSFRUUFMgbGF5ZXIsIGJ1 dCBpZg0KPiBhdXRoZW50aWNhdGluZyBkZXZpY2UgaXMgYWNoaWV2ZWQgaW4gZGlmZmVyZW50IGxh eWVyIChpLmUuIGluIFBBV1MgbGF5ZXIpLCBob3cNCj4gY2FuIHRoZSBkZXZpY2UgYW5kIHNlcnZl ciBuZWdvdGlhdGUgdGhlIHNlc3Npb24ga2V5Pw0KPiANCj4gU0Q+IER1cmluZyBub3JtYWwgVExT IG5lZ290aWF0aW9uLg0KPiANCj4gLSBPciwgaWYgbXkgYWJvdmUgdW5kZXJzdGFuZGluZyBpcyB3 cm9uZyBhbmQgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGlzIGluZGVlZA0KPiBkb25lIGluIFRMUyBs YXllciwgd2h5IGRvZXMgaXQgbmVlZCB0byBoYXZlIGFkZGl0aW9uYWwgIkhUVFAgZGlnZXN0IGF1 dGgiIGluDQo+IFBBV1MgbGF5ZXI/DQo+IA0KPiBTRD4gT25seSBjbGllbnQgYXV0aGVudGljYXRp b24gaXMgZG9uZSBhdCB0aGUgUEFXUyBsYXllci4gT2YgY291cnNlIGNsaWVudA0KPiBhdXRoIGNh biBiZSBkb25lIGF0IHRoZSBUTFMgbGF5ZXIuIFRoZW4gb25lIG5lZWRzIHRvIGhhdmUgY2hhbm5l bCBiaW5kaW5nDQo+IGFuZCB0aGF0J3MgYW5vdGhlciBhcHByb2FjaC4NCj4gDQo+IC0gIkhUVFAg ZGlnZXN0IGF1dGgiIG9ubHkgcHJvdmlkZXMgYSBoYXNoLWJhc2VkIHByb3RlY3Rpb24gZm9yIHNl Y3JldHMgbGlrZQ0KPiBwYXNzd29yZCBhbmQgSUQsIGFuZCBpcyBrbm93biB0byBiZSB2dWxuZXJh YmxlIHRvIE1pdE0gKE1hbi1pbi10aGUtTWlkZGxlKQ0KPiBhdHRhY2tzLiBTaW5jZSBhY2NvcmRp bmcgdG8gdGhlIFBBV1MgV0cgZG9jdW1lbnQsDQo+IGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0 bXQtdXNlY2FzZXMtcnFtdHMtMDYsIENoYXB0ZXIgOCwgdGhyZWF0IDcsIE1pdE0NCj4gYXR0YWNr IHNob3VsZCBiZSB0aHdhcnRlZC4gVGhpcyBkcmFmdCB1c2luZyAiSFRUUCBkaWdlc3QgYXV0aCIg b2J2aW91c2x5DQo+IGRvZXMgbm90IHNhdGlzZnkgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50Lg0K PiANCj4gU0Q+ICBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoaXMuIEhUVFAvVExTIGlzIHVzZWQgaW4g b3VyIHNjaGVtZS4NCj4gDQo+IC0gIkhUVFAgZGlnZXN0IGF1dGgiIGRpZmZlcnMgZnJvbSBIVFRQ IG92ZXIgVExTLCB3aGVyZSB0aGUgZm9ybWVyIHByb3ZpZGVzDQo+IG5vIGVuY3J5cHRpb24gZm9y IGNvbnRlbnQsIGJ1dCB0aGUgbGF0dGVyIGNhbiBlbmNyeXB0IHRoZSBjb250ZW50IGJ5IFB1Ymxp Yw0KPiBLZXkgY3J5cHRvLiBUaHVzIFRMUyBpcyBwcmVmZXJyZWQuDQo+IC0gIkhUVFAgZGlnZXN0 IGF1dGgiIGRvZXMgbm90IHN1cHBvcnQgSE1BQyBhbGdvcml0aG0gKHNvLWNhbGxlZCBLZXllZA0K PiBIYXNoKSwgdGh1cyBpdCBpcyB5ZXQgYSBsaXR0bGUgcmlza3kgdG8gdXNlIFNIQS0xIHRvIHJl cGxhY2UgY3VycmVudCBNRDUNCj4gYWxnb3JpdGhtLCBiZWNhdXNlIE5JU1QgaGFzIG5vdCByZWNv bW1lbmRlZCB0byB1c2UgdGhlIGNvbGxpc2lvbiByZXNpc3RhbmNlDQo+IG9mIFNIQS0xIChidXQg SE1BQy1TSEExIGlzIGZpbmUpLiBJbiBjb250cmFzdCwgVExTIHN1cHBvcnRzIEhNQUMgYW5kIGRv ZXMNCj4gbm90IGhhdmUgc3VjaCBhIHByb2JsZW0uDQo+IA0KPiBTRD4gWWVzIGl0IHNob3VsZCBi ZSBITUFDLVNIQTEuDQo+IA0KPiBGcm9tIHRoZSBhYm92ZSBhbmFseXNpcywgaXQgaXMgY2xlYXIg dG8gc2VlIHRoYXQgdGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IG9mDQo+IFBBV1MgaXMgbm90IHN0 cmFpZ2h0Zm9yd2FyZCBhbmQgbmVlZHMgdG8gYmUgY2FyZWZ1bGx5IGludmVzdGlnYXRlZCwgZm9y DQo+IGRlc2lnbiBhbmQgaW1wbGVtZW50YXRpb24uDQo+IEl0IGlzIGFsc28gdGhlIHJlYXNvbiB3 aHkgd2UgaGF2ZSBzdWJtaXR0ZWQgYW4gaW5kZXBlbmRlbnQgZHJhZnQgZm9yIFBBV1MNCj4gc2Vj dXJpdHksIHRvIHByb3ZpZGUgYSBiYXNlIGZvciBkaXNjdXNzaW9uLg0KPiANCj4gQlIsDQo+IFlh bmcNCj4gPT09PT09PT09PT09PT09PT09DQo+ICBZYW5nIEN1aSwgIFBoLkQuDQo+ICBIdWF3ZWkg VGVjaG5vbG9naWVzDQo+ICBjdWl5YW5nQGh1YXdlaS5jb20NCj4gDQo+IA0KPiA+IC0tLS0t08q8 /tStvP4tLS0tLQ0KPiA+ILeivP7IyzogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3 cy1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+ID4gR2Fib3IuQmFqa29Abm9raWEuY29tDQo+ID4g t6LLzcqxvOQ6IDIwMTLE6jfUwjIyyNUgNzozMQ0KPiA+IMrVvP7IyzogcGF3c0BpZXRmLm9yZw0K PiA+INb3zOI6IFtwYXdzXSBjb21tZW50cyBvbiBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50 eHQNCj4gPg0KPiA+IEl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgaWYgdGhlcmUgd2VyZSBkaXNjdXNz aW9ucyBvbiB0aGUgZHJhZnRzIHRvDQo+ID4gc3VibWl0dGVkIGFoZWFkIG9mIHRoZSBGMkYgcHJl c2VudGF0aW9ucy4NCj4gPiBUaHVzLCBJJ3ZlIHRha2VuIHRoZSBpbml0aWF0aXZlIHRvIHJlYWQg dGhlIGRyYWZ0IGFuZCBwcm92aWRlIHNvbWUNCj4gPiBpbml0aWFsDQo+ID4gY29tbWVudHM6DQo+ ID4NCj4gPiAxLiBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoZSBpbml0aWFs aXphdGlvbiBwcm9jZXNzIGFuZA0KPiA+IHdoeSBtZXNzYWdlcyBJTlQtUkVRIGFuZCBJTlQtUkVT UCBhcmUgbmVjZXNzYXJ5LiBUaGUgY2FwYWJpbGl0eQ0KPiA+IGV4Y2hhbmdlIGNhbiBiZSBkb25l IGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuDQo+ID4gV2UgbWF5IGV2ZW4gY29uc2lk ZXIgbWVyZ2luZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgd2l0aCB0aGUgREINCj4gPiBxdWVy eSBwcm9jZXNzLCB0aGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgYW55IHJlYXNvbiB0byBoYXZlIHRo ZW0gYXMNCj4gPiBzZXBhcmF0ZSBtZXNzYWdlcy4NCj4gPg0KPiA+IDIuIHlvdSBtYXkgbmVlZCBh IHNlY3Rpb24gd2hlcmUgeW91IG1hcCB5b3VyIG5ld2x5IGRlZmluZWQgbWVzc2FnZXMgdG8NCj4g PiBleGlzdGluZyBodHRwIHByb3RvY29sIG1lc3NhZ2VzLiBJIHNhdyB0aGF0IHlvdSBoYXZlIGFu IGV4YW1wbGUNCj4gPiBzZWN0aW9uLCBidXQgYSBub3JtYXRpdmUgc2VjdGlvbiB3b3VsZCBiZSBt b3JlIGRlc2lyYWJsZS4NCj4gPg0KPiA+IDMuIHRoZSBkYXRhIG1vZGVsIHBhcnQgbmVlZHMgc29t ZSBtb3JlIHdvcmsuIFRoZSBzdHJ1Y3R1cmUgaXMgbm90IHZlcnkNCj4gPiBjbGVhciB0byBtZSwg YW5kIHNvbWUgb2YgdGhlIGF0dHJpYnV0ZXMgcmVmZXJlbmNlIG9ic29sZXRlIFJGQy4NCj4gPiBF ZywgUkZDMzgyNSBpcyByZWZlcmVuY2VkIGZvciB0aGUgbG9uZ2l0dWRlL2xhdGl0dWRlIGF0dHJp YnV0ZXMuIEkNCj4gPiB0aGluayB5b3Ugc2hvdWxkIGJlIGJldHRlciBvZiB1c2luZyBhbiBlbGVt ZW50IGZvciBnZW8tbG9jYXRpb24sIHdpdGgNCj4gPiB0aGUgc3RydWN0dXJlIGFzIGRlZmluZWQg aW4gUkZDNTQ5MSwgYSBzZXBhcmF0ZSBlbGVtZW50IGZvciB0aGUgY2l2aWMNCj4gPiBsb2NhdGlv biwgd2l0aCB0aGUgc3RydWN0dXJlIGFzIGRlZmluZWQgaW4gUkZDNTEzOSwgZXRjLg0KPiA+IElu c3RlYWQgb2YgdGhlIERldmljZU93bmVyIG9iamVjdCwgSSB3b3VsZCB1c2UgYSB2Q2FyZCBlbGVt ZW50LCB3aXRoDQo+ID4gdGhlIHN0cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJGQzI0MjYuDQo+ID4g WW91IG1heSBhbHNvIG5lZWQgYW4gaUNhbGVuZGFyIGVsZW1lbnQgKFJGQzU1NDUpIHRvIHNwZWNp ZnkgdGhlDQo+ID4gY2hhbm5lbCBhdmFpbGFiaWxpdHkgdGltZSAoZWcsIHdoZW4gdGhlIGNoYW5u ZWwgaXMgbm90IGF2YWlsYWJsZSBmb3IgdGhlIGZ1bGwNCj4gMjRIKS4NCj4gPiBFdGMuDQo+ID4N Cj4gPiBNb3JlIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiA+IC0gR2Fib3INCj4gPg0KPiA+DQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBwYXdzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+IE9mIGV4 dCBEYXMsIFN1YmlyDQo+ID4gU2VudDogU2F0dXJkYXksIEp1bHkgMTQsIDIwMTIgNzozNiBBTQ0K PiA+IFRvOiBwYXdzQGlldGYub3JnDQo+ID4gU3ViamVjdDogW3Bhd3NdIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+ ID4NCj4gPiBEZWFyIENoYWlycywNCj4gPiBXZSBoYXZlIHVwZGF0ZWQgb3VyIGRyYWZ0IGFuZCB3 b3VsZCBsaWtlIHRvIHJlcXVlc3QgYSBzbG90IGluIElFVEYtODQNCj4gPiB0byBwcmVzZW50IGl0 Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBfU3ViaXINCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDE0LCAy MDEyIDEwOjMwIEFNDQo+ID4gVG86IERhcywgU3ViaXINCj4gPiBDYzogam1hbHlhckB0ZWxjb3Jk aWEuY29tOyBkLmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb20NCj4gPiBTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPiA+ DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wt MDIudHh0IGhhcyBiZWVuDQo+ID4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdWJpciBEYXMg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gRmlsZW5hbWU6CSBk cmFmdC1kYXMtcGF3cy1wcm90b2NvbA0KPiA+IFJldmlzaW9uOgkgMDINCj4gPiBUaXRsZToJCSBE ZXZpY2UgdG8gRGF0YWJhc2UgUHJvdG9jb2wgZm9yIFdoaXRlIFNwYWNlDQo+ID4gQ3JlYXRpb24g ZGF0ZToJIDIwMTItMDctMTQNCj4gPiBXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g PiBOdW1iZXIgb2YgcGFnZXM6IDMyDQo+ID4gVVJMOg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPiA+IFN0YXR1 czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kYXMtcGF3 cy1wcm90b2NvbA0KPiA+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDINCj4gPiBEaWZmOg0KPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyDQo+ID4NCj4g PiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgYFByb3RvY29s IHRvIEFjY2VzcyBXaGl0ZSBTcGFjZSBkYXRhYmFzZQ0KPiA+ICAgIChQQVdTKScgdGhhdCB1c2Vz IEhUVFAvVExTIGFzIHRyYW5zcG9ydC4gIFRoZSBwcm90b2NvbCBpcyB1c2VkIGZvcg0KPiA+ICAg IHJldHJpZXZpbmcgdGhlIG5lY2Vzc2FyeSBUViB3aGl0ZSBzcGFjZSBpbmZvcm1hdGlvbiAoZS5n LiwgY2hhbm5lbCwNCj4gPiAgICBmcmVxdWVuY3ksIHRyYW5zbWl0dGVkIHBvd2VyKSBhdCBhIGdp dmVuIGxvY2F0aW9uIGFuZCB0aW1lIGZyb20gYQ0KPiA+ICAgIGRhdGFiYXNlIHRoYXQgaXMgb3Bl cmF0aW5nIHVuZGVyIGEgcmVndWxhdG9yeSBkb21haW4uICBUaGUgZG9jdW1lbnQNCj4gPiAgICBp bmNsdWRlcyB0aGUgcHJvdG9jb2wgZnVuY3Rpb25hbGl0aWVzLCBpdHMgZWxlbWVudHMsIGNvcnJl c3BvbmRpbmcNCj4gPiAgICBkYXRhIG1vZGVsIGFuZCByZWNvbW1lbmRzIGl0cyBlbmNvZGluZyBz Y2hlbWUuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gcGF3 cyBtYWlsaW5nIGxpc3QNCj4gPiBwYXdzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBwYXdzIG1haWxpbmcgbGlzdA0KPiA+IHBhd3NAaWV0 Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBt YWlsaW5nIGxpc3QNCj4gcGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MNCg== From gerald.chouinard@sympatico.ca Tue Jul 24 10:41:15 2012 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 3DE5711E8086 for ; Tue, 24 Jul 2012 10:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.803] 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 s+EeTJYncwhH for ; Tue, 24 Jul 2012 10:41:12 -0700 (PDT) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEB611E808D for ; Tue, 24 Jul 2012 10:41:12 -0700 (PDT) Received: from BLU0-SMTP63 ([65.55.116.72]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jul 2012 10:41:02 -0700 X-Originating-IP: [69.157.189.235] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([69.157.189.235]) by BLU0-SMTP63.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jul 2012 10:41:00 -0700 From: Gerald Chouinard To: "'Cuiyang'" Date: Tue, 24 Jul 2012 13:41:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1pPz68yv7NHS/cQYWYxlv1MnvLyQAg8gVQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 24 Jul 2012 17:41:00.0697 (UTC) FILETIME=[7D65B890:01CD69C3] Cc: paws@ietf.org, 'Ranga Reddy' , 'apurva mody' Subject: [paws] FW: comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 17:41:15 -0000 Cuiyang, Below are some further comments on these multiple points from our = resident security expert in the IEEE 802.22 Working Group. Gerald Chouinard -----Original Message----- From: Ranga Reddy [mailto:ranga.reddy@me.com]=20 Sent: Monday, 23 July, 2012 21:54 To: Gerald Chouinard Cc: Apurva Mody; Ranga Reddy Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt Overall I agree with Yang Cui's points. Here are my reponses to Yang = Cui's comments: 1) It's true that the "HTTP Digest Auth" is weaker. However, the = statement about TLS being only server-side is not entirely true. A TLS transaction = can be setup so that the client and server authenticate each other (see http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticate= d_T LS_handshake for an example). 2) I don't have any idea of what Yang is talking about here. There is a 5-layer model = PHY(1)<->MAC(2)<->Network(3)<->Transport(4)<->Application(5). PAWS could likely be a set of protocols that runs across layers 3-5, but most likely a Layer 3 (Network) protocol. "HTTP digest Auth" is just an application layer, or layer (5) protocol. I don't think a layer 5 only protocol would be sufficent. I would think a layer 3-5 or layer 3 = protocol would meet the PAWS requirements. This is assuming PAWS is built from an existing set of IETF protocols. 3) Yang brings up a good point here, given the issue raised by comment = (2). What PAWS is doing at each layer, if it's developed to be a multi-layer protocol, needs to be defined explicitly! 4) His initial understanding was/is slightly incorrect (see my response = to 1). Mutual authentication can be done by TLS. Because of this an "HTTP Digest Auth" is not needed. 5) Agreed in order to provided confidentiality and authentication of the devices and data transmitted between them, as defined in the PAWS requirements, "HTTP Digest Auth" is not sufficient and should not be = used. 6) Agreed. 7) Agree with the point Yang makes, but disagree with the selection of algorithms. HMAC and SHA-1 should be avoided if possible. Both have been shown to have issues and can be compromised. In fact, I believe most (current) references will show that SHA-1 has been deprecated by NIST. = Any TLS quite that can make use of SHA-2 should be used. Of the comments, comment (3) needs to be addressed. What is being along = each step of the PAWS transaction must be defined before we can make an = attempt to secure it. Vr, Ranga Reddy ranga.reddy@me.com On Jul 23, 2012, at 2:47 PM, Gerald Chouinard wrote: > Hi Ranga, >=20 > You may be interested in the points raised in the email below about = the use > of HTTP/TLS for PAWS security. I believe we had it right in the 802.22 > Standard. >=20 > Gerald >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of > Cuiyang > Sent: Monday, 23 July, 2012 08:45 > To: Gabor.Bajko@nokia.com; paws@ietf.org > Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt >=20 > Hi All, >=20 > I would like to provide some comments to this draft, from a security = point > of view. > Hope that it will be helpful. >=20 > The TLS and "HTTP Digest Auth" have been used, but seem unclear for = me. > Besides, it is not recommended to use the latter for some reasons = listed > below. > - It is said that the HTTP/TLS protocol is deployed for mutual > authentication. However, "HTTP digest authentication" is actually used = for > authenticating the device, which is typically weaker than normal TLS. = Only > the server side authentication is performed by TLS certificate-based crypto > method. > - It appears that authentication is done in different layers, i.e., = device > is done in PAWS layer by "HTTP digest auth" and server is achieved in = TLS > layer by certificate. I do not understand why security is done in = mixed > layers? > - It is said that confidentiality is protected in HTTPS layer, but if > authenticating device is achieved in different layer (i.e. in PAWS = layer), > how can the device and server negotiate the session key? > - Or, if my above understanding is wrong and mutual authentication is indeed > done in TLS layer, why does it need to have additional "HTTP digest = auth" in > PAWS layer? > - "HTTP digest auth" only provides a hash-based protection for secrets like > password and ID, and is known to be vulnerable to MitM = (Man-in-the-Middle) > attacks. Since according to the PAWS WG document, > draft-ietf-paws-problem-stmt-usecases-rqmts-06, Chapter 8, threat 7, = MitM > attack should be thwarted. This draft using "HTTP digest auth" = obviously > does not satisfy the security requirement. > - "HTTP digest auth" differs from HTTP over TLS, where the former = provides > no encryption for content, but the latter can encrypt the content by Public > Key crypto. Thus TLS is preferred. > - "HTTP digest auth" does not support HMAC algorithm (so-called Keyed Hash), > thus it is yet a little risky to use SHA-1 to replace current MD5 algorithm, > because NIST has not recommended to use the collision resistance of = SHA-1 > (but HMAC-SHA1 is fine). In contrast, TLS supports HMAC and does not = have > such a problem. >=20 > From the above analysis, it is clear to see that the security and = privacy of > PAWS is not straightforward and needs to be carefully investigated, = for > design and implementation. > It is also the reason why we have submitted an independent draft for = PAWS > security, to provide a base for discussion. >=20 > BR, > Yang > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Yang Cui, Ph.D. > Huawei Technologies > cuiyang@huawei.com >=20 >=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] =B4=FA=B1=ED >> Gabor.Bajko@nokia.com >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C222=C8=D5 7:31 >> =CA=D5=BC=FE=C8=CB: paws@ietf.org >> =D6=F7=CC=E2: [paws] comments on draft-das-paws-protocol-02.txt >>=20 >> It would be beneficial if there were discussions on the drafts to > submitted >> ahead of the F2F presentations. >> Thus, I've taken the initiative to read the draft and provide some initial >> comments: >>=20 >> 1. I do not understand the purpose of the initialization process and = why >> messages INT-REQ and INT-RESP are necessary. The capability exchange = can >> be done during the registration process. >> We may even consider merging the registration process with the DB = query >> process, there doesn't seem to be any reason to have them as separate >> messages. >>=20 >> 2. you may need a section where you map your newly defined messages = to >> existing http protocol messages. I saw that you have an example = section, > but a >> normative section would be more desirable. >>=20 >> 3. the data model part needs some more work. The structure is not = very > clear >> to me, and some of the attributes reference obsolete RFC. >> Eg, RFC3825 is referenced for the longitude/latitude attributes. I = think > you >> should be better of using an element for geo-location, with the = structure > as >> defined in RFC5491, a separate element for the civic location, with = the >> structure as defined in RFC5139, etc. >> Instead of the DeviceOwner object, I would use a vCard element, with = the >> structure as defined in RFC2426. >> You may also need an iCalendar element (RFC5545) to specify the = channel >> availability time (eg, when the channel is not available for the full > 24H). >> Etc. >>=20 >> More comments are welcome. >> - Gabor >>=20 >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of >> ext Das, Subir >> Sent: Saturday, July 14, 2012 7:36 AM >> To: paws@ietf.org >> Subject: [paws] FW: New Version Notification for >> draft-das-paws-protocol-02.txt >>=20 >> Dear Chairs, >> We have updated our draft and would like to request a slot in IETF-84 = to >> present it. >>=20 >> Regards, >> _Subir >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Saturday, July 14, 2012 10:30 AM >> To: Das, Subir >> Cc: jmalyar@telcordia.com; d.joslyn@spectrumbridge.com >> Subject: New Version Notification for draft-das-paws-protocol-02.txt >>=20 >>=20 >> A new version of I-D, draft-das-paws-protocol-02.txt has been successfully >> submitted by Subir Das and posted to the IETF repository. >>=20 >> Filename: draft-das-paws-protocol >> Revision: 02 >> Title: Device to Database Protocol for White Space >> Creation date: 2012-07-14 >> WG ID: Individual Submission >> Number of pages: 32 >> URL: >> http://www.ietf.org/internet-drafts/draft-das-paws-protocol-02.txt >> Status: = http://datatracker.ietf.org/doc/draft-das-paws-protocol >> Htmlized: = http://tools.ietf.org/html/draft-das-paws-protocol-02 >> Diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-das-paws-protocol-02 >>=20 >> Abstract: >> This document describes the `Protocol to Access White Space = database >> (PAWS)' that uses HTTP/TLS as transport. The protocol is used for >> retrieving the necessary TV white space information (e.g., channel, >> frequency, transmitted power) at a given location and time from a >> database that is operating under a regulatory domain. The document >> includes the protocol functionalities, its elements, corresponding >> data model and recommends its encoding scheme. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 From budden@nps.edu Tue Jul 24 11:15:27 2012 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 AB77911E8086 for ; Tue, 24 Jul 2012 11:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 NWmRFf7RUL2I for ; Tue, 24 Jul 2012 11:15:26 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCDB11E8079 for ; Tue, 24 Jul 2012 11:15:26 -0700 (PDT) X-ASG-Debug-ID: 1343153725-036c9204943f7140001-Z0ZA9G Received: from gulfstream.ern.nps.edu (gulfstream.ern.nps.edu [172.20.24.113]) by mule.nps.edu with ESMTP id A1663a9XegUUjTcs; Tue, 24 Jul 2012 11:15:25 -0700 (PDT) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.113) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 24 Jul 2012 11:15:24 -0700 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] FW: comments on draft-das-paws-protocol-02.txt To: Gerald Chouinard In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Jul 2012 11:14:31 -0700 Message-ID: <1343153671.981.559.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: gulfstream.ern.nps.edu[172.20.24.113] X-Barracuda-Start-Time: 1343153725 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.103642 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org, 'apurva mody' , 'Ranga Reddy' Subject: Re: [paws] FW: comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:15:27 -0000 in line below On Tue, 2012-07-24 at 13:41 -0400, Gerald Chouinard wrote: > Cuiyang, > > Below are some further comments on these multiple points from our resident > security expert in the IEEE 802.22 Working Group. > > Gerald Chouinard > > -----Original Message----- > From: Ranga Reddy [mailto:ranga.reddy@me.com] > Sent: Monday, 23 July, 2012 21:54 > To: Gerald Chouinard > Cc: Apurva Mody; Ranga Reddy > Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt > > Overall I agree with Yang Cui's points. Here are my reponses to Yang Cui's > comments: > > 1) It's true that the "HTTP Digest Auth" is weaker. However, the statement > about TLS being only server-side is not entirely true. A TLS transaction can > be setup so that the client and server authenticate each other (see > http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_T > LS_handshake for an example). > > 2) I don't have any idea of what Yang is talking about here. There is a > 5-layer model PHY(1)<->MAC(2)<->Network(3)<->Transport(4)<->Application(5). > PAWS could likely be a set of protocols that runs across layers 3-5, but > most likely a Layer 3 (Network) protocol. "HTTP digest Auth" is just an > application layer, or layer (5) protocol. I don't think a layer 5 only > protocol would be sufficent. I would think a layer 3-5 or layer 3 protocol > would meet the PAWS requirements. This is assuming PAWS is built from an > existing set of IETF protocols. Ranga, This masks a problem that is outside of the comms net but important to the information system. In your model, diff between layer 4 and 5. TLS (or any other transport layer security measure) has scope from TCP socket to TCP socket. The rest of the operating system on each end is outside of this security scope. So the data is unprotected once it is on the OS side of the TCP socket. Application security measures (e-mail sign/crypt is an example) secure the data rather than the connection. This allows the data to remain secured through the operating system except in the part where it is actually used/read/generated. vis PAWS, there don't seem to be any inhibitions to using application layer security measures which allow placing most of the OS outside the necessary security perimeter. > > 3) Yang brings up a good point here, given the issue raised by comment (2). > What PAWS is doing at each layer, if it's developed to be a multi-layer > protocol, needs to be defined explicitly! > > 4) His initial understanding was/is slightly incorrect (see my response to > 1). Mutual authentication can be done by TLS. Because of this an "HTTP > Digest Auth" is not needed. > > 5) Agreed in order to provided confidentiality and authentication of the > devices and data transmitted between them, as defined in the PAWS > requirements, "HTTP Digest Auth" is not sufficient and should not be used. > > 6) Agreed. > > 7) Agree with the point Yang makes, but disagree with the selection of > algorithms. HMAC and SHA-1 should be avoided if possible. Both have been > shown to have issues and can be compromised. In fact, I believe most > (current) references will show that SHA-1 has been deprecated by NIST. Any > TLS quite that can make use of SHA-2 should be used. > > Of the comments, comment (3) needs to be addressed. What is being along each > step of the PAWS transaction must be defined before we can make an attempt > to secure it. > > Vr, > Ranga Reddy > ranga.reddy@me.com > > On Jul 23, 2012, at 2:47 PM, Gerald Chouinard > wrote: > > > Hi Ranga, > > > > You may be interested in the points raised in the email below about the > use > > of HTTP/TLS for PAWS security. I believe we had it right in the 802.22 > > Standard. > > > > Gerald > > > > > > -----Original Message----- > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > > Cuiyang > > Sent: Monday, 23 July, 2012 08:45 > > To: Gabor.Bajko@nokia.com; paws@ietf.org > > Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt > > > > Hi All, > > > > I would like to provide some comments to this draft, from a security point > > of view. > > Hope that it will be helpful. > > > > The TLS and "HTTP Digest Auth" have been used, but seem unclear for me. > > Besides, it is not recommended to use the latter for some reasons listed > > below. > > - It is said that the HTTP/TLS protocol is deployed for mutual > > authentication. However, "HTTP digest authentication" is actually used for > > authenticating the device, which is typically weaker than normal TLS. Only > > the server side authentication is performed by TLS certificate-based > crypto > > method. > > - It appears that authentication is done in different layers, i.e., device > > is done in PAWS layer by "HTTP digest auth" and server is achieved in TLS > > layer by certificate. I do not understand why security is done in mixed > > layers? > > - It is said that confidentiality is protected in HTTPS layer, but if > > authenticating device is achieved in different layer (i.e. in PAWS layer), > > how can the device and server negotiate the session key? > > - Or, if my above understanding is wrong and mutual authentication is > indeed > > done in TLS layer, why does it need to have additional "HTTP digest auth" > in > > PAWS layer? > > - "HTTP digest auth" only provides a hash-based protection for secrets > like > > password and ID, and is known to be vulnerable to MitM (Man-in-the-Middle) > > attacks. Since according to the PAWS WG document, > > draft-ietf-paws-problem-stmt-usecases-rqmts-06, Chapter 8, threat 7, MitM > > attack should be thwarted. This draft using "HTTP digest auth" obviously > > does not satisfy the security requirement. > > - "HTTP digest auth" differs from HTTP over TLS, where the former provides > > no encryption for content, but the latter can encrypt the content by > Public > > Key crypto. Thus TLS is preferred. > > - "HTTP digest auth" does not support HMAC algorithm (so-called Keyed > Hash), > > thus it is yet a little risky to use SHA-1 to replace current MD5 > algorithm, > > because NIST has not recommended to use the collision resistance of SHA-1 > > (but HMAC-SHA1 is fine). In contrast, TLS supports HMAC and does not have > > such a problem. > > > > From the above analysis, it is clear to see that the security and privacy > of > > PAWS is not straightforward and needs to be carefully investigated, for > > design and implementation. > > It is also the reason why we have submitted an independent draft for PAWS > > security, to provide a base for discussion. > > > > BR, > > Yang > > ================== > > Yang Cui, Ph.D. > > Huawei Technologies > > cuiyang@huawei.com > > > > > >> -----邮件原件----- > >> å‘件人: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] 代表 > >> Gabor.Bajko@nokia.com > >> å‘é€æ—¶é—´: 2012å¹´7月22æ—¥ 7:31 > >> 收件人: paws@ietf.org > >> 主题: [paws] comments on draft-das-paws-protocol-02.txt > >> > >> It would be beneficial if there were discussions on the drafts to > > submitted > >> ahead of the F2F presentations. > >> Thus, I've taken the initiative to read the draft and provide some > initial > >> comments: > >> > >> 1. I do not understand the purpose of the initialization process and why > >> messages INT-REQ and INT-RESP are necessary. The capability exchange can > >> be done during the registration process. > >> We may even consider merging the registration process with the DB query > >> process, there doesn't seem to be any reason to have them as separate > >> messages. > >> > >> 2. you may need a section where you map your newly defined messages to > >> existing http protocol messages. I saw that you have an example section, > > but a > >> normative section would be more desirable. > >> > >> 3. the data model part needs some more work. The structure is not very > > clear > >> to me, and some of the attributes reference obsolete RFC. > >> Eg, RFC3825 is referenced for the longitude/latitude attributes. I think > > you > >> should be better of using an element for geo-location, with the structure > > as > >> defined in RFC5491, a separate element for the civic location, with the > >> structure as defined in RFC5139, etc. > >> Instead of the DeviceOwner object, I would use a vCard element, with the > >> structure as defined in RFC2426. > >> You may also need an iCalendar element (RFC5545) to specify the channel > >> availability time (eg, when the channel is not available for the full > > 24H). > >> Etc. > >> > >> More comments are welcome. > >> - Gabor > >> > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > >> ext Das, Subir > >> Sent: Saturday, July 14, 2012 7:36 AM > >> To: paws@ietf.org > >> Subject: [paws] FW: New Version Notification for > >> draft-das-paws-protocol-02.txt > >> > >> Dear Chairs, > >> We have updated our draft and would like to request a slot in IETF-84 to > >> present it. > >> > >> Regards, > >> _Subir > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Saturday, July 14, 2012 10:30 AM > >> To: Das, Subir > >> Cc: jmalyar@telcordia.com; d.joslyn@spectrumbridge.com > >> Subject: New Version Notification for draft-das-paws-protocol-02.txt > >> > >> > >> A new version of I-D, draft-das-paws-protocol-02.txt has been > successfully > >> submitted by Subir Das and posted to the IETF repository. > >> > >> Filename: draft-das-paws-protocol > >> Revision: 02 > >> Title: Device to Database Protocol for White Space > >> Creation date: 2012-07-14 > >> WG ID: Individual Submission > >> Number of pages: 32 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-das-paws-protocol-02.txt > >> Status: http://datatracker.ietf.org/doc/draft-das-paws-protocol > >> Htmlized: http://tools.ietf.org/html/draft-das-paws-protocol-02 > >> Diff: > > http://tools.ietf.org/rfcdiff?url2=draft-das-paws-protocol-02 > >> > >> Abstract: > >> This document describes the `Protocol to Access White Space database > >> (PAWS)' that uses HTTP/TLS as transport. The protocol is used for > >> retrieving the necessary TV white space information (e.g., channel, > >> frequency, transmitted power) at a given location and time from a > >> database that is operating under a regulatory domain. The document > >> includes the protocol functionalities, its elements, corresponding > >> data model and recommends its encoding scheme. > >> > >> > >> > >> > >> The IETF Secretariat > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Wed Jul 25 12:06:28 2012 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 6A8E221F86F7 for ; Wed, 25 Jul 2012 12:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 KFor9ztNnE02 for ; Wed, 25 Jul 2012 12:06:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BF4CB21F8646 for ; Wed, 25 Jul 2012 12:06:26 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AII49530; Wed, 25 Jul 2012 15:06:26 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 25 Jul 2012 12:04:02 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.75]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 12:03:51 -0700 From: Peter McCann To: Cuiyang , "Das, Subir" , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQAB/KozAAGpqGMABA6hCA Date: Wed, 25 Jul 2012 19:03:50 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E18FC3@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DD31@SZXEML508-MBS.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE2163684DD31@SZXEML508-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.152] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 19:06:28 -0000 SXQgYWxzbyBhcHBlYXJzIHRoYXQgZHJhZnQtZGFzIHJlLWltcGxlbWVudHMgSFRUUCBEaWdlc3Qg YXQgdGhlDQphcHBsaWNhdGlvbiBsYXllciwgcmF0aGVyIHRoYW4gYXR0ZW1wdGluZyB0byB1c2Ug c3RhbmRhcmQgSFRUUA0KRGlnZXN0LiAgSSBhbSBjdXJpb3VzIGFzIHRvIHdoeSB5b3UgbWFkZSB0 aGlzIGNob2ljZS4gIElzIGl0IHNvDQp0aGF0IHlvdSBjYW4gdXBncmFkZSB0aGUgaGFzaCBmdW5j dGlvbiBmcm9tIE1ENSB0byBTSEEtMT8NCg0KQWxzbywgeW91IGRvbid0IHNob3cgdGhlIG1lc3Nh Z2VzIHRoYXQgcmVsYXkgdGhlIG5vbmNlIHZhbHVlIGZyb20NCnRoZSBzZXJ2ZXIgdG8gdGhlIGNs aWVudC4gIEkgdGhpbmsgeW91IHdpbGwgbmVlZCB0byBzcGVjaWZ5IHRoYXQNCm1lc3NhZ2UgYXMg d2VsbC4gIEhUVFAgZG9lcyB0aGlzIHdpdGggYSA0MDEgVW5hdXRob3JpemVkIHJlc3BvbnNlLg0K DQpJdCBhbHNvIGxvb2tzIGxpa2UgeW91IGFyZSBub3Qgc2VuZGluZyBhbnkgcmVzcG9uc2VzIGF0 IGFsbCBpbiB5b3VyDQpleGFtcGxlcywganVzdCB1c2luZyBQT1NUIGluIGJvdGggZGlyZWN0aW9u cy4gIFRoaXMgc2VlbXMgc3RyYW5nZS4NCg0KDQpJdCBtaWdodCBiZSBiZXR0ZXIgdG8gcmVseSBv biBjbGllbnQgY2VydGlmaWNhdGVzIGF0IHRoZSBUTFMgbGF5ZXINCnRvIGF1dGhlbnRpY2F0ZSB0 aGUgbWFzdGVyIGRldmljZS4NCg0KRm9yIGF1dGhlbnRpY2F0aW5nIHRoZSBzbGF2ZSBkZXZpY2Vz LCB3ZSBtaWdodCBuZWVkIHNvbWV0aGluZyBhdCB0aGUNCmFwcGxpY2F0aW9uIGxheWVyLiAgVGhh dCBpcyBhIHNlcGFyYXRlIGRpc2N1c3Npb24gdGhhdCBzdGlsbCBuZWVkcyB0bw0KaGFwcGVuIChu ZWl0aGVyIGRyYWZ0IHJpZ2h0IG5vdyBkZWFscyB3aXRoIGF1dGhlbnRpY2F0aW5nIHRoZSBzbGF2 ZQ0KZGV2aWNlIGlkZW50aWZpZXJzKS4NCg0KLVBldGUNCg0KDQpDdWl5YW5nIHdyb3RlOg0KPiBU aGFua3MgZm9yIHlvdXIgYW5zd2Vycy4NCj4gDQo+IEJ1dCB0aGVuIEkgcmVhbGl6ZWQgdGhhdCB0 aGUgcHJvcG9zYWwgaXMgdXNpbmcgYSBraW5kIG9mIHR3by1sYXllcg0KPiBhdXRoZW50aWNhdGlv biBwcm90b2NvbHMsIHMudC4gYW4gb3V0ZXIgbGF5ZXIgcHJvdG9jb2wgb2YgVExTDQo+IGF1dGhl bnRpY2F0aW9uIG9mIHNlcnZlciAoZGF0YWJhc2UpLCBhbmQgYW4gaW5uZXIgbGF5ZXIgcHJvdG9j b2wNCj4gYXV0aGVudGljYXRpb24gb2YgY2xpZW50IChNYXN0ZXIgZGV2aWNlKS4NCj4gVW5mb3J0 dW5hdGVseSwgaXQgaXMga25vd24gdGhhdCBzdWNoIGEgbWl4ZWQgbW9kZSBvZiBhdXRoZW50aWNh dGlvbiBpcw0KPiB2dWxuZXJhYmxlIHRvIE1pdE0uDQo+IEkgYW0gc2VyaW91c2x5IGNvbmNlcm5l ZCB0aGF0IHRoaXMgZHJhZnQgaXMgYWxzbyBpbiB0aGUgY2FzZS4NCj4gDQo+IEluIHBhcnRpY3Vs YXIsIHN1Y2ggYSBjb21iaW5hdGlvbiBvZiBUTFMgb2Ygc2VydmVyIGF1dGhlbnRpY2F0aW9uIGFu ZA0KPiBIVFRQIGRpZ2VzdCBhdXRoZW50aWNhdGlvbiBvZiBjbGllbnQsIGlzIHJhaXNlZCBhcyBh biBpbnNlY3VyZSBleGFtcGxlDQo+IGluIHNldmVyYWwgcGxhY2VzLCBpbmNsdWRpbmc6DQo+IC0g UkZDIDQxNjkNCj4gLSBBc29rYW4tTmllbWktTnliZXJnIGF0dGFjayAyMDAyLCBodHRwOi8vZXBy aW50LmlhY3Iub3JnLzIwMDIvMTYzLnBkZg0KPiANCj4gUXVvdGVkIGZyb20gUkZDIDQxNjksIFNl YyA0LjMsIE1hbi1pbi10aGUtTWlkZGxlIEF0dGFjaywNCj4gCSIgRm9yIGV4YW1wbGUsIHRoZSB1 c2Ugb2YgVExTIHdpdGggSFRUUCBEaWdlc3QgYXV0aGVudGljYXRpb24gKGkuZS4sDQo+ICAgIFRM UyBmb3Igc2VydmVyIGF1dGhlbnRpY2F0aW9uLCBhbmQgc3Vic2VxdWVudCB1c2Ugb2YgSFRUUCBE aWdlc3QgZm9yDQo+ICAgIGNsaWVudCBhdXRoZW50aWNhdGlvbikgaXMgYW4gaW5zdGFuY2Ugb2Yg c3VjaCBzY2VuYXJpby4gIEhUVFANCj4gICAgY2hhbGxlbmdlcyBhbmQgcmVzcG9uc2VzIGNhbiBi ZSBmZXRjaGVkIGZyb20gYW5kIHRvIGRpZmZlcmVudCBUTFMNCj4gICAgdHVubmVscyB3aXRob3V0 IG5vdGljaW5nIHRoZWlyIG9yaWdpbi4iDQo+IEFsdGhvdWdoIHRoZSBhYm92ZSBhdHRhY2sgbmVl ZHMgc29tZSBjb25kaXRpb25zLCBzdWNoIGEgdXNlIG9mIFRMUyBhbmQNCj4gSFRUUCBkaWdlc3Qg ZG9lcyBsZWFkIHRoZSBwcm9wb3NlZCBwcm90b2NvbCB0byBhIGRhbmdlcm91cyBzaXR1YXRpb24u DQo+IEl0IGlzIG1haW5seSBiZWNhdXNlLCAoZGV0YWlscyBjb3VsZCBiZSBmb3VuZCBpbiBBc29r YW4gZXQgYWwncyBwYXBlcikNCj4gLSBIVFRQIGRpZ2VzdCBhdXRoZW50aWNhdGlvbiBwcm90b2Nv bCBpcyB0b28gd2Vhay4gSXQgb25seSBoYXMgYQ0KPiBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rp b24gdG8gcnVuIGEgb25lLXdheSBjb21wdXRhdGlvbiBvZiB0aGUNCj4gcGFzc3dvcmQsIGxhY2sg b2Ygc2VjcmV0IGtleSBiYXNlZCBvciBwdWJsaWMga2V5IGJhc2VkIHByb3RlY3Rpb24sDQo+IHVu bGlrZSBUTFMuDQo+IC0gVGhlIHNlc3Npb24ga2V5IGlzIG5lZ290aWF0ZWQgaW4gb3V0ZXIgVExT IHByb3RvY29sIHNvbGVseS4NCj4gLSBUaGUgaW5uZXIgcHJvdG9jb2wgSFRUUCBkaWdlc3QgYXV0 aCBkb2VzIG5vdCByZWFsaXplIHRoZSBleGlzdGVuY2UNCj4gb2Ygb3V0ZXIgVExTIHByb3RvY29s Lg0KPiANCj4gQSBwb3NzaWJsZSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gbWlnaHQgYmUgdG8g Y3J5cHRvZ3JhcGhpY2FsbHkgYmluZA0KPiB0aGUgaW5uZXIgYW5kIG91dGVyIHByb3RvY29sLCBm b3IgZXhhbXBsZSwgdG8gZ2VuZXJhdGUgYSBzZXNzaW9uIGtleQ0KPiBmb3IgaW5uZXIgcHJvdG9j b2wuDQo+IEhvd2V2ZXIsIEhUVFAgZGlnZXN0IGRvZXMgbm90IHVzZSBub3IgZ2VuZXJhdGUgc2Vz c2lvbiBrZXkuLi4NCj4gQWdhaW4sIElNSE8sIGl0IHNlZW1zIG5vdCBhIGdvb2QgaWRlYSB0byB1 c2UgSFRUUCBkaWdlc3QgYXV0aCBwcm90b2NvbA0KPiBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9u LiBTb21lIG90aGVyIGNhbmRpZGF0ZXMgbmVlZCB0byBiZSBjb25zaWRlcmVkLg0KPiANCj4gQW5k IGFnYWluLCBJIGZlZWwgdGhhdCBpdCBpcyBuZWNlc3NhcnkgdG8gc2V0IHVwIGFuIGluZGVwZW5k ZW50IGRyYWZ0DQo+IHRha2luZyBjYXJlIG9mIFBBV1Mgc2VjdXJpdHksIHdoaWNoIG1heSBoZWxw IGRlc2lnbiBhbmQgaW1wbGVtZW50IHRoZQ0KPiBQQVdTIHByb3RvY29sLg0KPiBIb3BlIHRoYXQg b3VyIGRyYWZ0LCBkcmFmdC13dS1wYXdzLXNlY3V0aXR5LTAwLCBjb3VsZCBiZSBhIHN0YXJ0aW5n DQo+IHBvaW50LiBBbnkgY29tbWVudCBpcyB3ZWxjb21lLg0KPiANCj4gQlIsDQo+IFlhbmcNCj4g PT09PT09PT09PT09PT09PT09DQo+ICBZYW5nIEN1aSwgIFBoLkQuDQo+ICBIdWF3ZWkgVGVjaG5v bG9naWVzDQo+ICBjdWl5YW5nQGh1YXdlaS5jb20NCj4gDQo+PiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4+ILeivP7IyzogRGFzLCBTdWJpciBbbWFpbHRvOnNkYXNAYXBwY29tc2NpLmNvbV0NCj4+ILei y83KsbzkOiAyMDEyxOo31MIyNMjVIDc6NDYNCj4+IMrVvP7IyzogQ3VpeWFuZzsgR2Fib3IuQmFq a29Abm9raWEuY29tOyBwYXdzQGlldGYub3JnDQo+PiDW98ziOiBSRTogY29tbWVudHMgb24gZHJh ZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+PiANCj4+IFRoYW5rcyBmb3IgeW91ciBjb21t ZW50cy4gU29tZSBhbnN3ZXJzIGlubGluZS4NCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+PiBPZiBDdWl5YW5nDQo+PiBTZW50OiBNb25kYXksIEp1 bHkgMjMsIDIwMTIgODo0NSBBTQ0KPj4gVG86IEdhYm9yLkJhamtvQG5va2lhLmNvbTsgcGF3c0Bp ZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtwYXdzXSBjb21tZW50cyBvbiBkcmFmdC1kYXMtcGF3 cy1wcm90b2NvbC0wMi50eHQNCj4+IA0KPj4gSGkgQWxsLA0KPj4gDQo+PiBJIHdvdWxkIGxpa2Ug dG8gcHJvdmlkZSBzb21lIGNvbW1lbnRzIHRvIHRoaXMgZHJhZnQsIGZyb20gYSBzZWN1cml0eQ0K Pj4gcG9pbnQgb2Ygdmlldy4NCj4+IEhvcGUgdGhhdCBpdCB3aWxsIGJlIGhlbHBmdWwuDQo+PiAN Cj4+IFRoZSBUTFMgYW5kICJIVFRQIERpZ2VzdCBBdXRoIiBoYXZlIGJlZW4gdXNlZCwgYnV0IHNl ZW0gdW5jbGVhciBmb3IgbWUuDQo+PiBCZXNpZGVzLCBpdCBpcyBub3QgcmVjb21tZW5kZWQgdG8g dXNlIHRoZSBsYXR0ZXIgZm9yIHNvbWUgcmVhc29ucw0KPj4gbGlzdGVkIGJlbG93LiAtIEl0IGlz IHNhaWQgdGhhdCB0aGUgSFRUUC9UTFMgcHJvdG9jb2wgaXMgZGVwbG95ZWQgZm9yDQo+PiBtdXR1 YWwgYXV0aGVudGljYXRpb24uDQo+PiANCj4+IFNEPiBUaGlzIGlzIG5vdCBjb3JyZWN0Lg0KPj4g DQo+PiBIb3dldmVyLCAiSFRUUCBkaWdlc3QgYXV0aGVudGljYXRpb24iIGlzIGFjdHVhbGx5IHVz ZWQgZm9yDQo+PiBhdXRoZW50aWNhdGluZyB0aGUgZGV2aWNlLA0KPj4gDQo+PiBTRD4gIERpZ2Vz dCBBdXRoZW50aWNhdGlvbiBpcyB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGF0IHRo ZQ0KPj4gU0Q+IFBBV1MNCj4+IGxheWVyLg0KPj4gDQo+PiB3aGljaCBpcyB0eXBpY2FsbHkgd2Vh a2VyIHRoYW4gbm9ybWFsIFRMUy4NCj4+IA0KPj4gU0Q+IFdoeSBpcyBpdCB3ZWFrZXI/DQo+PiAN Cj4+IE9ubHkgdGhlIHNlcnZlciBzaWRlIGF1dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCBieSBU TFMNCj4+IGNlcnRpZmljYXRlLWJhc2VkIGNyeXB0byBtZXRob2QuDQo+PiAtIEl0IGFwcGVhcnMg dGhhdCBhdXRoZW50aWNhdGlvbiBpcyBkb25lIGluIGRpZmZlcmVudCBsYXllcnMsIGkuZS4sDQo+ PiBkZXZpY2UgaXMgZG9uZSBpbiBQQVdTIGxheWVyIGJ5ICJIVFRQIGRpZ2VzdCBhdXRoIiBhbmQg c2VydmVyIGlzDQo+PiBhY2hpZXZlZCBpbiBUTFMgbGF5ZXIgYnkgY2VydGlmaWNhdGUuDQo+PiAN Cj4+IFNEPiBZZXMsIGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgYXQgdGhlIFBBV1MgbGF5ZXIgYnkg dXNpbmcgZGlnZXN0DQo+PiBhdXRoZW50aWNhdGlvbi4NCj4+IA0KPj4gSSBkbyBub3QgdW5kZXJz dGFuZCB3aHkgc2VjdXJpdHkgaXMgZG9uZSBpbiBtaXhlZCBsYXllcnM/DQo+PiANCj4+IC0gSXQg aXMgc2FpZCB0aGF0IGNvbmZpZGVudGlhbGl0eSBpcyBwcm90ZWN0ZWQgaW4gSFRUUFMgbGF5ZXIs IGJ1dA0KPj4gaWYgYXV0aGVudGljYXRpbmcgZGV2aWNlIGlzIGFjaGlldmVkIGluIGRpZmZlcmVu dCBsYXllciAoaS5lLiBpbg0KPj4gUEFXUyBsYXllciksIGhvdyBjYW4gdGhlIGRldmljZSBhbmQg c2VydmVyIG5lZ290aWF0ZSB0aGUgc2Vzc2lvbiBrZXk/DQo+PiANCj4+IFNEPiBEdXJpbmcgbm9y bWFsIFRMUyBuZWdvdGlhdGlvbi4NCj4+IA0KPj4gLSBPciwgaWYgbXkgYWJvdmUgdW5kZXJzdGFu ZGluZyBpcyB3cm9uZyBhbmQgbXV0dWFsIGF1dGhlbnRpY2F0aW9uDQo+PiBpcyBpbmRlZWQgZG9u ZSBpbiBUTFMgbGF5ZXIsIHdoeSBkb2VzIGl0IG5lZWQgdG8gaGF2ZSBhZGRpdGlvbmFsDQo+PiAi SFRUUCBkaWdlc3QgYXV0aCIgaW4gUEFXUyBsYXllcj8NCj4+IA0KPj4gU0Q+IE9ubHkgY2xpZW50 IGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgYXQgdGhlIFBBV1MgbGF5ZXIuIE9mIGNvdXJzZQ0KPj4g U0Q+IGNsaWVudA0KPj4gYXV0aCBjYW4gYmUgZG9uZSBhdCB0aGUgVExTIGxheWVyLiBUaGVuIG9u ZSBuZWVkcyB0byBoYXZlIGNoYW5uZWwNCj4+IGJpbmRpbmcgYW5kIHRoYXQncyBhbm90aGVyIGFw cHJvYWNoLg0KPj4gDQo+PiAtICJIVFRQIGRpZ2VzdCBhdXRoIiBvbmx5IHByb3ZpZGVzIGEgaGFz aC1iYXNlZCBwcm90ZWN0aW9uIGZvciBzZWNyZXRzDQo+PiBsaWtlIHBhc3N3b3JkIGFuZCBJRCwg YW5kIGlzIGtub3duIHRvIGJlIHZ1bG5lcmFibGUgdG8gTWl0TQ0KPj4gKE1hbi1pbi10aGUtTWlk ZGxlKSBhdHRhY2tzLiBTaW5jZSBhY2NvcmRpbmcgdG8gdGhlIFBBV1MgV0cgZG9jdW1lbnQsDQo+ PiBkcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTA2LCBDaGFwdGVy IDgsIHRocmVhdCA3LA0KPj4gTWl0TSBhdHRhY2sgc2hvdWxkIGJlIHRod2FydGVkLiBUaGlzIGRy YWZ0IHVzaW5nICJIVFRQIGRpZ2VzdCBhdXRoIg0KPj4gb2J2aW91c2x5IGRvZXMgbm90IHNhdGlz ZnkgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50Lg0KPj4gDQo+PiBTRD4gIEkgZG8gbm90IHVuZGVy c3RhbmQgdGhpcy4gSFRUUC9UTFMgaXMgdXNlZCBpbiBvdXIgc2NoZW1lLg0KPj4gDQo+PiAtICJI VFRQIGRpZ2VzdCBhdXRoIiBkaWZmZXJzIGZyb20gSFRUUCBvdmVyIFRMUywgd2hlcmUgdGhlIGZv cm1lcg0KPj4gcHJvdmlkZXMgbm8gZW5jcnlwdGlvbiBmb3IgY29udGVudCwgYnV0IHRoZSBsYXR0 ZXIgY2FuIGVuY3J5cHQgdGhlDQo+PiBjb250ZW50IGJ5IFB1YmxpYyBLZXkgY3J5cHRvLiBUaHVz IFRMUyBpcyBwcmVmZXJyZWQuIC0gIkhUVFAgZGlnZXN0DQo+PiBhdXRoIiBkb2VzIG5vdCBzdXBw b3J0IEhNQUMgYWxnb3JpdGhtIChzby1jYWxsZWQgS2V5ZWQgSGFzaCksIHRodXMgaXQNCj4+IGlz IHlldCBhIGxpdHRsZSByaXNreSB0byB1c2UgU0hBLTEgdG8gcmVwbGFjZSBjdXJyZW50IE1ENSBh bGdvcml0aG0sDQo+PiBiZWNhdXNlIE5JU1QgaGFzIG5vdCByZWNvbW1lbmRlZCB0byB1c2UgdGhl IGNvbGxpc2lvbiByZXNpc3RhbmNlIG9mDQo+PiBTSEEtMSAoYnV0IEhNQUMtU0hBMSBpcyBmaW5l KS4gSW4gY29udHJhc3QsIFRMUyBzdXBwb3J0cyBITUFDIGFuZCBkb2VzDQo+PiBub3QgaGF2ZSBz dWNoIGEgcHJvYmxlbS4NCj4+IA0KPj4gU0Q+IFllcyBpdCBzaG91bGQgYmUgSE1BQy1TSEExLg0K Pj4gDQo+PiBGcm9tIHRoZSBhYm92ZSBhbmFseXNpcywgaXQgaXMgY2xlYXIgdG8gc2VlIHRoYXQg dGhlIHNlY3VyaXR5IGFuZA0KPj4gcHJpdmFjeSBvZiBQQVdTIGlzIG5vdCBzdHJhaWdodGZvcndh cmQgYW5kIG5lZWRzIHRvIGJlIGNhcmVmdWxseQ0KPj4gaW52ZXN0aWdhdGVkLCBmb3IgZGVzaWdu IGFuZCBpbXBsZW1lbnRhdGlvbi4NCj4+IEl0IGlzIGFsc28gdGhlIHJlYXNvbiB3aHkgd2UgaGF2 ZSBzdWJtaXR0ZWQgYW4gaW5kZXBlbmRlbnQgZHJhZnQgZm9yDQo+PiBQQVdTIHNlY3VyaXR5LCB0 byBwcm92aWRlIGEgYmFzZSBmb3IgZGlzY3Vzc2lvbi4NCj4+IA0KPj4gQlIsDQo+PiBZYW5nDQo+ PiA9PT09PT09PT09PT09PT09PT0NCj4+ICBZYW5nIEN1aSwgIFBoLkQuDQo+PiAgSHVhd2VpIFRl Y2hub2xvZ2llcw0KPj4gIGN1aXlhbmdAaHVhd2VpLmNvbQ0KPj4gDQo+Pj4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+Pj4gt6K8/sjLOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJv dW5jZXNAaWV0Zi5vcmddILT6se0NCj4+PiBHYWJvci5CYWprb0Bub2tpYS5jb20NCj4+PiC3osvN yrG85DogMjAxMsTqN9TCMjLI1SA3OjMxDQo+Pj4gytW8/sjLOiBwYXdzQGlldGYub3JnDQo+Pj4g 1vfM4jogW3Bhd3NdIGNvbW1lbnRzIG9uIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0K Pj4+IA0KPj4+IEl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgaWYgdGhlcmUgd2VyZSBkaXNjdXNzaW9u cyBvbiB0aGUgZHJhZnRzIHRvDQo+Pj4gc3VibWl0dGVkIGFoZWFkIG9mIHRoZSBGMkYgcHJlc2Vu dGF0aW9ucy4NCj4+PiBUaHVzLCBJJ3ZlIHRha2VuIHRoZSBpbml0aWF0aXZlIHRvIHJlYWQgdGhl IGRyYWZ0IGFuZCBwcm92aWRlIHNvbWUNCj4+PiBpbml0aWFsDQo+Pj4gY29tbWVudHM6DQo+Pj4g DQo+Pj4gMS4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGUgaW5pdGlhbGl6 YXRpb24gcHJvY2VzcyBhbmQNCj4+PiB3aHkgbWVzc2FnZXMgSU5ULVJFUSBhbmQgSU5ULVJFU1Ag YXJlIG5lY2Vzc2FyeS4gVGhlIGNhcGFiaWxpdHkNCj4+PiBleGNoYW5nZSBjYW4gYmUgZG9uZSBk dXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiBXZSBtYXkgZXZlbg0KPj4+IGNvbnNpZGVy IG1lcmdpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIHdpdGggdGhlIERCIHF1ZXJ5IHByb2Nl c3MsDQo+Pj4gdGhlcmUgZG9lc24ndCBzZWVtIHRvIGJlIGFueSByZWFzb24gdG8gaGF2ZSB0aGVt IGFzIHNlcGFyYXRlIG1lc3NhZ2VzLg0KPj4+IA0KPj4+IDIuIHlvdSBtYXkgbmVlZCBhIHNlY3Rp b24gd2hlcmUgeW91IG1hcCB5b3VyIG5ld2x5IGRlZmluZWQNCj4+PiBtZXNzYWdlcyB0byBleGlz dGluZyBodHRwIHByb3RvY29sIG1lc3NhZ2VzLiBJIHNhdyB0aGF0IHlvdSBoYXZlDQo+Pj4gYW4g ZXhhbXBsZSBzZWN0aW9uLCBidXQgYSBub3JtYXRpdmUgc2VjdGlvbiB3b3VsZCBiZSBtb3JlIGRl c2lyYWJsZS4NCj4+PiANCj4+PiAzLiB0aGUgZGF0YSBtb2RlbCBwYXJ0IG5lZWRzIHNvbWUgbW9y ZSB3b3JrLiBUaGUgc3RydWN0dXJlIGlzIG5vdCB2ZXJ5DQo+Pj4gY2xlYXIgdG8gbWUsIGFuZCBz b21lIG9mIHRoZSBhdHRyaWJ1dGVzIHJlZmVyZW5jZSBvYnNvbGV0ZSBSRkMuIEVnLA0KPj4+IFJG QzM4MjUgaXMgcmVmZXJlbmNlZCBmb3IgdGhlIGxvbmdpdHVkZS9sYXRpdHVkZSBhdHRyaWJ1dGVz LiBJIHRoaW5rDQo+Pj4geW91IHNob3VsZCBiZSBiZXR0ZXIgb2YgdXNpbmcgYW4gZWxlbWVudCBm b3IgZ2VvLWxvY2F0aW9uLCB3aXRoIHRoZQ0KPj4+IHN0cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJG QzU0OTEsIGEgc2VwYXJhdGUgZWxlbWVudCBmb3IgdGhlIGNpdmljDQo+Pj4gbG9jYXRpb24sIHdp dGggdGhlIHN0cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJGQzUxMzksIGV0Yy4gSW5zdGVhZCBvZg0K Pj4+IHRoZSBEZXZpY2VPd25lciBvYmplY3QsIEkgd291bGQgdXNlIGEgdkNhcmQgZWxlbWVudCwg d2l0aCB0aGUNCj4+PiBzdHJ1Y3R1cmUgYXMgZGVmaW5lZCBpbiBSRkMyNDI2LiBZb3UgbWF5IGFs c28gbmVlZCBhbiBpQ2FsZW5kYXINCj4+PiBlbGVtZW50IChSRkM1NTQ1KSB0byBzcGVjaWZ5IHRo ZSBjaGFubmVsIGF2YWlsYWJpbGl0eSB0aW1lIChlZywgd2hlbg0KPj4+IHRoZSBjaGFubmVsIGlz IG5vdCBhdmFpbGFibGUgZm9yIHRoZSBmdWxsIDI0SCkuIEV0Yy4NCj4+PiANCj4+PiBNb3JlIGNv bW1lbnRzIGFyZSB3ZWxjb21lLg0KPj4+IC0gR2Fib3INCj4+PiANCj4+PiANCj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcNCj4+PiBbbWFp bHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBEYXMsIFN1YmlyIFNl bnQ6DQo+Pj4gU2F0dXJkYXksIEp1bHkgMTQsIDIwMTIgNzozNiBBTSBUbzogcGF3c0BpZXRmLm9y ZyBTdWJqZWN0OiBbcGF3c10gRlc6DQo+Pj4gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCj4+PiANCj4+PiBEZWFyIENoYWlycywNCj4+ PiBXZSBoYXZlIHVwZGF0ZWQgb3VyIGRyYWZ0IGFuZCB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYSBz bG90IGluDQo+Pj4gSUVURi04NCB0byBwcmVzZW50IGl0Lg0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+ Pj4gX1N1YmlyDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDE0LCAyMDEyIDEwOjMwDQo+Pj4gQU0gVG86IERhcywg U3ViaXIgQ2M6IGptYWx5YXJAdGVsY29yZGlhLmNvbTsNCj4+PiBkLmpvc2x5bkBzcGVjdHJ1bWJy aWRnZS5jb20gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4+IGRyYWZ0 LWRhcy1wYXdzLXByb3RvY29sLSAwMi50eHQNCj4+PiANCj4+PiANCj4+PiBBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0IGhhcyBiZWVuDQo+Pj4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdWJpciBEYXMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KPj4+IA0KPj4+IEZpbGVuYW1lOgkgZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wg UmV2aXNpb246CSAwMiBUaXRsZToJCSBEZXZpY2UgdG8NCj4+PiBEYXRhYmFzZSBQcm90b2NvbCBm b3IgV2hpdGUgU3BhY2UgQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTQgV0cgSUQ6CQkNCj4+PiBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24gTnVtYmVyIG9mIHBhZ2VzOiAzMiBVUkw6DQo+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIu dHh0DQo+Pj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWRhcy1wYXdzLQ0KPj4+IHByb3RvY29sIEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFzLXBhd3MtDQo+Pj4gcHJvdG9jb2wtMDIgRGlmZjoN Cj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWRhcy1wYXdzLXBy b3RvY29sLTAyDQo+Pj4gDQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgdGhlIGBQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3BhY2UNCj4+PiAgICBkYXRhYmFz ZSAoUEFXUyknIHRoYXQgdXNlcyBIVFRQL1RMUyBhcyB0cmFuc3BvcnQuICBUaGUgcHJvdG9jb2wg aXMNCj4+PiAgICB1c2VkIGZvciByZXRyaWV2aW5nIHRoZSBuZWNlc3NhcnkgVFYgd2hpdGUgc3Bh Y2UgaW5mb3JtYXRpb24gKGUuZy4sDQo+Pj4gICAgY2hhbm5lbCwgZnJlcXVlbmN5LCB0cmFuc21p dHRlZCBwb3dlcikgYXQgYSBnaXZlbiBsb2NhdGlvbiBhbmQgdGltZQ0KPj4+ICAgIGZyb20gYSBk YXRhYmFzZSB0aGF0IGlzIG9wZXJhdGluZyB1bmRlciBhIHJlZ3VsYXRvcnkgZG9tYWluLiAgVGhl DQo+Pj4gICAgZG9jdW1lbnQgaW5jbHVkZXMgdGhlIHByb3RvY29sIGZ1bmN0aW9uYWxpdGllcywg aXRzIGVsZW1lbnRzLA0KPj4+ICAgIGNvcnJlc3BvbmRpbmcgZGF0YSBtb2RlbCBhbmQgcmVjb21t ZW5kcyBpdHMgZW5jb2Rpbmcgc2NoZW1lLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IFRoZSBJRVRG IFNlY3JldGFyaWF0DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+IHBhd3NAaWV0Zi5vcmcNCj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHBhd3MgbWFpbGluZyBs aXN0DQo+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBwYXdzQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4g cGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCg0KDQoNCg== From sdas@appcomsci.com Wed Jul 25 22:26:13 2012 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 0CFE921F859A for ; Wed, 25 Jul 2012 22:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5 tests=[AWL=-1.651, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 NG-HGL4ZUINM for ; Wed, 25 Jul 2012 22:26:11 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 762A721F858F for ; Wed, 25 Jul 2012 22:26:10 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q6Q5Q3Ym025764; Thu, 26 Jul 2012 01:26:03 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q6Q5Q24Y030842; Thu, 26 Jul 2012 01:26:02 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Thu, 26 Jul 2012 01:26:02 -0400 From: "Das, Subir" To: Peter McCann , Cuiyang , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQAB/KozAAGpqGMABA6hCAABVA+6A= Date: Thu, 26 Jul 2012 05:25:59 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DD31@SZXEML508-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E18FC3@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E18FC3@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 05:26:13 -0000 QW5zd2VycyBpbmxpbmUuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGV0 ZXIgTWNDYW5uIFttYWlsdG86UGV0ZXIuTWNDYW5uQGh1YXdlaS5jb21dIA0KU2VudDogV2VkbmVz ZGF5LCBKdWx5IDI1LCAyMDEyIDM6MDQgUE0NClRvOiBDdWl5YW5nOyBEYXMsIFN1YmlyOyBHYWJv ci5CYWprb0Bub2tpYS5jb207IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBjb21tZW50cyBv biBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCg0KSXQgYWxzbyBhcHBlYXJzIHRoYXQg ZHJhZnQtZGFzIHJlLWltcGxlbWVudHMgSFRUUCBEaWdlc3QgYXQgdGhlIGFwcGxpY2F0aW9uIGxh eWVyLCByYXRoZXIgdGhhbiBhdHRlbXB0aW5nIHRvIHVzZSBzdGFuZGFyZCBIVFRQIERpZ2VzdC4g SSBhbSBjdXJpb3VzIGFzIHRvIHdoeSB5b3UgbWFkZSB0aGlzIGNob2ljZS4gIA0KDQpTRD4gIFRo aXMgaXMgbm90IG5ldy4gT3RoZXIgSUVURiBwcm90b2NvbHMgaGF2ZSB1c2VkIHRoaXMsIGZvciBl eGFtcGxlLCBSRkMgMzI2MQ0KDQpJcyBpdCBzbyB0aGF0IHlvdSBjYW4gdXBncmFkZSB0aGUgaGFz aCBmdW5jdGlvbiBmcm9tIE1ENSB0byBTSEEtMT8NCg0KU0Q+IElFVEYgZG9lcyBub3QgcmVjb21t ZW5kICB1c2luZyBNRDUgYW55bW9yZS4gDQoNCkFsc28sIHlvdSBkb24ndCBzaG93IHRoZSBtZXNz YWdlcyB0aGF0IHJlbGF5IHRoZSBub25jZSB2YWx1ZSBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNs aWVudC4gIEkgdGhpbmsgeW91IHdpbGwgbmVlZCB0byBzcGVjaWZ5IHRoYXQgbWVzc2FnZSBhcyB3 ZWxsLiAgSFRUUCBkb2VzIHRoaXMgd2l0aCBhIDQwMSBVbmF1dGhvcml6ZWQgcmVzcG9uc2UuDQoN ClNEPiBUaGlzIGlzIGRvbmUgdmlhIGluaXRpYWxpemF0aW9uIHJlc3BvbnNlIG1lc3NhZ2UsIElO SVRfUkVTUC4gIFJlbWVtYmVyIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBwZXJmb3JtZWQgZHVy aW5nIGluaXRpYWxpemF0aW9uIHN0YWdlLiBXZSBzaG91bGQgaGF2ZSBpbmNsdWRlZCB0aGUgZGV0 YWlscyBvZiBJTklUX1JFUSBhbmQgSU5JVF9SRVNQIG1lc3NhZ2VzIGluIGV4YW1wbGUgc2VjdGlv bi4gV2lsbCBpbmNsdWRlIHRoaXMgaW4gbmV4dCB2ZXJzaW9uLg0KDQpJdCBhbHNvIGxvb2tzIGxp a2UgeW91IGFyZSBub3Qgc2VuZGluZyBhbnkgcmVzcG9uc2VzIGF0IGFsbCBpbiB5b3VyIGV4YW1w bGVzLCBqdXN0IHVzaW5nIFBPU1QgaW4gYm90aCBkaXJlY3Rpb25zLiAgVGhpcyBzZWVtcyBzdHJh bmdlLg0KDQpTRD4gIFRoZSBkYXRhYmFzZSByZXNwb25kcyB0byBhbGwgcmVxdWVzdHMuIEluIG91 ciBleGFtcGxlLCAgd2UgY3VycmVudGx5IHNob3cgUEFXUyBwcm90b2NvbCBtZXNzYWdlICBkZXRh aWxzIHRoYXQgYXJlIGluY2x1ZGVkIGluIHRoZSBib2R5IG9mIHRoZSBIVFRQIFBPU1QuDQoNCg0K SXQgbWlnaHQgYmUgYmV0dGVyIHRvIHJlbHkgb24gY2xpZW50IGNlcnRpZmljYXRlcyBhdCB0aGUg VExTIGxheWVyIHRvIGF1dGhlbnRpY2F0ZSB0aGUgbWFzdGVyIGRldmljZS4NCg0KU0Q+IFdlIGRv IG5vdCBhc3N1bWUgdGhhdCB0aGUgY2xpZW50IGhhcyBjZXJ0LiBPdXIgZXhwZXJpZW5jZSB3aXRo IFdTRCBtYW51ZmFjdHVyZXMgaXMgdGhhdCB0aGV5IHByZWZlciB0aGUgbW9kZWwgb2YgYSBzaGFy ZWQgc2VjcmV0IGZvciBNYXN0ZXIgV1NEIGF1dGhlbnRpY2F0aW9uIHRvIG1hbmFnZSBjb3N0cy4N Cg0KRm9yIGF1dGhlbnRpY2F0aW5nIHRoZSBzbGF2ZSBkZXZpY2VzLCB3ZSBtaWdodCBuZWVkIHNv bWV0aGluZyBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIuICBUaGF0IGlzIGEgc2VwYXJhdGUgZGlz Y3Vzc2lvbiB0aGF0IHN0aWxsIG5lZWRzIHRvIGhhcHBlbiAobmVpdGhlciBkcmFmdCByaWdodCBu b3cgZGVhbHMgd2l0aCBhdXRoZW50aWNhdGluZyB0aGUgc2xhdmUgZGV2aWNlIGlkZW50aWZpZXJz KS4NCg0KU0Q+IE91ciB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYXV0aGVudGljYXRpbmcgdGhlIHNs YXZlIGRldmljZXMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgUEFXUy4gVGhlcmUgaXMgbm8gZGly ZWN0IGNvbW11bmljYXRpb24gYmV0d2VlbiBzbGF2ZSBkZXZpY2VzIGFuZCB0aGUgZGF0YWJhc2Uu IEhvd2V2ZXIsIHdlIGRvIHN1cHBvcnQgdGhlIGNhcGFiaWxpdHkgb2YgdmFsaWRhdGluZyB0aGUg c2xhdmUgZGV2aWNlcyB2aWEgTVNELiANCg0KLVBldGUNCg0KDQpDdWl5YW5nIHdyb3RlOiANCj4g VGhhbmtzIGZvciB5b3VyIGFuc3dlcnMuDQo+IA0KPiBCdXQgdGhlbiBJIHJlYWxpemVkIHRoYXQg dGhlIHByb3Bvc2FsIGlzIHVzaW5nIGEga2luZCBvZiB0d28tbGF5ZXIgDQo+IGF1dGhlbnRpY2F0 aW9uIHByb3RvY29scywgcy50LiBhbiBvdXRlciBsYXllciBwcm90b2NvbCBvZiBUTFMgDQo+IGF1 dGhlbnRpY2F0aW9uIG9mIHNlcnZlciAoZGF0YWJhc2UpLCBhbmQgYW4gaW5uZXIgbGF5ZXIgcHJv dG9jb2wgDQo+IGF1dGhlbnRpY2F0aW9uIG9mIGNsaWVudCAoTWFzdGVyIGRldmljZSkuDQo+IFVu Zm9ydHVuYXRlbHksIGl0IGlzIGtub3duIHRoYXQgc3VjaCBhIG1peGVkIG1vZGUgb2YgYXV0aGVu dGljYXRpb24gaXMgDQo+IHZ1bG5lcmFibGUgdG8gTWl0TS4NCj4gSSBhbSBzZXJpb3VzbHkgY29u Y2VybmVkIHRoYXQgdGhpcyBkcmFmdCBpcyBhbHNvIGluIHRoZSBjYXNlLg0KPiANCj4gSW4gcGFy dGljdWxhciwgc3VjaCBhIGNvbWJpbmF0aW9uIG9mIFRMUyBvZiBzZXJ2ZXIgYXV0aGVudGljYXRp b24gYW5kIA0KPiBIVFRQIGRpZ2VzdCBhdXRoZW50aWNhdGlvbiBvZiBjbGllbnQsIGlzIHJhaXNl ZCBhcyBhbiBpbnNlY3VyZSBleGFtcGxlIA0KPiBpbiBzZXZlcmFsIHBsYWNlcywgaW5jbHVkaW5n Og0KPiAtIFJGQyA0MTY5DQo+IC0gQXNva2FuLU5pZW1pLU55YmVyZyBhdHRhY2sgMjAwMiwgaHR0 cDovL2VwcmludC5pYWNyLm9yZy8yMDAyLzE2My5wZGYNCj4gDQo+IFF1b3RlZCBmcm9tIFJGQyA0 MTY5LCBTZWMgNC4zLCBNYW4taW4tdGhlLU1pZGRsZSBBdHRhY2ssDQo+IAkiIEZvciBleGFtcGxl LCB0aGUgdXNlIG9mIFRMUyB3aXRoIEhUVFAgRGlnZXN0IGF1dGhlbnRpY2F0aW9uIChpLmUuLA0K PiAgICBUTFMgZm9yIHNlcnZlciBhdXRoZW50aWNhdGlvbiwgYW5kIHN1YnNlcXVlbnQgdXNlIG9m IEhUVFAgRGlnZXN0IGZvcg0KPiAgICBjbGllbnQgYXV0aGVudGljYXRpb24pIGlzIGFuIGluc3Rh bmNlIG9mIHN1Y2ggc2NlbmFyaW8uICBIVFRQDQo+ICAgIGNoYWxsZW5nZXMgYW5kIHJlc3BvbnNl cyBjYW4gYmUgZmV0Y2hlZCBmcm9tIGFuZCB0byBkaWZmZXJlbnQgVExTDQo+ICAgIHR1bm5lbHMg d2l0aG91dCBub3RpY2luZyB0aGVpciBvcmlnaW4uIg0KPiBBbHRob3VnaCB0aGUgYWJvdmUgYXR0 YWNrIG5lZWRzIHNvbWUgY29uZGl0aW9ucywgc3VjaCBhIHVzZSBvZiBUTFMgYW5kIA0KPiBIVFRQ IGRpZ2VzdCBkb2VzIGxlYWQgdGhlIHByb3Bvc2VkIHByb3RvY29sIHRvIGEgZGFuZ2Vyb3VzIHNp dHVhdGlvbi4NCj4gSXQgaXMgbWFpbmx5IGJlY2F1c2UsIChkZXRhaWxzIGNvdWxkIGJlIGZvdW5k IGluIEFzb2thbiBldCBhbCdzIHBhcGVyKQ0KPiAtIEhUVFAgZGlnZXN0IGF1dGhlbnRpY2F0aW9u IHByb3RvY29sIGlzIHRvbyB3ZWFrLiBJdCBvbmx5IGhhcyBhIA0KPiBjcnlwdG9ncmFwaGljIGhh c2ggZnVuY3Rpb24gdG8gcnVuIGEgb25lLXdheSBjb21wdXRhdGlvbiBvZiB0aGUgDQo+IHBhc3N3 b3JkLCBsYWNrIG9mIHNlY3JldCBrZXkgYmFzZWQgb3IgcHVibGljIGtleSBiYXNlZCBwcm90ZWN0 aW9uLCANCj4gdW5saWtlIFRMUy4NCj4gLSBUaGUgc2Vzc2lvbiBrZXkgaXMgbmVnb3RpYXRlZCBp biBvdXRlciBUTFMgcHJvdG9jb2wgc29sZWx5Lg0KPiAtIFRoZSBpbm5lciBwcm90b2NvbCBIVFRQ IGRpZ2VzdCBhdXRoIGRvZXMgbm90IHJlYWxpemUgdGhlIGV4aXN0ZW5jZSANCj4gb2Ygb3V0ZXIg VExTIHByb3RvY29sLg0KPiANCj4gQSBwb3NzaWJsZSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0g bWlnaHQgYmUgdG8gY3J5cHRvZ3JhcGhpY2FsbHkgYmluZCANCj4gdGhlIGlubmVyIGFuZCBvdXRl ciBwcm90b2NvbCwgZm9yIGV4YW1wbGUsIHRvIGdlbmVyYXRlIGEgc2Vzc2lvbiBrZXkgDQo+IGZv ciBpbm5lciBwcm90b2NvbC4NCj4gSG93ZXZlciwgSFRUUCBkaWdlc3QgZG9lcyBub3QgdXNlIG5v ciBnZW5lcmF0ZSBzZXNzaW9uIGtleS4uLg0KPiBBZ2FpbiwgSU1ITywgaXQgc2VlbXMgbm90IGEg Z29vZCBpZGVhIHRvIHVzZSBIVFRQIGRpZ2VzdCBhdXRoIHByb3RvY29sIA0KPiBmb3IgY2xpZW50 IGF1dGhlbnRpY2F0aW9uLiBTb21lIG90aGVyIGNhbmRpZGF0ZXMgbmVlZCB0byBiZSBjb25zaWRl cmVkLg0KPiANCj4gQW5kIGFnYWluLCBJIGZlZWwgdGhhdCBpdCBpcyBuZWNlc3NhcnkgdG8gc2V0 IHVwIGFuIGluZGVwZW5kZW50IGRyYWZ0IA0KPiB0YWtpbmcgY2FyZSBvZiBQQVdTIHNlY3VyaXR5 LCB3aGljaCBtYXkgaGVscCBkZXNpZ24gYW5kIGltcGxlbWVudCB0aGUgDQo+IFBBV1MgcHJvdG9j b2wuDQo+IEhvcGUgdGhhdCBvdXIgZHJhZnQsIGRyYWZ0LXd1LXBhd3Mtc2VjdXRpdHktMDAsIGNv dWxkIGJlIGEgc3RhcnRpbmcgDQo+IHBvaW50LiBBbnkgY29tbWVudCBpcyB3ZWxjb21lLg0KPiAN Cj4gQlIsDQo+IFlhbmcNCj4gPT09PT09PT09PT09PT09PT09DQo+ICBZYW5nIEN1aSwgIFBoLkQu DQo+ICBIdWF3ZWkgVGVjaG5vbG9naWVzDQo+ICBjdWl5YW5nQGh1YXdlaS5jb20NCj4gDQo+PiAt LS0tLdPKvP7Urbz+LS0tLS0NCj4+ILeivP7IyzogRGFzLCBTdWJpciBbbWFpbHRvOnNkYXNAYXBw Y29tc2NpLmNvbV0NCj4+ILeiy83KsbzkOiAyMDEyxOo31MIyNMjVIDc6NDYNCj4+IMrVvP7Iyzog Q3VpeWFuZzsgR2Fib3IuQmFqa29Abm9raWEuY29tOyBwYXdzQGlldGYub3JnDQo+PiDW98ziOiBS RTogY29tbWVudHMgb24gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+PiANCj4+IFRo YW5rcyBmb3IgeW91ciBjb21tZW50cy4gU29tZSBhbnN3ZXJzIGlubGluZS4NCj4+IA0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPj4gT2YgQ3VpeWFuZw0K Pj4gU2VudDogTW9uZGF5LCBKdWx5IDIzLCAyMDEyIDg6NDUgQU0NCj4+IFRvOiBHYWJvci5CYWpr b0Bub2tpYS5jb207IHBhd3NAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tbWVu dHMgb24gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+PiANCj4+IEhpIEFsbCwNCj4+ IA0KPj4gSSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgc29tZSBjb21tZW50cyB0byB0aGlzIGRyYWZ0 LCBmcm9tIGEgc2VjdXJpdHkgDQo+PiBwb2ludCBvZiB2aWV3Lg0KPj4gSG9wZSB0aGF0IGl0IHdp bGwgYmUgaGVscGZ1bC4NCj4+IA0KPj4gVGhlIFRMUyBhbmQgIkhUVFAgRGlnZXN0IEF1dGgiIGhh dmUgYmVlbiB1c2VkLCBidXQgc2VlbSB1bmNsZWFyIGZvciBtZS4NCj4+IEJlc2lkZXMsIGl0IGlz IG5vdCByZWNvbW1lbmRlZCB0byB1c2UgdGhlIGxhdHRlciBmb3Igc29tZSByZWFzb25zIA0KPj4g bGlzdGVkIGJlbG93LiAtIEl0IGlzIHNhaWQgdGhhdCB0aGUgSFRUUC9UTFMgcHJvdG9jb2wgaXMg ZGVwbG95ZWQgZm9yIA0KPj4gbXV0dWFsIGF1dGhlbnRpY2F0aW9uLg0KPj4gDQo+PiBTRD4gVGhp cyBpcyBub3QgY29ycmVjdC4NCj4+IA0KPj4gSG93ZXZlciwgIkhUVFAgZGlnZXN0IGF1dGhlbnRp Y2F0aW9uIiBpcyBhY3R1YWxseSB1c2VkIGZvciANCj4+IGF1dGhlbnRpY2F0aW5nIHRoZSBkZXZp Y2UsDQo+PiANCj4+IFNEPiAgRGlnZXN0IEF1dGhlbnRpY2F0aW9uIGlzIHVzZWQgdG8gYXV0aGVu dGljYXRlIHRoZSBjbGllbnQgYXQgdGhlIA0KPj4gU0Q+IFBBV1MNCj4+IGxheWVyLg0KPj4gDQo+ PiB3aGljaCBpcyB0eXBpY2FsbHkgd2Vha2VyIHRoYW4gbm9ybWFsIFRMUy4NCj4+IA0KPj4gU0Q+ IFdoeSBpcyBpdCB3ZWFrZXI/DQo+PiANCj4+IE9ubHkgdGhlIHNlcnZlciBzaWRlIGF1dGhlbnRp Y2F0aW9uIGlzIHBlcmZvcm1lZCBieSBUTFMgDQo+PiBjZXJ0aWZpY2F0ZS1iYXNlZCBjcnlwdG8g bWV0aG9kLg0KPj4gLSBJdCBhcHBlYXJzIHRoYXQgYXV0aGVudGljYXRpb24gaXMgZG9uZSBpbiBk aWZmZXJlbnQgbGF5ZXJzLCBpLmUuLCANCj4+IGRldmljZSBpcyBkb25lIGluIFBBV1MgbGF5ZXIg YnkgIkhUVFAgZGlnZXN0IGF1dGgiIGFuZCBzZXJ2ZXIgaXMgDQo+PiBhY2hpZXZlZCBpbiBUTFMg bGF5ZXIgYnkgY2VydGlmaWNhdGUuDQo+PiANCj4+IFNEPiBZZXMsIGF1dGhlbnRpY2F0aW9uIGlz IGRvbmUgYXQgdGhlIFBBV1MgbGF5ZXIgYnkgdXNpbmcgZGlnZXN0DQo+PiBhdXRoZW50aWNhdGlv bi4NCj4+IA0KPj4gSSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgc2VjdXJpdHkgaXMgZG9uZSBpbiBt aXhlZCBsYXllcnM/DQo+PiANCj4+IC0gSXQgaXMgc2FpZCB0aGF0IGNvbmZpZGVudGlhbGl0eSBp cyBwcm90ZWN0ZWQgaW4gSFRUUFMgbGF5ZXIsIGJ1dCBpZiANCj4+IGF1dGhlbnRpY2F0aW5nIGRl dmljZSBpcyBhY2hpZXZlZCBpbiBkaWZmZXJlbnQgbGF5ZXIgKGkuZS4gaW4gUEFXUyANCj4+IGxh eWVyKSwgaG93IGNhbiB0aGUgZGV2aWNlIGFuZCBzZXJ2ZXIgbmVnb3RpYXRlIHRoZSBzZXNzaW9u IGtleT8NCj4+IA0KPj4gU0Q+IER1cmluZyBub3JtYWwgVExTIG5lZ290aWF0aW9uLg0KPj4gDQo+ PiAtIE9yLCBpZiBteSBhYm92ZSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nIGFuZCBtdXR1YWwgYXV0 aGVudGljYXRpb24gaXMgDQo+PiBpbmRlZWQgZG9uZSBpbiBUTFMgbGF5ZXIsIHdoeSBkb2VzIGl0 IG5lZWQgdG8gaGF2ZSBhZGRpdGlvbmFsICJIVFRQIA0KPj4gZGlnZXN0IGF1dGgiIGluIFBBV1Mg bGF5ZXI/DQo+PiANCj4+IFNEPiBPbmx5IGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBkb25lIGF0 IHRoZSBQQVdTIGxheWVyLiBPZiBjb3Vyc2UgDQo+PiBTRD4gY2xpZW50DQo+PiBhdXRoIGNhbiBi ZSBkb25lIGF0IHRoZSBUTFMgbGF5ZXIuIFRoZW4gb25lIG5lZWRzIHRvIGhhdmUgY2hhbm5lbCAN Cj4+IGJpbmRpbmcgYW5kIHRoYXQncyBhbm90aGVyIGFwcHJvYWNoLg0KPj4gDQo+PiAtICJIVFRQ IGRpZ2VzdCBhdXRoIiBvbmx5IHByb3ZpZGVzIGEgaGFzaC1iYXNlZCBwcm90ZWN0aW9uIGZvciAN Cj4+IHNlY3JldHMgbGlrZSBwYXNzd29yZCBhbmQgSUQsIGFuZCBpcyBrbm93biB0byBiZSB2dWxu ZXJhYmxlIHRvIE1pdE0NCj4+IChNYW4taW4tdGhlLU1pZGRsZSkgYXR0YWNrcy4gU2luY2UgYWNj b3JkaW5nIHRvIHRoZSBQQVdTIFdHIGRvY3VtZW50LCANCj4+IGRyYWZ0LWlldGYtcGF3cy1wcm9i bGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMtMDYsIENoYXB0ZXIgOCwgdGhyZWF0IDcsIA0KPj4gTWl0 TSBhdHRhY2sgc2hvdWxkIGJlIHRod2FydGVkLiBUaGlzIGRyYWZ0IHVzaW5nICJIVFRQIGRpZ2Vz dCBhdXRoIg0KPj4gb2J2aW91c2x5IGRvZXMgbm90IHNhdGlzZnkgdGhlIHNlY3VyaXR5IHJlcXVp cmVtZW50Lg0KPj4gDQo+PiBTRD4gIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhpcy4gSFRUUC9UTFMg aXMgdXNlZCBpbiBvdXIgc2NoZW1lLg0KPj4gDQo+PiAtICJIVFRQIGRpZ2VzdCBhdXRoIiBkaWZm ZXJzIGZyb20gSFRUUCBvdmVyIFRMUywgd2hlcmUgdGhlIGZvcm1lciANCj4+IHByb3ZpZGVzIG5v IGVuY3J5cHRpb24gZm9yIGNvbnRlbnQsIGJ1dCB0aGUgbGF0dGVyIGNhbiBlbmNyeXB0IHRoZSAN Cj4+IGNvbnRlbnQgYnkgUHVibGljIEtleSBjcnlwdG8uIFRodXMgVExTIGlzIHByZWZlcnJlZC4g LSAiSFRUUCBkaWdlc3QgDQo+PiBhdXRoIiBkb2VzIG5vdCBzdXBwb3J0IEhNQUMgYWxnb3JpdGht IChzby1jYWxsZWQgS2V5ZWQgSGFzaCksIHRodXMgaXQgDQo+PiBpcyB5ZXQgYSBsaXR0bGUgcmlz a3kgdG8gdXNlIFNIQS0xIHRvIHJlcGxhY2UgY3VycmVudCBNRDUgYWxnb3JpdGhtLCANCj4+IGJl Y2F1c2UgTklTVCBoYXMgbm90IHJlY29tbWVuZGVkIHRvIHVzZSB0aGUgY29sbGlzaW9uIHJlc2lz dGFuY2Ugb2YNCj4+IFNIQS0xIChidXQgSE1BQy1TSEExIGlzIGZpbmUpLiBJbiBjb250cmFzdCwg VExTIHN1cHBvcnRzIEhNQUMgYW5kIA0KPj4gZG9lcyBub3QgaGF2ZSBzdWNoIGEgcHJvYmxlbS4N Cj4+IA0KPj4gU0Q+IFllcyBpdCBzaG91bGQgYmUgSE1BQy1TSEExLg0KPj4gDQo+PiBGcm9tIHRo ZSBhYm92ZSBhbmFseXNpcywgaXQgaXMgY2xlYXIgdG8gc2VlIHRoYXQgdGhlIHNlY3VyaXR5IGFu ZCANCj4+IHByaXZhY3kgb2YgUEFXUyBpcyBub3Qgc3RyYWlnaHRmb3J3YXJkIGFuZCBuZWVkcyB0 byBiZSBjYXJlZnVsbHkgDQo+PiBpbnZlc3RpZ2F0ZWQsIGZvciBkZXNpZ24gYW5kIGltcGxlbWVu dGF0aW9uLg0KPj4gSXQgaXMgYWxzbyB0aGUgcmVhc29uIHdoeSB3ZSBoYXZlIHN1Ym1pdHRlZCBh biBpbmRlcGVuZGVudCBkcmFmdCBmb3IgDQo+PiBQQVdTIHNlY3VyaXR5LCB0byBwcm92aWRlIGEg YmFzZSBmb3IgZGlzY3Vzc2lvbi4NCj4+IA0KPj4gQlIsDQo+PiBZYW5nDQo+PiA9PT09PT09PT09 PT09PT09PT0NCj4+ICBZYW5nIEN1aSwgIFBoLkQuDQo+PiAgSHVhd2VpIFRlY2hub2xvZ2llcw0K Pj4gIGN1aXlhbmdAaHVhd2VpLmNvbQ0KPj4gDQo+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+Pj4g t6K8/sjLOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5v cmddILT6se0NCj4+PiBHYWJvci5CYWprb0Bub2tpYS5jb20NCj4+PiC3osvNyrG85DogMjAxMsTq N9TCMjLI1SA3OjMxDQo+Pj4gytW8/sjLOiBwYXdzQGlldGYub3JnDQo+Pj4g1vfM4jogW3Bhd3Nd IGNvbW1lbnRzIG9uIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPj4+IA0KPj4+IEl0 IHdvdWxkIGJlIGJlbmVmaWNpYWwgaWYgdGhlcmUgd2VyZSBkaXNjdXNzaW9ucyBvbiB0aGUgZHJh ZnRzIHRvIA0KPj4+IHN1Ym1pdHRlZCBhaGVhZCBvZiB0aGUgRjJGIHByZXNlbnRhdGlvbnMuDQo+ Pj4gVGh1cywgSSd2ZSB0YWtlbiB0aGUgaW5pdGlhdGl2ZSB0byByZWFkIHRoZSBkcmFmdCBhbmQg cHJvdmlkZSBzb21lIA0KPj4+IGluaXRpYWwNCj4+PiBjb21tZW50czoNCj4+PiANCj4+PiAxLiBJ IGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoZSBpbml0aWFsaXphdGlvbiBwcm9j ZXNzIGFuZCANCj4+PiB3aHkgbWVzc2FnZXMgSU5ULVJFUSBhbmQgSU5ULVJFU1AgYXJlIG5lY2Vz c2FyeS4gVGhlIGNhcGFiaWxpdHkgDQo+Pj4gZXhjaGFuZ2UgY2FuIGJlIGRvbmUgZHVyaW5nIHRo ZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4gV2UgbWF5IGV2ZW4gDQo+Pj4gY29uc2lkZXIgbWVyZ2lu ZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgd2l0aCB0aGUgREIgcXVlcnkgcHJvY2VzcywgDQo+ Pj4gdGhlcmUgZG9lc24ndCBzZWVtIHRvIGJlIGFueSByZWFzb24gdG8gaGF2ZSB0aGVtIGFzIHNl cGFyYXRlIG1lc3NhZ2VzLg0KPj4+IA0KPj4+IDIuIHlvdSBtYXkgbmVlZCBhIHNlY3Rpb24gd2hl cmUgeW91IG1hcCB5b3VyIG5ld2x5IGRlZmluZWQgbWVzc2FnZXMgDQo+Pj4gdG8gZXhpc3Rpbmcg aHR0cCBwcm90b2NvbCBtZXNzYWdlcy4gSSBzYXcgdGhhdCB5b3UgaGF2ZSBhbiBleGFtcGxlIA0K Pj4+IHNlY3Rpb24sIGJ1dCBhIG5vcm1hdGl2ZSBzZWN0aW9uIHdvdWxkIGJlIG1vcmUgZGVzaXJh YmxlLg0KPj4+IA0KPj4+IDMuIHRoZSBkYXRhIG1vZGVsIHBhcnQgbmVlZHMgc29tZSBtb3JlIHdv cmsuIFRoZSBzdHJ1Y3R1cmUgaXMgbm90IA0KPj4+IHZlcnkgY2xlYXIgdG8gbWUsIGFuZCBzb21l IG9mIHRoZSBhdHRyaWJ1dGVzIHJlZmVyZW5jZSBvYnNvbGV0ZSBSRkMuIA0KPj4+IEVnLA0KPj4+ IFJGQzM4MjUgaXMgcmVmZXJlbmNlZCBmb3IgdGhlIGxvbmdpdHVkZS9sYXRpdHVkZSBhdHRyaWJ1 dGVzLiBJIHRoaW5rIA0KPj4+IHlvdSBzaG91bGQgYmUgYmV0dGVyIG9mIHVzaW5nIGFuIGVsZW1l bnQgZm9yIGdlby1sb2NhdGlvbiwgd2l0aCB0aGUgDQo+Pj4gc3RydWN0dXJlIGFzIGRlZmluZWQg aW4gUkZDNTQ5MSwgYSBzZXBhcmF0ZSBlbGVtZW50IGZvciB0aGUgY2l2aWMgDQo+Pj4gbG9jYXRp b24sIHdpdGggdGhlIHN0cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJGQzUxMzksIGV0Yy4gSW5zdGVh ZCBvZiANCj4+PiB0aGUgRGV2aWNlT3duZXIgb2JqZWN0LCBJIHdvdWxkIHVzZSBhIHZDYXJkIGVs ZW1lbnQsIHdpdGggdGhlIA0KPj4+IHN0cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJGQzI0MjYuIFlv dSBtYXkgYWxzbyBuZWVkIGFuIGlDYWxlbmRhciANCj4+PiBlbGVtZW50IChSRkM1NTQ1KSB0byBz cGVjaWZ5IHRoZSBjaGFubmVsIGF2YWlsYWJpbGl0eSB0aW1lIChlZywgd2hlbiANCj4+PiB0aGUg Y2hhbm5lbCBpcyBub3QgYXZhaWxhYmxlIGZvciB0aGUgZnVsbCAyNEgpLiBFdGMuDQo+Pj4gDQo+ Pj4gTW9yZSBjb21tZW50cyBhcmUgd2VsY29tZS4NCj4+PiAtIEdhYm9yDQo+Pj4gDQo+Pj4gDQo+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3Jn IA0KPj4+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IERh cywgU3ViaXIgU2VudDoNCj4+PiBTYXR1cmRheSwgSnVseSAxNCwgMjAxMiA3OjM2IEFNIFRvOiBw YXdzQGlldGYub3JnIFN1YmplY3Q6IFtwYXdzXSBGVzoNCj4+PiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPj4+IA0KPj4+IERlYXIg Q2hhaXJzLA0KPj4+IFdlIGhhdmUgdXBkYXRlZCBvdXIgZHJhZnQgYW5kIHdvdWxkIGxpa2UgdG8g cmVxdWVzdCBhIHNsb3QgaW4NCj4+PiBJRVRGLTg0IHRvIHByZXNlbnQgaXQuDQo+Pj4gDQo+Pj4g UmVnYXJkcywNCj4+PiBfU3ViaXINCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LSBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQo+Pj4gW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDE0LCAyMDEyIA0KPj4+IDEwOjMw IEFNIFRvOiBEYXMsIFN1YmlyIENjOiBqbWFseWFyQHRlbGNvcmRpYS5jb207IA0KPj4+IGQuam9z bHluQHNwZWN0cnVtYnJpZGdlLmNvbSBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yDQo+Pj4gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtIDAyLnR4dA0KPj4+IA0KPj4+IA0KPj4+ IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQgaGFz IGJlZW4gDQo+Pj4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdWJpciBEYXMgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPj4+IA0KPj4+IEZpbGVuYW1lOgkgZHJhZnQtZGFz LXBhd3MtcHJvdG9jb2wgUmV2aXNpb246CSAwMiBUaXRsZToJCSBEZXZpY2UgdG8NCj4+PiBEYXRh YmFzZSBQcm90b2NvbCBmb3IgV2hpdGUgU3BhY2UgQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTQg V0cgSUQ6CQkNCj4+PiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24gTnVtYmVyIG9mIHBhZ2VzOiAzMiBV Ukw6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGFzLXBh d3MtcHJvdG9jb2wtMDIudHh0DQo+Pj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRhcy1wYXdzLQ0KPj4+IHByb3RvY29sIEh0bWxpemVkOiAg ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFzLXBhd3MtDQo+Pj4gcHJv dG9jb2wtMDIgRGlmZjoNCj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyDQo+Pj4gDQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGBQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3BhY2UN Cj4+PiAgICBkYXRhYmFzZSAoUEFXUyknIHRoYXQgdXNlcyBIVFRQL1RMUyBhcyB0cmFuc3BvcnQu ICBUaGUgcHJvdG9jb2wgaXMNCj4+PiAgICB1c2VkIGZvciByZXRyaWV2aW5nIHRoZSBuZWNlc3Nh cnkgVFYgd2hpdGUgc3BhY2UgaW5mb3JtYXRpb24gKGUuZy4sDQo+Pj4gICAgY2hhbm5lbCwgZnJl cXVlbmN5LCB0cmFuc21pdHRlZCBwb3dlcikgYXQgYSBnaXZlbiBsb2NhdGlvbiBhbmQgdGltZQ0K Pj4+ICAgIGZyb20gYSBkYXRhYmFzZSB0aGF0IGlzIG9wZXJhdGluZyB1bmRlciBhIHJlZ3VsYXRv cnkgZG9tYWluLiAgVGhlDQo+Pj4gICAgZG9jdW1lbnQgaW5jbHVkZXMgdGhlIHByb3RvY29sIGZ1 bmN0aW9uYWxpdGllcywgaXRzIGVsZW1lbnRzLA0KPj4+ICAgIGNvcnJlc3BvbmRpbmcgZGF0YSBt b2RlbCBhbmQgcmVjb21tZW5kcyBpdHMgZW5jb2Rpbmcgc2NoZW1lLg0KPj4+IA0KPj4+IA0KPj4+ IA0KPj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+IHBhd3NA aWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MN Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IHBhd3MgbWFpbGluZyBsaXN0DQo+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBwYXdzQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBt YWlsaW5nIGxpc3QNCj4gcGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MNCg0KDQoNCg== From lei.zhu@huawei.com Thu Jul 26 03:15:44 2012 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 D8C8621F86C2 for ; Thu, 26 Jul 2012 03:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 NljAwioxW-Jg for ; Thu, 26 Jul 2012 03:15:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E9FFF21F864F for ; Thu, 26 Jul 2012 03:15:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIJ00752; Thu, 26 Jul 2012 06:15:42 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jul 2012 03:13:22 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jul 2012 03:13:27 -0700 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.92]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Thu, 26 Jul 2012 18:13:13 +0800 From: Zhulei To: "Das, Subir" , Peter McCann , Cuiyang , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQAB/KozAAGpqGMABA6hCAABVA+6AACenf8A== Date: Thu, 26 Jul 2012 10:13:12 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE6252495FDE4@szxeml504-mbs.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DD31@SZXEML508-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E18FC3@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 10:15:45 -0000 RGlzYWdyZWUgdGhhdCB0aGUgcGF3cyBpcyB0byBjb21wYXJlIFNlc3Npb24gSW5pdGlhdGlvbiBQ cm90b2NvbCB3aGljaCBpcyBxdWl0ZSBzaW1pbGFyIHRvIEhUVFAuIEl0IGlzIGdvaW5nIHRvIFRM UyBzZWN1cml0eSwgYnV0IGEgcGF3cyBkaWdlc3QgYXV0aGVudGljYXRpb24uIEl0IGV2ZW4gZG9l cyBub3QgYXV0aGVudGljYXRpb24gaW4gSFRUUCBsYXllci4gDQoNClRoZSBkaWdlc3QgYXV0aGVu dGljYXRpb24gaXMgbm90IHN1ZmZpY2llbnQgZWl0aGVyIGluIHBhd3MgZGF0YSBtb2RlbCBvciBo dHRwIG1lc3NhZ2UgYm9keSwgYW5kLCBJIGRvdWJ0IHRoaXMgdXNlIHRoYXQgbWlnaHQgbWl4IGxh eWVyZWQgZnVuY3Rpb25zLg0KDQpJIGRpc2FncmVlZCB0aGUgdXNhZ2Ugb2YgUE9TVCBtZXRob2Qg Zm9yIGJpZGlyZWN0aW9uYWwgYmV0d2VlbiBwYXdzIG1hc3RlciBkZXZpY2UgYW5kIERCIGFuZCBk dXBsaWNhdGUgaW5mb3JtYXRpb24gaW4gSU5JVF9SRVNQIG1lc3NhZ2UgdG8gcmVnaXN0cmF0aW9u LiBUaGUgc2Vjb25kIG9uZSBpcyBxdWl0ZSByZWxldmFudCB0byB0aGUgc2VjdXJpdHkgbW9kZWwg b2YgcGF3cyB3aGljaCBpcyBhc3N1bWVkIHRvIGJlIGRpc2N1c3NlZCBpbiBtZWV0aW5nIGFuZCBp cyBhIHNlcGFyYXRlZCBhcnJhbmdlbWVudCBhY2NvcmRpbmcgdG8gbXkgdW5kZXJzdGFuZGluZy4N Cg0KQmVzdCByZWdhcmRzLA0KWmh1IExlaQ0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL OiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gRGFzLCBTdWJpcg0Kt6LLzcqxvOQ6IDIwMTLE6jfUwjI2yNUgMTM6MjYNCsrVvP7IyzogUGV0 ZXIgTWNDYW5uOyBDdWl5YW5nOyBHYWJvci5CYWprb0Bub2tpYS5jb207IHBhd3NAaWV0Zi5vcmcN Ctb3zOI6IFJlOiBbcGF3c10gY29tbWVudHMgb24gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIu dHh0DQoNCkFuc3dlcnMgaW5saW5lLiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFBldGVyIE1jQ2FubiBbbWFpbHRvOlBldGVyLk1jQ2FubkBodWF3ZWkuY29tXSANClNlbnQ6 IFdlZG5lc2RheSwgSnVseSAyNSwgMjAxMiAzOjA0IFBNDQpUbzogQ3VpeWFuZzsgRGFzLCBTdWJp cjsgR2Fib3IuQmFqa29Abm9raWEuY29tOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBSRTogY29t bWVudHMgb24gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQoNCkl0IGFsc28gYXBwZWFy cyB0aGF0IGRyYWZ0LWRhcyByZS1pbXBsZW1lbnRzIEhUVFAgRGlnZXN0IGF0IHRoZSBhcHBsaWNh dGlvbiBsYXllciwgcmF0aGVyIHRoYW4gYXR0ZW1wdGluZyB0byB1c2Ugc3RhbmRhcmQgSFRUUCBE aWdlc3QuIEkgYW0gY3VyaW91cyBhcyB0byB3aHkgeW91IG1hZGUgdGhpcyBjaG9pY2UuICANCg0K U0Q+ICBUaGlzIGlzIG5vdCBuZXcuIE90aGVyIElFVEYgcHJvdG9jb2xzIGhhdmUgdXNlZCB0aGlz LCBmb3IgZXhhbXBsZSwgUkZDIDMyNjENCg0KSXMgaXQgc28gdGhhdCB5b3UgY2FuIHVwZ3JhZGUg dGhlIGhhc2ggZnVuY3Rpb24gZnJvbSBNRDUgdG8gU0hBLTE/DQoNClNEPiBJRVRGIGRvZXMgbm90 IHJlY29tbWVuZCAgdXNpbmcgTUQ1IGFueW1vcmUuIA0KDQpBbHNvLCB5b3UgZG9uJ3Qgc2hvdyB0 aGUgbWVzc2FnZXMgdGhhdCByZWxheSB0aGUgbm9uY2UgdmFsdWUgZnJvbSB0aGUgc2VydmVyIHRv IHRoZSBjbGllbnQuICBJIHRoaW5rIHlvdSB3aWxsIG5lZWQgdG8gc3BlY2lmeSB0aGF0IG1lc3Nh Z2UgYXMgd2VsbC4gIEhUVFAgZG9lcyB0aGlzIHdpdGggYSA0MDEgVW5hdXRob3JpemVkIHJlc3Bv bnNlLg0KDQpTRD4gVGhpcyBpcyBkb25lIHZpYSBpbml0aWFsaXphdGlvbiByZXNwb25zZSBtZXNz YWdlLCBJTklUX1JFU1AuICBSZW1lbWJlciBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgcGVyZm9y bWVkIGR1cmluZyBpbml0aWFsaXphdGlvbiBzdGFnZS4gV2Ugc2hvdWxkIGhhdmUgaW5jbHVkZWQg dGhlIGRldGFpbHMgb2YgSU5JVF9SRVEgYW5kIElOSVRfUkVTUCBtZXNzYWdlcyBpbiBleGFtcGxl IHNlY3Rpb24uIFdpbGwgaW5jbHVkZSB0aGlzIGluIG5leHQgdmVyc2lvbi4NCg0KSXQgYWxzbyBs b29rcyBsaWtlIHlvdSBhcmUgbm90IHNlbmRpbmcgYW55IHJlc3BvbnNlcyBhdCBhbGwgaW4geW91 ciBleGFtcGxlcywganVzdCB1c2luZyBQT1NUIGluIGJvdGggZGlyZWN0aW9ucy4gIFRoaXMgc2Vl bXMgc3RyYW5nZS4NCg0KU0Q+ICBUaGUgZGF0YWJhc2UgcmVzcG9uZHMgdG8gYWxsIHJlcXVlc3Rz LiBJbiBvdXIgZXhhbXBsZSwgIHdlIGN1cnJlbnRseSBzaG93IFBBV1MgcHJvdG9jb2wgbWVzc2Fn ZSAgZGV0YWlscyB0aGF0IGFyZSBpbmNsdWRlZCBpbiB0aGUgYm9keSBvZiB0aGUgSFRUUCBQT1NU Lg0KDQoNCkl0IG1pZ2h0IGJlIGJldHRlciB0byByZWx5IG9uIGNsaWVudCBjZXJ0aWZpY2F0ZXMg YXQgdGhlIFRMUyBsYXllciB0byBhdXRoZW50aWNhdGUgdGhlIG1hc3RlciBkZXZpY2UuDQoNClNE PiBXZSBkbyBub3QgYXNzdW1lIHRoYXQgdGhlIGNsaWVudCBoYXMgY2VydC4gT3VyIGV4cGVyaWVu Y2Ugd2l0aCBXU0QgbWFudWZhY3R1cmVzIGlzIHRoYXQgdGhleSBwcmVmZXIgdGhlIG1vZGVsIG9m IGEgc2hhcmVkIHNlY3JldCBmb3IgTWFzdGVyIFdTRCBhdXRoZW50aWNhdGlvbiB0byBtYW5hZ2Ug Y29zdHMuDQoNCkZvciBhdXRoZW50aWNhdGluZyB0aGUgc2xhdmUgZGV2aWNlcywgd2UgbWlnaHQg bmVlZCBzb21ldGhpbmcgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLiAgVGhhdCBpcyBhIHNlcGFy YXRlIGRpc2N1c3Npb24gdGhhdCBzdGlsbCBuZWVkcyB0byBoYXBwZW4gKG5laXRoZXIgZHJhZnQg cmlnaHQgbm93IGRlYWxzIHdpdGggYXV0aGVudGljYXRpbmcgdGhlIHNsYXZlIGRldmljZSBpZGVu dGlmaWVycykuDQoNClNEPiBPdXIgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGF1dGhlbnRpY2F0aW5n IHRoZSBzbGF2ZSBkZXZpY2VzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFBBV1MuIFRoZXJlIGlz IG5vIGRpcmVjdCBjb21tdW5pY2F0aW9uIGJldHdlZW4gc2xhdmUgZGV2aWNlcyBhbmQgdGhlIGRh dGFiYXNlLiBIb3dldmVyLCB3ZSBkbyBzdXBwb3J0IHRoZSBjYXBhYmlsaXR5IG9mIHZhbGlkYXRp bmcgdGhlIHNsYXZlIGRldmljZXMgdmlhIE1TRC4gDQoNCi1QZXRlDQoNCg0KQ3VpeWFuZyB3cm90 ZTogDQo+IFRoYW5rcyBmb3IgeW91ciBhbnN3ZXJzLg0KPiANCj4gQnV0IHRoZW4gSSByZWFsaXpl ZCB0aGF0IHRoZSBwcm9wb3NhbCBpcyB1c2luZyBhIGtpbmQgb2YgdHdvLWxheWVyIA0KPiBhdXRo ZW50aWNhdGlvbiBwcm90b2NvbHMsIHMudC4gYW4gb3V0ZXIgbGF5ZXIgcHJvdG9jb2wgb2YgVExT IA0KPiBhdXRoZW50aWNhdGlvbiBvZiBzZXJ2ZXIgKGRhdGFiYXNlKSwgYW5kIGFuIGlubmVyIGxh eWVyIHByb3RvY29sIA0KPiBhdXRoZW50aWNhdGlvbiBvZiBjbGllbnQgKE1hc3RlciBkZXZpY2Up Lg0KPiBVbmZvcnR1bmF0ZWx5LCBpdCBpcyBrbm93biB0aGF0IHN1Y2ggYSBtaXhlZCBtb2RlIG9m IGF1dGhlbnRpY2F0aW9uIGlzIA0KPiB2dWxuZXJhYmxlIHRvIE1pdE0uDQo+IEkgYW0gc2VyaW91 c2x5IGNvbmNlcm5lZCB0aGF0IHRoaXMgZHJhZnQgaXMgYWxzbyBpbiB0aGUgY2FzZS4NCj4gDQo+ IEluIHBhcnRpY3VsYXIsIHN1Y2ggYSBjb21iaW5hdGlvbiBvZiBUTFMgb2Ygc2VydmVyIGF1dGhl bnRpY2F0aW9uIGFuZCANCj4gSFRUUCBkaWdlc3QgYXV0aGVudGljYXRpb24gb2YgY2xpZW50LCBp cyByYWlzZWQgYXMgYW4gaW5zZWN1cmUgZXhhbXBsZSANCj4gaW4gc2V2ZXJhbCBwbGFjZXMsIGlu Y2x1ZGluZzoNCj4gLSBSRkMgNDE2OQ0KPiAtIEFzb2thbi1OaWVtaS1OeWJlcmcgYXR0YWNrIDIw MDIsIGh0dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAwMi8xNjMucGRmDQo+IA0KPiBRdW90ZWQgZnJv bSBSRkMgNDE2OSwgU2VjIDQuMywgTWFuLWluLXRoZS1NaWRkbGUgQXR0YWNrLA0KPiAJIiBGb3Ig ZXhhbXBsZSwgdGhlIHVzZSBvZiBUTFMgd2l0aCBIVFRQIERpZ2VzdCBhdXRoZW50aWNhdGlvbiAo aS5lLiwNCj4gICAgVExTIGZvciBzZXJ2ZXIgYXV0aGVudGljYXRpb24sIGFuZCBzdWJzZXF1ZW50 IHVzZSBvZiBIVFRQIERpZ2VzdCBmb3INCj4gICAgY2xpZW50IGF1dGhlbnRpY2F0aW9uKSBpcyBh biBpbnN0YW5jZSBvZiBzdWNoIHNjZW5hcmlvLiAgSFRUUA0KPiAgICBjaGFsbGVuZ2VzIGFuZCBy ZXNwb25zZXMgY2FuIGJlIGZldGNoZWQgZnJvbSBhbmQgdG8gZGlmZmVyZW50IFRMUw0KPiAgICB0 dW5uZWxzIHdpdGhvdXQgbm90aWNpbmcgdGhlaXIgb3JpZ2luLiINCj4gQWx0aG91Z2ggdGhlIGFi b3ZlIGF0dGFjayBuZWVkcyBzb21lIGNvbmRpdGlvbnMsIHN1Y2ggYSB1c2Ugb2YgVExTIGFuZCAN Cj4gSFRUUCBkaWdlc3QgZG9lcyBsZWFkIHRoZSBwcm9wb3NlZCBwcm90b2NvbCB0byBhIGRhbmdl cm91cyBzaXR1YXRpb24uDQo+IEl0IGlzIG1haW5seSBiZWNhdXNlLCAoZGV0YWlscyBjb3VsZCBi ZSBmb3VuZCBpbiBBc29rYW4gZXQgYWwncyBwYXBlcikNCj4gLSBIVFRQIGRpZ2VzdCBhdXRoZW50 aWNhdGlvbiBwcm90b2NvbCBpcyB0b28gd2Vhay4gSXQgb25seSBoYXMgYSANCj4gY3J5cHRvZ3Jh cGhpYyBoYXNoIGZ1bmN0aW9uIHRvIHJ1biBhIG9uZS13YXkgY29tcHV0YXRpb24gb2YgdGhlIA0K PiBwYXNzd29yZCwgbGFjayBvZiBzZWNyZXQga2V5IGJhc2VkIG9yIHB1YmxpYyBrZXkgYmFzZWQg cHJvdGVjdGlvbiwgDQo+IHVubGlrZSBUTFMuDQo+IC0gVGhlIHNlc3Npb24ga2V5IGlzIG5lZ290 aWF0ZWQgaW4gb3V0ZXIgVExTIHByb3RvY29sIHNvbGVseS4NCj4gLSBUaGUgaW5uZXIgcHJvdG9j b2wgSFRUUCBkaWdlc3QgYXV0aCBkb2VzIG5vdCByZWFsaXplIHRoZSBleGlzdGVuY2UgDQo+IG9m IG91dGVyIFRMUyBwcm90b2NvbC4NCj4gDQo+IEEgcG9zc2libGUgc29sdXRpb24gdG8gdGhpcyBw cm9ibGVtIG1pZ2h0IGJlIHRvIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgDQo+IHRoZSBpbm5lciBh bmQgb3V0ZXIgcHJvdG9jb2wsIGZvciBleGFtcGxlLCB0byBnZW5lcmF0ZSBhIHNlc3Npb24ga2V5 IA0KPiBmb3IgaW5uZXIgcHJvdG9jb2wuDQo+IEhvd2V2ZXIsIEhUVFAgZGlnZXN0IGRvZXMgbm90 IHVzZSBub3IgZ2VuZXJhdGUgc2Vzc2lvbiBrZXkuLi4NCj4gQWdhaW4sIElNSE8sIGl0IHNlZW1z IG5vdCBhIGdvb2QgaWRlYSB0byB1c2UgSFRUUCBkaWdlc3QgYXV0aCBwcm90b2NvbCANCj4gZm9y IGNsaWVudCBhdXRoZW50aWNhdGlvbi4gU29tZSBvdGhlciBjYW5kaWRhdGVzIG5lZWQgdG8gYmUg Y29uc2lkZXJlZC4NCj4gDQo+IEFuZCBhZ2FpbiwgSSBmZWVsIHRoYXQgaXQgaXMgbmVjZXNzYXJ5 IHRvIHNldCB1cCBhbiBpbmRlcGVuZGVudCBkcmFmdCANCj4gdGFraW5nIGNhcmUgb2YgUEFXUyBz ZWN1cml0eSwgd2hpY2ggbWF5IGhlbHAgZGVzaWduIGFuZCBpbXBsZW1lbnQgdGhlIA0KPiBQQVdT IHByb3RvY29sLg0KPiBIb3BlIHRoYXQgb3VyIGRyYWZ0LCBkcmFmdC13dS1wYXdzLXNlY3V0aXR5 LTAwLCBjb3VsZCBiZSBhIHN0YXJ0aW5nIA0KPiBwb2ludC4gQW55IGNvbW1lbnQgaXMgd2VsY29t ZS4NCj4gDQo+IEJSLA0KPiBZYW5nDQo+ID09PT09PT09PT09PT09PT09PQ0KPiAgWWFuZyBDdWks ICBQaC5ELg0KPiAgSHVhd2VpIFRlY2hub2xvZ2llcw0KPiAgY3VpeWFuZ0BodWF3ZWkuY29tDQo+ IA0KPj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3orz+yMs6IERhcywgU3ViaXIgW21haWx0bzpz ZGFzQGFwcGNvbXNjaS5jb21dDQo+PiC3osvNyrG85DogMjAxMsTqN9TCMjTI1SA3OjQ2DQo+PiDK 1bz+yMs6IEN1aXlhbmc7IEdhYm9yLkJhamtvQG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZw0KPj4g 1vfM4jogUkU6IGNvbW1lbnRzIG9uIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPj4g DQo+PiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFNvbWUgYW5zd2VycyBpbmxpbmUuDQo+PiAN Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBwYXdzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCj4+IE9mIEN1 aXlhbmcNCj4+IFNlbnQ6IE1vbmRheSwgSnVseSAyMywgMjAxMiA4OjQ1IEFNDQo+PiBUbzogR2Fi b3IuQmFqa29Abm9raWEuY29tOyBwYXdzQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3Bhd3Nd IGNvbW1lbnRzIG9uIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPj4gDQo+PiBIaSBB bGwsDQo+PiANCj4+IEkgd291bGQgbGlrZSB0byBwcm92aWRlIHNvbWUgY29tbWVudHMgdG8gdGhp cyBkcmFmdCwgZnJvbSBhIHNlY3VyaXR5IA0KPj4gcG9pbnQgb2Ygdmlldy4NCj4+IEhvcGUgdGhh dCBpdCB3aWxsIGJlIGhlbHBmdWwuDQo+PiANCj4+IFRoZSBUTFMgYW5kICJIVFRQIERpZ2VzdCBB dXRoIiBoYXZlIGJlZW4gdXNlZCwgYnV0IHNlZW0gdW5jbGVhciBmb3IgbWUuDQo+PiBCZXNpZGVz LCBpdCBpcyBub3QgcmVjb21tZW5kZWQgdG8gdXNlIHRoZSBsYXR0ZXIgZm9yIHNvbWUgcmVhc29u cyANCj4+IGxpc3RlZCBiZWxvdy4gLSBJdCBpcyBzYWlkIHRoYXQgdGhlIEhUVFAvVExTIHByb3Rv Y29sIGlzIGRlcGxveWVkIGZvciANCj4+IG11dHVhbCBhdXRoZW50aWNhdGlvbi4NCj4+IA0KPj4g U0Q+IFRoaXMgaXMgbm90IGNvcnJlY3QuDQo+PiANCj4+IEhvd2V2ZXIsICJIVFRQIGRpZ2VzdCBh dXRoZW50aWNhdGlvbiIgaXMgYWN0dWFsbHkgdXNlZCBmb3IgDQo+PiBhdXRoZW50aWNhdGluZyB0 aGUgZGV2aWNlLA0KPj4gDQo+PiBTRD4gIERpZ2VzdCBBdXRoZW50aWNhdGlvbiBpcyB1c2VkIHRv IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGF0IHRoZSANCj4+IFNEPiBQQVdTDQo+PiBsYXllci4N Cj4+IA0KPj4gd2hpY2ggaXMgdHlwaWNhbGx5IHdlYWtlciB0aGFuIG5vcm1hbCBUTFMuDQo+PiAN Cj4+IFNEPiBXaHkgaXMgaXQgd2Vha2VyPw0KPj4gDQo+PiBPbmx5IHRoZSBzZXJ2ZXIgc2lkZSBh dXRoZW50aWNhdGlvbiBpcyBwZXJmb3JtZWQgYnkgVExTIA0KPj4gY2VydGlmaWNhdGUtYmFzZWQg Y3J5cHRvIG1ldGhvZC4NCj4+IC0gSXQgYXBwZWFycyB0aGF0IGF1dGhlbnRpY2F0aW9uIGlzIGRv bmUgaW4gZGlmZmVyZW50IGxheWVycywgaS5lLiwgDQo+PiBkZXZpY2UgaXMgZG9uZSBpbiBQQVdT IGxheWVyIGJ5ICJIVFRQIGRpZ2VzdCBhdXRoIiBhbmQgc2VydmVyIGlzIA0KPj4gYWNoaWV2ZWQg aW4gVExTIGxheWVyIGJ5IGNlcnRpZmljYXRlLg0KPj4gDQo+PiBTRD4gWWVzLCBhdXRoZW50aWNh dGlvbiBpcyBkb25lIGF0IHRoZSBQQVdTIGxheWVyIGJ5IHVzaW5nIGRpZ2VzdA0KPj4gYXV0aGVu dGljYXRpb24uDQo+PiANCj4+IEkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IHNlY3VyaXR5IGlzIGRv bmUgaW4gbWl4ZWQgbGF5ZXJzPw0KPj4gDQo+PiAtIEl0IGlzIHNhaWQgdGhhdCBjb25maWRlbnRp YWxpdHkgaXMgcHJvdGVjdGVkIGluIEhUVFBTIGxheWVyLCBidXQgaWYgDQo+PiBhdXRoZW50aWNh dGluZyBkZXZpY2UgaXMgYWNoaWV2ZWQgaW4gZGlmZmVyZW50IGxheWVyIChpLmUuIGluIFBBV1Mg DQo+PiBsYXllciksIGhvdyBjYW4gdGhlIGRldmljZSBhbmQgc2VydmVyIG5lZ290aWF0ZSB0aGUg c2Vzc2lvbiBrZXk/DQo+PiANCj4+IFNEPiBEdXJpbmcgbm9ybWFsIFRMUyBuZWdvdGlhdGlvbi4N Cj4+IA0KPj4gLSBPciwgaWYgbXkgYWJvdmUgdW5kZXJzdGFuZGluZyBpcyB3cm9uZyBhbmQgbXV0 dWFsIGF1dGhlbnRpY2F0aW9uIGlzIA0KPj4gaW5kZWVkIGRvbmUgaW4gVExTIGxheWVyLCB3aHkg ZG9lcyBpdCBuZWVkIHRvIGhhdmUgYWRkaXRpb25hbCAiSFRUUCANCj4+IGRpZ2VzdCBhdXRoIiBp biBQQVdTIGxheWVyPw0KPj4gDQo+PiBTRD4gT25seSBjbGllbnQgYXV0aGVudGljYXRpb24gaXMg ZG9uZSBhdCB0aGUgUEFXUyBsYXllci4gT2YgY291cnNlIA0KPj4gU0Q+IGNsaWVudA0KPj4gYXV0 aCBjYW4gYmUgZG9uZSBhdCB0aGUgVExTIGxheWVyLiBUaGVuIG9uZSBuZWVkcyB0byBoYXZlIGNo YW5uZWwgDQo+PiBiaW5kaW5nIGFuZCB0aGF0J3MgYW5vdGhlciBhcHByb2FjaC4NCj4+IA0KPj4g LSAiSFRUUCBkaWdlc3QgYXV0aCIgb25seSBwcm92aWRlcyBhIGhhc2gtYmFzZWQgcHJvdGVjdGlv biBmb3IgDQo+PiBzZWNyZXRzIGxpa2UgcGFzc3dvcmQgYW5kIElELCBhbmQgaXMga25vd24gdG8g YmUgdnVsbmVyYWJsZSB0byBNaXRNDQo+PiAoTWFuLWluLXRoZS1NaWRkbGUpIGF0dGFja3MuIFNp bmNlIGFjY29yZGluZyB0byB0aGUgUEFXUyBXRyBkb2N1bWVudCwgDQo+PiBkcmFmdC1pZXRmLXBh d3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTA2LCBDaGFwdGVyIDgsIHRocmVhdCA3LCAN Cj4+IE1pdE0gYXR0YWNrIHNob3VsZCBiZSB0aHdhcnRlZC4gVGhpcyBkcmFmdCB1c2luZyAiSFRU UCBkaWdlc3QgYXV0aCINCj4+IG9idmlvdXNseSBkb2VzIG5vdCBzYXRpc2Z5IHRoZSBzZWN1cml0 eSByZXF1aXJlbWVudC4NCj4+IA0KPj4gU0Q+ICBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoaXMuIEhU VFAvVExTIGlzIHVzZWQgaW4gb3VyIHNjaGVtZS4NCj4+IA0KPj4gLSAiSFRUUCBkaWdlc3QgYXV0 aCIgZGlmZmVycyBmcm9tIEhUVFAgb3ZlciBUTFMsIHdoZXJlIHRoZSBmb3JtZXIgDQo+PiBwcm92 aWRlcyBubyBlbmNyeXB0aW9uIGZvciBjb250ZW50LCBidXQgdGhlIGxhdHRlciBjYW4gZW5jcnlw dCB0aGUgDQo+PiBjb250ZW50IGJ5IFB1YmxpYyBLZXkgY3J5cHRvLiBUaHVzIFRMUyBpcyBwcmVm ZXJyZWQuIC0gIkhUVFAgZGlnZXN0IA0KPj4gYXV0aCIgZG9lcyBub3Qgc3VwcG9ydCBITUFDIGFs Z29yaXRobSAoc28tY2FsbGVkIEtleWVkIEhhc2gpLCB0aHVzIGl0IA0KPj4gaXMgeWV0IGEgbGl0 dGxlIHJpc2t5IHRvIHVzZSBTSEEtMSB0byByZXBsYWNlIGN1cnJlbnQgTUQ1IGFsZ29yaXRobSwg DQo+PiBiZWNhdXNlIE5JU1QgaGFzIG5vdCByZWNvbW1lbmRlZCB0byB1c2UgdGhlIGNvbGxpc2lv biByZXNpc3RhbmNlIG9mDQo+PiBTSEEtMSAoYnV0IEhNQUMtU0hBMSBpcyBmaW5lKS4gSW4gY29u dHJhc3QsIFRMUyBzdXBwb3J0cyBITUFDIGFuZCANCj4+IGRvZXMgbm90IGhhdmUgc3VjaCBhIHBy b2JsZW0uDQo+PiANCj4+IFNEPiBZZXMgaXQgc2hvdWxkIGJlIEhNQUMtU0hBMS4NCj4+IA0KPj4g RnJvbSB0aGUgYWJvdmUgYW5hbHlzaXMsIGl0IGlzIGNsZWFyIHRvIHNlZSB0aGF0IHRoZSBzZWN1 cml0eSBhbmQgDQo+PiBwcml2YWN5IG9mIFBBV1MgaXMgbm90IHN0cmFpZ2h0Zm9yd2FyZCBhbmQg bmVlZHMgdG8gYmUgY2FyZWZ1bGx5IA0KPj4gaW52ZXN0aWdhdGVkLCBmb3IgZGVzaWduIGFuZCBp bXBsZW1lbnRhdGlvbi4NCj4+IEl0IGlzIGFsc28gdGhlIHJlYXNvbiB3aHkgd2UgaGF2ZSBzdWJt aXR0ZWQgYW4gaW5kZXBlbmRlbnQgZHJhZnQgZm9yIA0KPj4gUEFXUyBzZWN1cml0eSwgdG8gcHJv dmlkZSBhIGJhc2UgZm9yIGRpc2N1c3Npb24uDQo+PiANCj4+IEJSLA0KPj4gWWFuZw0KPj4gPT09 PT09PT09PT09PT09PT09DQo+PiAgWWFuZyBDdWksICBQaC5ELg0KPj4gIEh1YXdlaSBUZWNobm9s b2dpZXMNCj4+ICBjdWl5YW5nQGh1YXdlaS5jb20NCj4+IA0KPj4+IC0tLS0t08q8/tStvP4tLS0t LQ0KPj4+ILeivP7IyzogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2Vz QGlldGYub3JnXSC0+rHtDQo+Pj4gR2Fib3IuQmFqa29Abm9raWEuY29tDQo+Pj4gt6LLzcqxvOQ6 IDIwMTLE6jfUwjIyyNUgNzozMQ0KPj4+IMrVvP7IyzogcGF3c0BpZXRmLm9yZw0KPj4+INb3zOI6 IFtwYXdzXSBjb21tZW50cyBvbiBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCj4+PiAN Cj4+PiBJdCB3b3VsZCBiZSBiZW5lZmljaWFsIGlmIHRoZXJlIHdlcmUgZGlzY3Vzc2lvbnMgb24g dGhlIGRyYWZ0cyB0byANCj4+PiBzdWJtaXR0ZWQgYWhlYWQgb2YgdGhlIEYyRiBwcmVzZW50YXRp b25zLg0KPj4+IFRodXMsIEkndmUgdGFrZW4gdGhlIGluaXRpYXRpdmUgdG8gcmVhZCB0aGUgZHJh ZnQgYW5kIHByb3ZpZGUgc29tZSANCj4+PiBpbml0aWFsDQo+Pj4gY29tbWVudHM6DQo+Pj4gDQo+ Pj4gMS4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGUgaW5pdGlhbGl6YXRp b24gcHJvY2VzcyBhbmQgDQo+Pj4gd2h5IG1lc3NhZ2VzIElOVC1SRVEgYW5kIElOVC1SRVNQIGFy ZSBuZWNlc3NhcnkuIFRoZSBjYXBhYmlsaXR5IA0KPj4+IGV4Y2hhbmdlIGNhbiBiZSBkb25lIGR1 cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuIFdlIG1heSBldmVuIA0KPj4+IGNvbnNpZGVy IG1lcmdpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIHdpdGggdGhlIERCIHF1ZXJ5IHByb2Nl c3MsIA0KPj4+IHRoZXJlIGRvZXNuJ3Qgc2VlbSB0byBiZSBhbnkgcmVhc29uIHRvIGhhdmUgdGhl bSBhcyBzZXBhcmF0ZSBtZXNzYWdlcy4NCj4+PiANCj4+PiAyLiB5b3UgbWF5IG5lZWQgYSBzZWN0 aW9uIHdoZXJlIHlvdSBtYXAgeW91ciBuZXdseSBkZWZpbmVkIG1lc3NhZ2VzIA0KPj4+IHRvIGV4 aXN0aW5nIGh0dHAgcHJvdG9jb2wgbWVzc2FnZXMuIEkgc2F3IHRoYXQgeW91IGhhdmUgYW4gZXhh bXBsZSANCj4+PiBzZWN0aW9uLCBidXQgYSBub3JtYXRpdmUgc2VjdGlvbiB3b3VsZCBiZSBtb3Jl IGRlc2lyYWJsZS4NCj4+PiANCj4+PiAzLiB0aGUgZGF0YSBtb2RlbCBwYXJ0IG5lZWRzIHNvbWUg bW9yZSB3b3JrLiBUaGUgc3RydWN0dXJlIGlzIG5vdCANCj4+PiB2ZXJ5IGNsZWFyIHRvIG1lLCBh bmQgc29tZSBvZiB0aGUgYXR0cmlidXRlcyByZWZlcmVuY2Ugb2Jzb2xldGUgUkZDLiANCj4+PiBF ZywNCj4+PiBSRkMzODI1IGlzIHJlZmVyZW5jZWQgZm9yIHRoZSBsb25naXR1ZGUvbGF0aXR1ZGUg YXR0cmlidXRlcy4gSSB0aGluayANCj4+PiB5b3Ugc2hvdWxkIGJlIGJldHRlciBvZiB1c2luZyBh biBlbGVtZW50IGZvciBnZW8tbG9jYXRpb24sIHdpdGggdGhlIA0KPj4+IHN0cnVjdHVyZSBhcyBk ZWZpbmVkIGluIFJGQzU0OTEsIGEgc2VwYXJhdGUgZWxlbWVudCBmb3IgdGhlIGNpdmljIA0KPj4+ IGxvY2F0aW9uLCB3aXRoIHRoZSBzdHJ1Y3R1cmUgYXMgZGVmaW5lZCBpbiBSRkM1MTM5LCBldGMu IEluc3RlYWQgb2YgDQo+Pj4gdGhlIERldmljZU93bmVyIG9iamVjdCwgSSB3b3VsZCB1c2UgYSB2 Q2FyZCBlbGVtZW50LCB3aXRoIHRoZSANCj4+PiBzdHJ1Y3R1cmUgYXMgZGVmaW5lZCBpbiBSRkMy NDI2LiBZb3UgbWF5IGFsc28gbmVlZCBhbiBpQ2FsZW5kYXIgDQo+Pj4gZWxlbWVudCAoUkZDNTU0 NSkgdG8gc3BlY2lmeSB0aGUgY2hhbm5lbCBhdmFpbGFiaWxpdHkgdGltZSAoZWcsIHdoZW4gDQo+ Pj4gdGhlIGNoYW5uZWwgaXMgbm90IGF2YWlsYWJsZSBmb3IgdGhlIGZ1bGwgMjRIKS4gRXRjLg0K Pj4+IA0KPj4+IE1vcmUgY29tbWVudHMgYXJlIHdlbGNvbWUuDQo+Pj4gLSBHYWJvcg0KPj4+IA0K Pj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHBhd3MtYm91bmNlc0Bp ZXRmLm9yZyANCj4+PiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IGV4dCBEYXMsIFN1YmlyIFNlbnQ6DQo+Pj4gU2F0dXJkYXksIEp1bHkgMTQsIDIwMTIgNzozNiBB TSBUbzogcGF3c0BpZXRmLm9yZyBTdWJqZWN0OiBbcGF3c10gRlc6DQo+Pj4gTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCj4+PiANCj4+ PiBEZWFyIENoYWlycywNCj4+PiBXZSBoYXZlIHVwZGF0ZWQgb3VyIGRyYWZ0IGFuZCB3b3VsZCBs aWtlIHRvIHJlcXVlc3QgYSBzbG90IGluDQo+Pj4gSUVURi04NCB0byBwcmVzZW50IGl0Lg0KPj4+ IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gX1N1YmlyDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIA0KPj4+IFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSBTZW50OiBTYXR1cmRheSwgSnVseSAxNCwgMjAxMiANCj4+ PiAxMDozMCBBTSBUbzogRGFzLCBTdWJpciBDYzogam1hbHlhckB0ZWxjb3JkaWEuY29tOyANCj4+ PiBkLmpvc2x5bkBzcGVjdHJ1bWJyaWRnZS5jb20gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcg0KPj4+IGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLSAwMi50eHQNCj4+PiANCj4+ PiANCj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIu dHh0IGhhcyBiZWVuIA0KPj4+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3ViaXIgRGFzIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4+PiANCj4+PiBGaWxlbmFtZToJIGRy YWZ0LWRhcy1wYXdzLXByb3RvY29sIFJldmlzaW9uOgkgMDIgVGl0bGU6CQkgRGV2aWNlIHRvDQo+ Pj4gRGF0YWJhc2UgUHJvdG9jb2wgZm9yIFdoaXRlIFNwYWNlIENyZWF0aW9uIGRhdGU6CSAyMDEy LTA3LTE0IFdHIElEOgkJDQo+Pj4gSW5kaXZpZHVhbCBTdWJtaXNzaW9uIE51bWJlciBvZiBwYWdl czogMzIgVVJMOg0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPj4+IFN0YXR1czogICAgICAgICAgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kYXMtcGF3cy0NCj4+PiBwcm90b2NvbCBIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRhcy1wYXdzLQ0K Pj4+IHByb3RvY29sLTAyIERpZmY6DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMg0KPj4+IA0KPj4+IEFic3RyYWN0Og0KPj4+ ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBgUHJvdG9jb2wgdG8gQWNjZXNzIFdoaXRl IFNwYWNlDQo+Pj4gICAgZGF0YWJhc2UgKFBBV1MpJyB0aGF0IHVzZXMgSFRUUC9UTFMgYXMgdHJh bnNwb3J0LiAgVGhlIHByb3RvY29sIGlzDQo+Pj4gICAgdXNlZCBmb3IgcmV0cmlldmluZyB0aGUg bmVjZXNzYXJ5IFRWIHdoaXRlIHNwYWNlIGluZm9ybWF0aW9uIChlLmcuLA0KPj4+ICAgIGNoYW5u ZWwsIGZyZXF1ZW5jeSwgdHJhbnNtaXR0ZWQgcG93ZXIpIGF0IGEgZ2l2ZW4gbG9jYXRpb24gYW5k IHRpbWUNCj4+PiAgICBmcm9tIGEgZGF0YWJhc2UgdGhhdCBpcyBvcGVyYXRpbmcgdW5kZXIgYSBy ZWd1bGF0b3J5IGRvbWFpbi4gIFRoZQ0KPj4+ICAgIGRvY3VtZW50IGluY2x1ZGVzIHRoZSBwcm90 b2NvbCBmdW5jdGlvbmFsaXRpZXMsIGl0cyBlbGVtZW50cywNCj4+PiAgICBjb3JyZXNwb25kaW5n IGRhdGEgbW9kZWwgYW5kIHJlY29tbWVuZHMgaXRzIGVuY29kaW5nIHNjaGVtZS4NCj4+PiANCj4+ PiANCj4+PiANCj4+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+ PiBwYXdzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wYXdzDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+IHBhd3NAaWV0Zi5vcmcNCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4g cGF3c0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHBhd3MgbWFpbGluZyBsaXN0DQo+IHBhd3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K From Peter.McCann@huawei.com Thu Jul 26 08:18:33 2012 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 5339421F86B6 for ; Thu, 26 Jul 2012 08:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=-1.514, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 WC1s+AdwTdRt for ; Thu, 26 Jul 2012 08:18:31 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8F80721F8622 for ; Thu, 26 Jul 2012 08:18:31 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIJ18639; Thu, 26 Jul 2012 11:18:31 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jul 2012 08:16:51 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.75]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 26 Jul 2012 08:16:43 -0700 From: Peter McCann To: "Das, Subir" , Cuiyang , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQAB/KozAAGpqGMABA6hCAABVA+6AAFKb7wA== Date: Thu, 26 Jul 2012 15:16:42 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E1921B@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DD31@SZXEML508-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E18FC3@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.152] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 15:18:33 -0000 SGksIFN1YmlyLA0KDQpEYXMsIFN1YmlyIHdyb3RlOg0KPiBBbnN3ZXJzIGlubGluZS4NCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBldGVyIE1jQ2FubiBbbWFpbHRv OlBldGVyLk1jQ2FubkBodWF3ZWkuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjUsIDIw MTIgMzowNCBQTQ0KPiBUbzogQ3VpeWFuZzsgRGFzLCBTdWJpcjsgR2Fib3IuQmFqa29Abm9raWEu Y29tOyBwYXdzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBjb21tZW50cyBvbiBkcmFmdC1kYXMt cGF3cy1wcm90b2NvbC0wMi50eHQNCj4gDQo+IEl0IGFsc28gYXBwZWFycyB0aGF0IGRyYWZ0LWRh cyByZS1pbXBsZW1lbnRzIEhUVFAgRGlnZXN0IGF0IHRoZQ0KPiBhcHBsaWNhdGlvbiBsYXllciwg cmF0aGVyIHRoYW4gYXR0ZW1wdGluZyB0byB1c2Ugc3RhbmRhcmQgSFRUUCBEaWdlc3QuDQo+IEkg YW0gY3VyaW91cyBhcyB0byB3aHkgeW91IG1hZGUgdGhpcyBjaG9pY2UuDQo+IA0KPiBTRD4gIFRo aXMgaXMgbm90IG5ldy4gT3RoZXIgSUVURiBwcm90b2NvbHMgaGF2ZSB1c2VkIHRoaXMsIGZvciBl eGFtcGxlLA0KPiBSRkMgMzI2MQ0KDQpCdXQgMzI2MSBkb2VzIGl0IHdpdGggaGVhZGVyIGZpZWxk cyBhbmQgcmVzcG9uc2UgY29kZXMuICBXaGF0IHlvdQ0KYXJlIHByb3Bvc2luZyBpcyBsaWtlIHB1 dHRpbmcgdGhlIGNoYWxsZW5nZS9yZXNwb25zZSBpbnRvIHRoZSBTRFANCmJvZHksIHdoaWNoIGlz IG5vdCB0aGUgZGVzaWduIGNob2ljZSBtYWRlIHRoZXJlLiAgSWYgd2UgZGVjaWRlIHRvDQp1c2Ug RGlnZXN0ICh3aGljaCBpcyBhIGJpZyBpZikgSSB0aGluayBpdCBzaG91bGQgdXNlIHRoZSBIVFRQ IGhlYWRlcnMuDQoNCj4gSXMgaXQgc28gdGhhdCB5b3UgY2FuIHVwZ3JhZGUgdGhlIGhhc2ggZnVu Y3Rpb24gZnJvbSBNRDUgdG8gU0hBLTE/DQo+IA0KPiBTRD4gSUVURiBkb2VzIG5vdCByZWNvbW1l bmQgIHVzaW5nIE1ENSBhbnltb3JlLg0KDQpTdXJlLCBidXQgdGhhdCdzIG5vdCBuZWNlc3Nhcmls eSBhIHJlYXNvbiB0byByZS1pbXBsZW1lbnQgZGlnZXN0DQphdXRoZW50aWNhdGlvbiBpbiB0aGUg cGF5bG9hZC4gIFdlIGNvdWxkIGRlZmluZSBhIG5ldyAiYWxnb3JpdGhtIg0KdmFsdWUgZm9yIHRo ZSBIVFRQLWRpZ2VzdCBzY2hlbWUuDQoNCj4gQWxzbywgeW91IGRvbid0IHNob3cgdGhlIG1lc3Nh Z2VzIHRoYXQgcmVsYXkgdGhlIG5vbmNlIHZhbHVlIGZyb20gdGhlDQo+IHNlcnZlciB0byB0aGUg Y2xpZW50LiAgSSB0aGluayB5b3Ugd2lsbCBuZWVkIHRvIHNwZWNpZnkgdGhhdCBtZXNzYWdlIGFz DQo+IHdlbGwuICBIVFRQIGRvZXMgdGhpcyB3aXRoIGEgNDAxIFVuYXV0aG9yaXplZCByZXNwb25z ZS4NCj4gDQo+IFNEPiBUaGlzIGlzIGRvbmUgdmlhIGluaXRpYWxpemF0aW9uIHJlc3BvbnNlIG1l c3NhZ2UsIElOSVRfUkVTUC4NCj4gUmVtZW1iZXIgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIHBl cmZvcm1lZCBkdXJpbmcgaW5pdGlhbGl6YXRpb24NCj4gc3RhZ2UuIFdlIHNob3VsZCBoYXZlIGlu Y2x1ZGVkIHRoZSBkZXRhaWxzIG9mIElOSVRfUkVRIGFuZCBJTklUX1JFU1ANCj4gbWVzc2FnZXMg aW4gZXhhbXBsZSBzZWN0aW9uLiBXaWxsIGluY2x1ZGUgdGhpcyBpbiBuZXh0IHZlcnNpb24uDQoN Ck9rLiAgTm90ZSB0aGF0IHRoaXMgd2lsbCBpbnRyb2R1Y2UgYW4gZXh0cmEgcm91bmQtdHJpcCBk dXJpbmcgdGhlDQpxdWVyeSBwcm9jZXNzLg0KDQo+IEl0IGFsc28gbG9va3MgbGlrZSB5b3UgYXJl IG5vdCBzZW5kaW5nIGFueSByZXNwb25zZXMgYXQgYWxsIGluIHlvdXINCj4gZXhhbXBsZXMsIGp1 c3QgdXNpbmcgUE9TVCBpbiBib3RoIGRpcmVjdGlvbnMuICBUaGlzIHNlZW1zIHN0cmFuZ2UuDQo+ IA0KPiBTRD4gIFRoZSBkYXRhYmFzZSByZXNwb25kcyB0byBhbGwgcmVxdWVzdHMuIEluIG91ciBl eGFtcGxlLCAgd2UNCj4gY3VycmVudGx5IHNob3cgUEFXUyBwcm90b2NvbCBtZXNzYWdlICBkZXRh aWxzIHRoYXQgYXJlIGluY2x1ZGVkIGluIHRoZQ0KPiBib2R5IG9mIHRoZSBIVFRQIFBPU1QuDQoN CldoeSBub3QgdXNlIGFuIEhUVFAgUmVzcG9uc2UgbWVzc2FnZT8NCg0KPiBJdCBtaWdodCBiZSBi ZXR0ZXIgdG8gcmVseSBvbiBjbGllbnQgY2VydGlmaWNhdGVzIGF0IHRoZSBUTFMgbGF5ZXIgdG8N Cj4gYXV0aGVudGljYXRlIHRoZSBtYXN0ZXIgZGV2aWNlLg0KPiANCj4gU0Q+IFdlIGRvIG5vdCBh c3N1bWUgdGhhdCB0aGUgY2xpZW50IGhhcyBjZXJ0LiBPdXIgZXhwZXJpZW5jZSB3aXRoIFdTRA0K PiBtYW51ZmFjdHVyZXMgaXMgdGhhdCB0aGV5IHByZWZlciB0aGUgbW9kZWwgb2YgYSBzaGFyZWQg c2VjcmV0IGZvcg0KPiBNYXN0ZXIgV1NEIGF1dGhlbnRpY2F0aW9uIHRvIG1hbmFnZSBjb3N0cy4N Cg0KVGhlIHVzZSBvZiBhIHNoYXJlZCBzZWNyZXQgaGFzIGFkZGl0aW9uYWwgY29zdHMgYmVjYXVz ZSBrZXkgZGlzdHJpYnV0aW9uDQppcyBoYXJkZXIuICBXaGF0IGlmIHRoZSB1c2VyIHdhbnRzIHRv IGNoYW5nZSBkYXRhYmFzZSBwcm92aWRlcnM/ICBUaGlzIGlzDQptdWNoIGVhc2llciB0byBhY2Nv bXBsaXNoIHdpdGggYSBwdWJsaWMga2V5IG1lY2hhbmlzbS4NCg0KPiBGb3IgYXV0aGVudGljYXRp bmcgdGhlIHNsYXZlIGRldmljZXMsIHdlIG1pZ2h0IG5lZWQgc29tZXRoaW5nIGF0IHRoZQ0KPiBh cHBsaWNhdGlvbiBsYXllci4gIFRoYXQgaXMgYSBzZXBhcmF0ZSBkaXNjdXNzaW9uIHRoYXQgc3Rp bGwgbmVlZHMgdG8NCj4gaGFwcGVuIChuZWl0aGVyIGRyYWZ0IHJpZ2h0IG5vdyBkZWFscyB3aXRo IGF1dGhlbnRpY2F0aW5nIHRoZSBzbGF2ZQ0KPiBkZXZpY2UgaWRlbnRpZmllcnMpLg0KPiANCj4g U0Q+IE91ciB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYXV0aGVudGljYXRpbmcgdGhlIHNsYXZlIGRl dmljZXMgaXMNCj4gb3V0c2lkZSB0aGUgc2NvcGUgb2YgUEFXUy4gVGhlcmUgaXMgbm8gZGlyZWN0 IGNvbW11bmljYXRpb24gYmV0d2Vlbg0KPiBzbGF2ZSBkZXZpY2VzIGFuZCB0aGUgZGF0YWJhc2Uu IEhvd2V2ZXIsIHdlIGRvIHN1cHBvcnQgdGhlIGNhcGFiaWxpdHkNCj4gb2YgdmFsaWRhdGluZyB0 aGUgc2xhdmUgZGV2aWNlcyB2aWEgTVNELg0KDQpJIHRoaW5rIGF1dGhlbnRpY2F0aW9uIG9mIHNs YXZlIGRldmljZXMgaXMgcmVxdWlyZWQgYnkgRkNDIHJ1bGVzLCBhcw0KcHJldmlvdXMgZGlzY3Vz c2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IGhhcyBzaG93bi4NCg0KLVBldGUNCg0KPiAtUGV0ZQ0K PiANCj4gDQo+IEN1aXlhbmcgd3JvdGU6DQo+PiBUaGFua3MgZm9yIHlvdXIgYW5zd2Vycy4NCj4+ IA0KPj4gQnV0IHRoZW4gSSByZWFsaXplZCB0aGF0IHRoZSBwcm9wb3NhbCBpcyB1c2luZyBhIGtp bmQgb2YgdHdvLWxheWVyDQo+PiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbHMsIHMudC4gYW4gb3V0 ZXIgbGF5ZXIgcHJvdG9jb2wgb2YgVExTDQo+PiBhdXRoZW50aWNhdGlvbiBvZiBzZXJ2ZXIgKGRh dGFiYXNlKSwgYW5kIGFuIGlubmVyIGxheWVyIHByb3RvY29sDQo+PiBhdXRoZW50aWNhdGlvbiBv ZiBjbGllbnQgKE1hc3RlciBkZXZpY2UpLiBVbmZvcnR1bmF0ZWx5LCBpdCBpcyBrbm93bg0KPj4g dGhhdCBzdWNoIGEgbWl4ZWQgbW9kZSBvZiBhdXRoZW50aWNhdGlvbiBpcyB2dWxuZXJhYmxlIHRv IE1pdE0uIEkgYW0NCj4+IHNlcmlvdXNseSBjb25jZXJuZWQgdGhhdCB0aGlzIGRyYWZ0IGlzIGFs c28gaW4gdGhlIGNhc2UuDQo+PiANCj4+IEluIHBhcnRpY3VsYXIsIHN1Y2ggYSBjb21iaW5hdGlv biBvZiBUTFMgb2Ygc2VydmVyIGF1dGhlbnRpY2F0aW9uIGFuZA0KPj4gSFRUUCBkaWdlc3QgYXV0 aGVudGljYXRpb24gb2YgY2xpZW50LCBpcyByYWlzZWQgYXMgYW4gaW5zZWN1cmUgZXhhbXBsZQ0K Pj4gaW4gc2V2ZXJhbCBwbGFjZXMsIGluY2x1ZGluZzogLSBSRkMgNDE2OSAtIEFzb2thbi1OaWVt aS1OeWJlcmcgYXR0YWNrDQo+PiAyMDAyLCBodHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMDIvMTYz LnBkZg0KPj4gDQo+PiBRdW90ZWQgZnJvbSBSRkMgNDE2OSwgU2VjIDQuMywgTWFuLWluLXRoZS1N aWRkbGUgQXR0YWNrLA0KPj4gCSIgRm9yIGV4YW1wbGUsIHRoZSB1c2Ugb2YgVExTIHdpdGggSFRU UCBEaWdlc3QgYXV0aGVudGljYXRpb24NCj4gKGkuZS4sDQo+PiAgICBUTFMgZm9yIHNlcnZlciBh dXRoZW50aWNhdGlvbiwgYW5kIHN1YnNlcXVlbnQgdXNlIG9mIEhUVFAgRGlnZXN0IGZvcg0KPj4g ICAgY2xpZW50IGF1dGhlbnRpY2F0aW9uKSBpcyBhbiBpbnN0YW5jZSBvZiBzdWNoIHNjZW5hcmlv LiAgSFRUUA0KPj4gICAgY2hhbGxlbmdlcyBhbmQgcmVzcG9uc2VzIGNhbiBiZSBmZXRjaGVkIGZy b20gYW5kIHRvIGRpZmZlcmVudCBUTFMNCj4+ICAgIHR1bm5lbHMgd2l0aG91dCBub3RpY2luZyB0 aGVpciBvcmlnaW4uIg0KPj4gQWx0aG91Z2ggdGhlIGFib3ZlIGF0dGFjayBuZWVkcyBzb21lIGNv bmRpdGlvbnMsIHN1Y2ggYSB1c2Ugb2YgVExTIGFuZA0KPj4gSFRUUCBkaWdlc3QgZG9lcyBsZWFk IHRoZSBwcm9wb3NlZCBwcm90b2NvbCB0byBhIGRhbmdlcm91cyBzaXR1YXRpb24uDQo+PiBJdCBp cyBtYWlubHkgYmVjYXVzZSwgKGRldGFpbHMgY291bGQgYmUgZm91bmQgaW4gQXNva2FuIGV0IGFs J3MgcGFwZXIpDQo+PiAtIEhUVFAgZGlnZXN0IGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIGlzIHRv byB3ZWFrLiBJdCBvbmx5IGhhcyBhDQo+PiBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24gdG8g cnVuIGEgb25lLXdheSBjb21wdXRhdGlvbiBvZiB0aGUNCj4+IHBhc3N3b3JkLCBsYWNrIG9mIHNl Y3JldCBrZXkgYmFzZWQgb3IgcHVibGljIGtleSBiYXNlZCBwcm90ZWN0aW9uLA0KPj4gdW5saWtl IFRMUy4gLSBUaGUgc2Vzc2lvbiBrZXkgaXMgbmVnb3RpYXRlZCBpbiBvdXRlciBUTFMgcHJvdG9j b2wNCj4+IHNvbGVseS4gLSBUaGUgaW5uZXIgcHJvdG9jb2wgSFRUUCBkaWdlc3QgYXV0aCBkb2Vz IG5vdCByZWFsaXplIHRoZQ0KPj4gZXhpc3RlbmNlIG9mIG91dGVyIFRMUyBwcm90b2NvbC4NCj4+ IA0KPj4gQSBwb3NzaWJsZSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gbWlnaHQgYmUgdG8gY3J5 cHRvZ3JhcGhpY2FsbHkgYmluZA0KPj4gdGhlIGlubmVyIGFuZCBvdXRlciBwcm90b2NvbCwgZm9y IGV4YW1wbGUsIHRvIGdlbmVyYXRlIGEgc2Vzc2lvbiBrZXkNCj4+IGZvciBpbm5lciBwcm90b2Nv bC4gSG93ZXZlciwgSFRUUCBkaWdlc3QgZG9lcyBub3QgdXNlIG5vciBnZW5lcmF0ZQ0KPj4gc2Vz c2lvbiBrZXkuLi4gQWdhaW4sIElNSE8sIGl0IHNlZW1zIG5vdCBhIGdvb2QgaWRlYSB0byB1c2Ug SFRUUCBkaWdlc3QNCj4+IGF1dGggcHJvdG9jb2wgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4g U29tZSBvdGhlciBjYW5kaWRhdGVzIG5lZWQgdG8NCj4+IGJlIGNvbnNpZGVyZWQuDQo+PiANCj4+ IEFuZCBhZ2FpbiwgSSBmZWVsIHRoYXQgaXQgaXMgbmVjZXNzYXJ5IHRvIHNldCB1cCBhbiBpbmRl cGVuZGVudCBkcmFmdA0KPj4gdGFraW5nIGNhcmUgb2YgUEFXUyBzZWN1cml0eSwgd2hpY2ggbWF5 IGhlbHAgZGVzaWduIGFuZCBpbXBsZW1lbnQgdGhlDQo+PiBQQVdTIHByb3RvY29sLg0KPj4gSG9w ZSB0aGF0IG91ciBkcmFmdCwgZHJhZnQtd3UtcGF3cy1zZWN1dGl0eS0wMCwgY291bGQgYmUgYSBz dGFydGluZw0KPj4gcG9pbnQuIEFueSBjb21tZW50IGlzIHdlbGNvbWUuDQo+PiANCj4+IEJSLA0K Pj4gWWFuZw0KPj4gPT09PT09PT09PT09PT09PT09DQo+PiAgWWFuZyBDdWksICBQaC5ELg0KPj4g IEh1YXdlaSBUZWNobm9sb2dpZXMNCj4+ICBjdWl5YW5nQGh1YXdlaS5jb20NCj4+ICANCj4+PiAt LS0tLdPKvP7Urbz+LS0tLS0NCj4+PiC3orz+yMs6IERhcywgU3ViaXIgW21haWx0bzpzZGFzQGFw cGNvbXNjaS5jb21dDQo+Pj4gt6LLzcqxvOQ6IDIwMTLE6jfUwjI0yNUgNzo0Ng0KPj4+IMrVvP7I yzogQ3VpeWFuZzsgR2Fib3IuQmFqa29Abm9raWEuY29tOyBwYXdzQGlldGYub3JnDQo+Pj4g1vfM 4jogUkU6IGNvbW1lbnRzIG9uIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPj4+IA0K Pj4+IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gU29tZSBhbnN3ZXJzIGlubGluZS4NCj4+PiAN Cj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IHBhd3MtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj4gT2Yg Q3VpeWFuZw0KPj4+IFNlbnQ6IE1vbmRheSwgSnVseSAyMywgMjAxMiA4OjQ1IEFNDQo+Pj4gVG86 IEdhYm9yLkJhamtvQG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBb cGF3c10gY29tbWVudHMgb24gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+Pj4gDQo+ Pj4gSGkgQWxsLA0KPj4+IA0KPj4+IEkgd291bGQgbGlrZSB0byBwcm92aWRlIHNvbWUgY29tbWVu dHMgdG8gdGhpcyBkcmFmdCwgZnJvbSBhIHNlY3VyaXR5DQo+Pj4gcG9pbnQgb2Ygdmlldy4NCj4+ PiBIb3BlIHRoYXQgaXQgd2lsbCBiZSBoZWxwZnVsLg0KPj4+IA0KPj4+IFRoZSBUTFMgYW5kICJI VFRQIERpZ2VzdCBBdXRoIiBoYXZlIGJlZW4gdXNlZCwgYnV0IHNlZW0gdW5jbGVhciBmb3INCj4+ PiBtZS4gQmVzaWRlcywgaXQgaXMgbm90IHJlY29tbWVuZGVkIHRvIHVzZSB0aGUgbGF0dGVyIGZv ciBzb21lIHJlYXNvbnMNCj4+PiBsaXN0ZWQgYmVsb3cuIC0gSXQgaXMgc2FpZCB0aGF0IHRoZSBI VFRQL1RMUyBwcm90b2NvbCBpcyBkZXBsb3llZCBmb3INCj4+PiBtdXR1YWwgYXV0aGVudGljYXRp b24uDQo+Pj4gDQo+Pj4gU0Q+IFRoaXMgaXMgbm90IGNvcnJlY3QuDQo+Pj4gDQo+Pj4gSG93ZXZl ciwgIkhUVFAgZGlnZXN0IGF1dGhlbnRpY2F0aW9uIiBpcyBhY3R1YWxseSB1c2VkIGZvcg0KPj4+ IGF1dGhlbnRpY2F0aW5nIHRoZSBkZXZpY2UsDQo+Pj4gDQo+Pj4gU0Q+ICBEaWdlc3QgQXV0aGVu dGljYXRpb24gaXMgdXNlZCB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhdCB0aGUNCj4+PiBT RD4gUEFXUw0KPj4+IGxheWVyLg0KPj4+IA0KPj4+IHdoaWNoIGlzIHR5cGljYWxseSB3ZWFrZXIg dGhhbiBub3JtYWwgVExTLg0KPj4+IA0KPj4+IFNEPiBXaHkgaXMgaXQgd2Vha2VyPw0KPj4+IA0K Pj4+IE9ubHkgdGhlIHNlcnZlciBzaWRlIGF1dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCBieSBU TFMNCj4+PiBjZXJ0aWZpY2F0ZS1iYXNlZCBjcnlwdG8gbWV0aG9kLg0KPj4+IC0gSXQgYXBwZWFy cyB0aGF0IGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgaW4gZGlmZmVyZW50IGxheWVycywgaS5lLiwN Cj4+PiBkZXZpY2UgaXMgZG9uZSBpbiBQQVdTIGxheWVyIGJ5ICJIVFRQIGRpZ2VzdCBhdXRoIiBh bmQgc2VydmVyIGlzDQo+Pj4gYWNoaWV2ZWQgaW4gVExTIGxheWVyIGJ5IGNlcnRpZmljYXRlLg0K Pj4+IA0KPj4+IFNEPiBZZXMsIGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgYXQgdGhlIFBBV1MgbGF5 ZXIgYnkgdXNpbmcgZGlnZXN0DQo+Pj4gYXV0aGVudGljYXRpb24uDQo+Pj4gDQo+Pj4gSSBkbyBu b3QgdW5kZXJzdGFuZCB3aHkgc2VjdXJpdHkgaXMgZG9uZSBpbiBtaXhlZCBsYXllcnM/DQo+Pj4g DQo+Pj4gLSBJdCBpcyBzYWlkIHRoYXQgY29uZmlkZW50aWFsaXR5IGlzIHByb3RlY3RlZCBpbiBI VFRQUyBsYXllciwgYnV0IGlmDQo+Pj4gYXV0aGVudGljYXRpbmcgZGV2aWNlIGlzIGFjaGlldmVk IGluIGRpZmZlcmVudCBsYXllciAoaS5lLiBpbiBQQVdTDQo+Pj4gbGF5ZXIpLCBob3cgY2FuIHRo ZSBkZXZpY2UgYW5kIHNlcnZlciBuZWdvdGlhdGUgdGhlIHNlc3Npb24ga2V5Pw0KPj4+IA0KPj4+ IFNEPiBEdXJpbmcgbm9ybWFsIFRMUyBuZWdvdGlhdGlvbi4NCj4+PiANCj4+PiAtIE9yLCBpZiBt eSBhYm92ZSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nIGFuZCBtdXR1YWwgYXV0aGVudGljYXRpb24g aXMNCj4+PiBpbmRlZWQgZG9uZSBpbiBUTFMgbGF5ZXIsIHdoeSBkb2VzIGl0IG5lZWQgdG8gaGF2 ZSBhZGRpdGlvbmFsICJIVFRQDQo+Pj4gZGlnZXN0IGF1dGgiIGluIFBBV1MgbGF5ZXI/DQo+Pj4g DQo+Pj4gU0Q+IE9ubHkgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgYXQgdGhlIFBBV1Mg bGF5ZXIuIE9mIGNvdXJzZQ0KPj4+IFNEPiBjbGllbnQNCj4+PiBhdXRoIGNhbiBiZSBkb25lIGF0 IHRoZSBUTFMgbGF5ZXIuIFRoZW4gb25lIG5lZWRzIHRvIGhhdmUgY2hhbm5lbA0KPj4+IGJpbmRp bmcgYW5kIHRoYXQncyBhbm90aGVyIGFwcHJvYWNoLg0KPj4+IA0KPj4+IC0gIkhUVFAgZGlnZXN0 IGF1dGgiIG9ubHkgcHJvdmlkZXMgYSBoYXNoLWJhc2VkIHByb3RlY3Rpb24gZm9yIHNlY3JldHMN Cj4+PiBsaWtlIHBhc3N3b3JkIGFuZCBJRCwgYW5kIGlzIGtub3duIHRvIGJlIHZ1bG5lcmFibGUg dG8gTWl0TQ0KPj4+IChNYW4taW4tdGhlLU1pZGRsZSkgYXR0YWNrcy4gU2luY2UgYWNjb3JkaW5n IHRvIHRoZSBQQVdTIFdHIGRvY3VtZW50LA0KPj4+IGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0 bXQtdXNlY2FzZXMtcnFtdHMtMDYsIENoYXB0ZXIgOCwgdGhyZWF0IDcsDQo+Pj4gTWl0TSBhdHRh Y2sgc2hvdWxkIGJlIHRod2FydGVkLiBUaGlzIGRyYWZ0IHVzaW5nICJIVFRQIGRpZ2VzdCBhdXRo Ig0KPj4+IG9idmlvdXNseSBkb2VzIG5vdCBzYXRpc2Z5IHRoZSBzZWN1cml0eSByZXF1aXJlbWVu dC4NCj4+PiANCj4+PiBTRD4gIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhpcy4gSFRUUC9UTFMgaXMg dXNlZCBpbiBvdXIgc2NoZW1lLg0KPj4+IA0KPj4+IC0gIkhUVFAgZGlnZXN0IGF1dGgiIGRpZmZl cnMgZnJvbSBIVFRQIG92ZXIgVExTLCB3aGVyZSB0aGUgZm9ybWVyDQo+Pj4gcHJvdmlkZXMgbm8g ZW5jcnlwdGlvbiBmb3IgY29udGVudCwgYnV0IHRoZSBsYXR0ZXIgY2FuIGVuY3J5cHQgdGhlDQo+ Pj4gY29udGVudCBieSBQdWJsaWMgS2V5IGNyeXB0by4gVGh1cyBUTFMgaXMgcHJlZmVycmVkLiAt ICJIVFRQIGRpZ2VzdA0KPj4+IGF1dGgiIGRvZXMgbm90IHN1cHBvcnQgSE1BQyBhbGdvcml0aG0g KHNvLWNhbGxlZCBLZXllZCBIYXNoKSwgdGh1cyBpdA0KPj4+IGlzIHlldCBhIGxpdHRsZSByaXNr eSB0byB1c2UgU0hBLTEgdG8gcmVwbGFjZSBjdXJyZW50IE1ENSBhbGdvcml0aG0sDQo+Pj4gYmVj YXVzZSBOSVNUIGhhcyBub3QgcmVjb21tZW5kZWQgdG8gdXNlIHRoZSBjb2xsaXNpb24gcmVzaXN0 YW5jZSBvZg0KPj4+IFNIQS0xIChidXQgSE1BQy1TSEExIGlzIGZpbmUpLiBJbiBjb250cmFzdCwg VExTIHN1cHBvcnRzIEhNQUMgYW5kIGRvZXMNCj4+PiBub3QgaGF2ZSBzdWNoIGEgcHJvYmxlbS4N Cj4+PiANCj4+PiBTRD4gWWVzIGl0IHNob3VsZCBiZSBITUFDLVNIQTEuDQo+Pj4gDQo+Pj4gRnJv bSB0aGUgYWJvdmUgYW5hbHlzaXMsIGl0IGlzIGNsZWFyIHRvIHNlZSB0aGF0IHRoZSBzZWN1cml0 eSBhbmQNCj4+PiBwcml2YWN5IG9mIFBBV1MgaXMgbm90IHN0cmFpZ2h0Zm9yd2FyZCBhbmQgbmVl ZHMgdG8gYmUgY2FyZWZ1bGx5DQo+Pj4gaW52ZXN0aWdhdGVkLCBmb3IgZGVzaWduIGFuZCBpbXBs ZW1lbnRhdGlvbi4NCj4+PiBJdCBpcyBhbHNvIHRoZSByZWFzb24gd2h5IHdlIGhhdmUgc3VibWl0 dGVkIGFuIGluZGVwZW5kZW50IGRyYWZ0IGZvcg0KPj4+IFBBV1Mgc2VjdXJpdHksIHRvIHByb3Zp ZGUgYSBiYXNlIGZvciBkaXNjdXNzaW9uLg0KPj4+IA0KPj4+IEJSLA0KPj4+IFlhbmcNCj4+PiA9 PT09PT09PT09PT09PT09PT0NCj4+PiAgWWFuZyBDdWksICBQaC5ELg0KPj4+ICBIdWF3ZWkgVGVj aG5vbG9naWVzDQo+Pj4gIGN1aXlhbmdAaHVhd2VpLmNvbQ0KPj4+ICANCj4+Pj4gLS0tLS3Tyrz+ 1K28/i0tLS0tDQo+Pj4+ILeivP7IyzogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3 cy1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+Pj4+IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPj4+ PiC3osvNyrG85DogMjAxMsTqN9TCMjLI1SA3OjMxDQo+Pj4+IMrVvP7IyzogcGF3c0BpZXRmLm9y Zw0KPj4+PiDW98ziOiBbcGF3c10gY29tbWVudHMgb24gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wt MDIudHh0DQo+Pj4+IA0KPj4+PiBJdCB3b3VsZCBiZSBiZW5lZmljaWFsIGlmIHRoZXJlIHdlcmUg ZGlzY3Vzc2lvbnMgb24gdGhlIGRyYWZ0cyB0bw0KPj4+PiBzdWJtaXR0ZWQgYWhlYWQgb2YgdGhl IEYyRiBwcmVzZW50YXRpb25zLg0KPj4+PiBUaHVzLCBJJ3ZlIHRha2VuIHRoZSBpbml0aWF0aXZl IHRvIHJlYWQgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIHNvbWUNCj4+Pj4gaW5pdGlhbA0KPj4+PiBj b21tZW50czoNCj4+Pj4gDQo+Pj4+IDEuIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ug b2YgdGhlIGluaXRpYWxpemF0aW9uIHByb2Nlc3MgYW5kDQo+Pj4+IHdoeSBtZXNzYWdlcyBJTlQt UkVRIGFuZCBJTlQtUkVTUCBhcmUgbmVjZXNzYXJ5LiBUaGUgY2FwYWJpbGl0eQ0KPj4+PiBleGNo YW5nZSBjYW4gYmUgZG9uZSBkdXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiBXZSBtYXkg ZXZlbg0KPj4+PiBjb25zaWRlciBtZXJnaW5nIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyB3aXRo IHRoZSBEQiBxdWVyeSBwcm9jZXNzLA0KPj4+PiB0aGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgYW55 IHJlYXNvbiB0byBoYXZlIHRoZW0gYXMgc2VwYXJhdGUgbWVzc2FnZXMuDQo+Pj4+IA0KPj4+PiAy LiB5b3UgbWF5IG5lZWQgYSBzZWN0aW9uIHdoZXJlIHlvdSBtYXAgeW91ciBuZXdseSBkZWZpbmVk IG1lc3NhZ2VzDQo+Pj4+IHRvIGV4aXN0aW5nIGh0dHAgcHJvdG9jb2wgbWVzc2FnZXMuIEkgc2F3 IHRoYXQgeW91IGhhdmUgYW4gZXhhbXBsZQ0KPj4+PiBzZWN0aW9uLCBidXQgYSBub3JtYXRpdmUg c2VjdGlvbiB3b3VsZCBiZSBtb3JlIGRlc2lyYWJsZS4NCj4+Pj4gDQo+Pj4+IDMuIHRoZSBkYXRh IG1vZGVsIHBhcnQgbmVlZHMgc29tZSBtb3JlIHdvcmsuIFRoZSBzdHJ1Y3R1cmUgaXMgbm90DQo+ Pj4+IHZlcnkgY2xlYXIgdG8gbWUsIGFuZCBzb21lIG9mIHRoZSBhdHRyaWJ1dGVzIHJlZmVyZW5j ZSBvYnNvbGV0ZSBSRkMuDQo+Pj4+IEVnLCBSRkMzODI1IGlzIHJlZmVyZW5jZWQgZm9yIHRoZSBs b25naXR1ZGUvbGF0aXR1ZGUgYXR0cmlidXRlcy4gSQ0KPj4+PiB0aGluayB5b3Ugc2hvdWxkIGJl IGJldHRlciBvZiB1c2luZyBhbiBlbGVtZW50IGZvciBnZW8tbG9jYXRpb24sIHdpdGgNCj4+Pj4g dGhlIHN0cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJGQzU0OTEsIGEgc2VwYXJhdGUgZWxlbWVudCBm b3IgdGhlIGNpdmljDQo+Pj4+IGxvY2F0aW9uLCB3aXRoIHRoZSBzdHJ1Y3R1cmUgYXMgZGVmaW5l ZCBpbiBSRkM1MTM5LCBldGMuIEluc3RlYWQgb2YNCj4+Pj4gdGhlIERldmljZU93bmVyIG9iamVj dCwgSSB3b3VsZCB1c2UgYSB2Q2FyZCBlbGVtZW50LCB3aXRoIHRoZQ0KPj4+PiBzdHJ1Y3R1cmUg YXMgZGVmaW5lZCBpbiBSRkMyNDI2LiBZb3UgbWF5IGFsc28gbmVlZCBhbiBpQ2FsZW5kYXINCj4+ Pj4gZWxlbWVudCAoUkZDNTU0NSkgdG8gc3BlY2lmeSB0aGUgY2hhbm5lbCBhdmFpbGFiaWxpdHkg dGltZSAoZWcsIHdoZW4NCj4+Pj4gdGhlIGNoYW5uZWwgaXMgbm90IGF2YWlsYWJsZSBmb3IgdGhl IGZ1bGwgMjRIKS4gRXRjLg0KPj4+PiANCj4+Pj4gTW9yZSBjb21tZW50cyBhcmUgd2VsY29tZS4N Cj4+Pj4gLSBHYWJvcg0KPj4+PiANCj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tIEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZw0KPj4+PiBbbWFpbHRvOnBhd3MtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBEYXMsIFN1YmlyIFNlbnQ6DQo+Pj4+IFNhdHVy ZGF5LCBKdWx5IDE0LCAyMDEyIDc6MzYgQU0gVG86IHBhd3NAaWV0Zi5vcmcgU3ViamVjdDogW3Bh d3NdIEZXOg0KPj4+PiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRhcy1wYXdz LXByb3RvY29sLTAyLnR4dA0KPj4+PiANCj4+Pj4gRGVhciBDaGFpcnMsDQo+Pj4+IFdlIGhhdmUg dXBkYXRlZCBvdXIgZHJhZnQgYW5kIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhIHNsb3QgaW4NCj4+ Pj4gSUVURi04NCB0byBwcmVzZW50IGl0Lg0KPj4+PiANCj4+Pj4gUmVnYXJkcywNCj4+Pj4gX1N1 YmlyDQo+Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcNCj4+Pj4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDE0LCAyMDEyDQo+Pj4+IDEwOjMwIEFNIFRvOiBEYXMsIFN1 YmlyIENjOiBqbWFseWFyQHRlbGNvcmRpYS5jb207DQo+Pj4+IGQuam9zbHluQHNwZWN0cnVtYnJp ZGdlLmNvbSBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+Pj4+IGRyYWZ0 LWRhcy1wYXdzLXByb3RvY29sLSAwMi50eHQNCj4+Pj4gDQo+Pj4+IA0KPj4+PiBBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0IGhhcyBiZWVuDQo+Pj4+ IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3ViaXIgRGFzIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4+Pj4gDQo+Pj4+IEZpbGVuYW1lOgkgZHJhZnQtZGFzLXBhd3MtcHJv dG9jb2wgUmV2aXNpb246CSAwMiBUaXRsZTogCSBEZXZpY2UgdG8NCj4+Pj4gRGF0YWJhc2UgUHJv dG9jb2wgZm9yIFdoaXRlIFNwYWNlIENyZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTE0IFdHIElEOg0K Pj4+PiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24gTnVtYmVyIG9mIHBhZ2VzOiAzMiBVUkw6DQo+Pj4+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRhcy1wYXdzLXByb3Rv Y29sLTAyLnR4dA0KPj4+PiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZGFzLXBhd3MtDQo+Pj4+IHByb3RvY29sIEh0bWxpemVkOiAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFzLSBwYXdzLQ0KPj4+PiBwcm90b2Nv bC0wMiBEaWZmOg0KPj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWRhcy1wYXdzLXByb3RvY29sLTAyDQo+Pj4+IA0KPj4+PiBBYnN0cmFjdDoNCj4+Pj4gICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGBQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3BhY2UN Cj4+Pj4gICAgZGF0YWJhc2UgKFBBV1MpJyB0aGF0IHVzZXMgSFRUUC9UTFMgYXMgdHJhbnNwb3J0 LiAgVGhlIHByb3RvY29sIGlzDQo+Pj4+ICAgIHVzZWQgZm9yIHJldHJpZXZpbmcgdGhlIG5lY2Vz c2FyeSBUViB3aGl0ZSBzcGFjZSBpbmZvcm1hdGlvbg0KPj4+PiAgICAoZS5nLiwgY2hhbm5lbCwg ZnJlcXVlbmN5LCB0cmFuc21pdHRlZCBwb3dlcikgYXQgYSBnaXZlbiBsb2NhdGlvbg0KPj4+PiAg ICBhbmQgdGltZSBmcm9tIGEgZGF0YWJhc2UgdGhhdCBpcyBvcGVyYXRpbmcgdW5kZXIgYSByZWd1 bGF0b3J5DQo+Pj4+ICAgIGRvbWFpbi4gVGhlIGRvY3VtZW50IGluY2x1ZGVzIHRoZSBwcm90b2Nv bCBmdW5jdGlvbmFsaXRpZXMsIGl0cw0KPj4+PiAgICBlbGVtZW50cywgY29ycmVzcG9uZGluZyBk YXRhIG1vZGVsIGFuZCByZWNvbW1lbmRzIGl0cyBlbmNvZGluZw0KPj4+PiAgICBzY2hlbWUuDQo+ Pj4+IA0KDQo= From weixinpeng@huawei.com Thu Jul 26 19:19:51 2012 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 7AC7721F856C for ; Thu, 26 Jul 2012 19:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 slmhYHizMap6 for ; Thu, 26 Jul 2012 19:19:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C78E421F8470 for ; Thu, 26 Jul 2012 19:19:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIC64600; Thu, 26 Jul 2012 22:19:49 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jul 2012 19:16:39 -0700 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jul 2012 19:16:45 -0700 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.130]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Fri, 27 Jul 2012 10:16:31 +0800 From: Weixinpeng To: "Das, Subir" , Peter McCann , Cuiyang , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQAB/KozAAGpqGMABA6hCAABVA+6AALBiIcA== Date: Fri, 27 Jul 2012 02:16:31 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DD31@SZXEML508-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E18FC3@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.64] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 02:19:51 -0000 SGksDQpJIHRoaW5rIGluIHRoZSByZXF1ZXN0IG1lc3NhZ2UgZnJvbSBtYXN0ZXIgZGV2aWNlIHRv IHRoZSBkYXRhYmFzZSBQT1NUIG1ldGhvZCBtYXkgYmUgb2ssIGJ1dCBmb3IgdGhlIA0KbWVzc2Fn ZSB0aGF0IHRoZSBkYXRhYmFzZSByZXNwb25zZXMgdG8gdGhlIG1hc3RlciBkZXZpY2UgU0hPVUxE IGJlIGEgSFRUUCByZXNwb25zZSBtZXNzYWdlLCBOT1QgYSBQT1NUIG1lc3NhZ2UuDQoNCi13ZWkN Cg0KU0Q+ICBUaGUgZGF0YWJhc2UgcmVzcG9uZHMgdG8gYWxsIHJlcXVlc3RzLiBJbiBvdXIgZXhh bXBsZSwgIHdlIGN1cnJlbnRseSBzaG93IFBBV1MgcHJvdG9jb2wgbWVzc2FnZSAgZGV0YWlscyB0 aGF0IGFyZSBpbmNsdWRlZCBpbiB0aGUgYm9keSBvZiB0aGUgSFRUUCBQT1NULg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhcywgU3ViaXINClNlbnQ6IFRodXJz ZGF5LCBKdWx5IDI2LCAyMDEyIDE6MjYgUE0NClRvOiBQZXRlciBNY0Nhbm47IEN1aXlhbmc7IEdh Ym9yLkJhamtvQG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtwYXdzXSBj b21tZW50cyBvbiBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCg0KQW5zd2VycyBpbmxp bmUuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGV0ZXIgTWNDYW5uIFtt YWlsdG86UGV0ZXIuTWNDYW5uQGh1YXdlaS5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDI1 LCAyMDEyIDM6MDQgUE0NClRvOiBDdWl5YW5nOyBEYXMsIFN1YmlyOyBHYWJvci5CYWprb0Bub2tp YS5jb207IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBjb21tZW50cyBvbiBkcmFmdC1kYXMt cGF3cy1wcm90b2NvbC0wMi50eHQNCg0KSXQgYWxzbyBhcHBlYXJzIHRoYXQgZHJhZnQtZGFzIHJl LWltcGxlbWVudHMgSFRUUCBEaWdlc3QgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLCByYXRoZXIg dGhhbiBhdHRlbXB0aW5nIHRvIHVzZSBzdGFuZGFyZCBIVFRQIERpZ2VzdC4gSSBhbSBjdXJpb3Vz IGFzIHRvIHdoeSB5b3UgbWFkZSB0aGlzIGNob2ljZS4gIA0KDQpTRD4gIFRoaXMgaXMgbm90IG5l dy4gT3RoZXIgSUVURiBwcm90b2NvbHMgaGF2ZSB1c2VkIHRoaXMsIGZvciBleGFtcGxlLCBSRkMg MzI2MQ0KDQpJcyBpdCBzbyB0aGF0IHlvdSBjYW4gdXBncmFkZSB0aGUgaGFzaCBmdW5jdGlvbiBm cm9tIE1ENSB0byBTSEEtMT8NCg0KU0Q+IElFVEYgZG9lcyBub3QgcmVjb21tZW5kICB1c2luZyBN RDUgYW55bW9yZS4gDQoNCkFsc28sIHlvdSBkb24ndCBzaG93IHRoZSBtZXNzYWdlcyB0aGF0IHJl bGF5IHRoZSBub25jZSB2YWx1ZSBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudC4gIEkgdGhp bmsgeW91IHdpbGwgbmVlZCB0byBzcGVjaWZ5IHRoYXQgbWVzc2FnZSBhcyB3ZWxsLiAgSFRUUCBk b2VzIHRoaXMgd2l0aCBhIDQwMSBVbmF1dGhvcml6ZWQgcmVzcG9uc2UuDQoNClNEPiBUaGlzIGlz IGRvbmUgdmlhIGluaXRpYWxpemF0aW9uIHJlc3BvbnNlIG1lc3NhZ2UsIElOSVRfUkVTUC4gIFJl bWVtYmVyIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBwZXJmb3JtZWQgZHVyaW5nIGluaXRpYWxp emF0aW9uIHN0YWdlLiBXZSBzaG91bGQgaGF2ZSBpbmNsdWRlZCB0aGUgZGV0YWlscyBvZiBJTklU X1JFUSBhbmQgSU5JVF9SRVNQIG1lc3NhZ2VzIGluIGV4YW1wbGUgc2VjdGlvbi4gV2lsbCBpbmNs dWRlIHRoaXMgaW4gbmV4dCB2ZXJzaW9uLg0KDQpJdCBhbHNvIGxvb2tzIGxpa2UgeW91IGFyZSBu b3Qgc2VuZGluZyBhbnkgcmVzcG9uc2VzIGF0IGFsbCBpbiB5b3VyIGV4YW1wbGVzLCBqdXN0IHVz aW5nIFBPU1QgaW4gYm90aCBkaXJlY3Rpb25zLiAgVGhpcyBzZWVtcyBzdHJhbmdlLg0KDQpTRD4g IFRoZSBkYXRhYmFzZSByZXNwb25kcyB0byBhbGwgcmVxdWVzdHMuIEluIG91ciBleGFtcGxlLCAg d2UgY3VycmVudGx5IHNob3cgUEFXUyBwcm90b2NvbCBtZXNzYWdlICBkZXRhaWxzIHRoYXQgYXJl IGluY2x1ZGVkIGluIHRoZSBib2R5IG9mIHRoZSBIVFRQIFBPU1QuDQoNCg0KSXQgbWlnaHQgYmUg YmV0dGVyIHRvIHJlbHkgb24gY2xpZW50IGNlcnRpZmljYXRlcyBhdCB0aGUgVExTIGxheWVyIHRv IGF1dGhlbnRpY2F0ZSB0aGUgbWFzdGVyIGRldmljZS4NCg0KU0Q+IFdlIGRvIG5vdCBhc3N1bWUg dGhhdCB0aGUgY2xpZW50IGhhcyBjZXJ0LiBPdXIgZXhwZXJpZW5jZSB3aXRoIFdTRCBtYW51ZmFj dHVyZXMgaXMgdGhhdCB0aGV5IHByZWZlciB0aGUgbW9kZWwgb2YgYSBzaGFyZWQgc2VjcmV0IGZv ciBNYXN0ZXIgV1NEIGF1dGhlbnRpY2F0aW9uIHRvIG1hbmFnZSBjb3N0cy4NCg0KRm9yIGF1dGhl bnRpY2F0aW5nIHRoZSBzbGF2ZSBkZXZpY2VzLCB3ZSBtaWdodCBuZWVkIHNvbWV0aGluZyBhdCB0 aGUgYXBwbGljYXRpb24gbGF5ZXIuICBUaGF0IGlzIGEgc2VwYXJhdGUgZGlzY3Vzc2lvbiB0aGF0 IHN0aWxsIG5lZWRzIHRvIGhhcHBlbiAobmVpdGhlciBkcmFmdCByaWdodCBub3cgZGVhbHMgd2l0 aCBhdXRoZW50aWNhdGluZyB0aGUgc2xhdmUgZGV2aWNlIGlkZW50aWZpZXJzKS4NCg0KU0Q+IE91 ciB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYXV0aGVudGljYXRpbmcgdGhlIHNsYXZlIGRldmljZXMg aXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgUEFXUy4gVGhlcmUgaXMgbm8gZGlyZWN0IGNvbW11bmlj YXRpb24gYmV0d2VlbiBzbGF2ZSBkZXZpY2VzIGFuZCB0aGUgZGF0YWJhc2UuIEhvd2V2ZXIsIHdl IGRvIHN1cHBvcnQgdGhlIGNhcGFiaWxpdHkgb2YgdmFsaWRhdGluZyB0aGUgc2xhdmUgZGV2aWNl cyB2aWEgTVNELiANCg0KLVBldGUNCg0KDQpDdWl5YW5nIHdyb3RlOiANCj4gVGhhbmtzIGZvciB5 b3VyIGFuc3dlcnMuDQo+IA0KPiBCdXQgdGhlbiBJIHJlYWxpemVkIHRoYXQgdGhlIHByb3Bvc2Fs IGlzIHVzaW5nIGEga2luZCBvZiB0d28tbGF5ZXIgDQo+IGF1dGhlbnRpY2F0aW9uIHByb3RvY29s cywgcy50LiBhbiBvdXRlciBsYXllciBwcm90b2NvbCBvZiBUTFMgDQo+IGF1dGhlbnRpY2F0aW9u IG9mIHNlcnZlciAoZGF0YWJhc2UpLCBhbmQgYW4gaW5uZXIgbGF5ZXIgcHJvdG9jb2wgDQo+IGF1 dGhlbnRpY2F0aW9uIG9mIGNsaWVudCAoTWFzdGVyIGRldmljZSkuDQo+IFVuZm9ydHVuYXRlbHks IGl0IGlzIGtub3duIHRoYXQgc3VjaCBhIG1peGVkIG1vZGUgb2YgYXV0aGVudGljYXRpb24gaXMg DQo+IHZ1bG5lcmFibGUgdG8gTWl0TS4NCj4gSSBhbSBzZXJpb3VzbHkgY29uY2VybmVkIHRoYXQg dGhpcyBkcmFmdCBpcyBhbHNvIGluIHRoZSBjYXNlLg0KPiANCj4gSW4gcGFydGljdWxhciwgc3Vj aCBhIGNvbWJpbmF0aW9uIG9mIFRMUyBvZiBzZXJ2ZXIgYXV0aGVudGljYXRpb24gYW5kIA0KPiBI VFRQIGRpZ2VzdCBhdXRoZW50aWNhdGlvbiBvZiBjbGllbnQsIGlzIHJhaXNlZCBhcyBhbiBpbnNl Y3VyZSBleGFtcGxlIA0KPiBpbiBzZXZlcmFsIHBsYWNlcywgaW5jbHVkaW5nOg0KPiAtIFJGQyA0 MTY5DQo+IC0gQXNva2FuLU5pZW1pLU55YmVyZyBhdHRhY2sgMjAwMiwgaHR0cDovL2VwcmludC5p YWNyLm9yZy8yMDAyLzE2My5wZGYNCj4gDQo+IFF1b3RlZCBmcm9tIFJGQyA0MTY5LCBTZWMgNC4z LCBNYW4taW4tdGhlLU1pZGRsZSBBdHRhY2ssDQo+IAkiIEZvciBleGFtcGxlLCB0aGUgdXNlIG9m IFRMUyB3aXRoIEhUVFAgRGlnZXN0IGF1dGhlbnRpY2F0aW9uIChpLmUuLA0KPiAgICBUTFMgZm9y IHNlcnZlciBhdXRoZW50aWNhdGlvbiwgYW5kIHN1YnNlcXVlbnQgdXNlIG9mIEhUVFAgRGlnZXN0 IGZvcg0KPiAgICBjbGllbnQgYXV0aGVudGljYXRpb24pIGlzIGFuIGluc3RhbmNlIG9mIHN1Y2gg c2NlbmFyaW8uICBIVFRQDQo+ICAgIGNoYWxsZW5nZXMgYW5kIHJlc3BvbnNlcyBjYW4gYmUgZmV0 Y2hlZCBmcm9tIGFuZCB0byBkaWZmZXJlbnQgVExTDQo+ICAgIHR1bm5lbHMgd2l0aG91dCBub3Rp Y2luZyB0aGVpciBvcmlnaW4uIg0KPiBBbHRob3VnaCB0aGUgYWJvdmUgYXR0YWNrIG5lZWRzIHNv bWUgY29uZGl0aW9ucywgc3VjaCBhIHVzZSBvZiBUTFMgYW5kIA0KPiBIVFRQIGRpZ2VzdCBkb2Vz IGxlYWQgdGhlIHByb3Bvc2VkIHByb3RvY29sIHRvIGEgZGFuZ2Vyb3VzIHNpdHVhdGlvbi4NCj4g SXQgaXMgbWFpbmx5IGJlY2F1c2UsIChkZXRhaWxzIGNvdWxkIGJlIGZvdW5kIGluIEFzb2thbiBl dCBhbCdzIHBhcGVyKQ0KPiAtIEhUVFAgZGlnZXN0IGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIGlz IHRvbyB3ZWFrLiBJdCBvbmx5IGhhcyBhIA0KPiBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24g dG8gcnVuIGEgb25lLXdheSBjb21wdXRhdGlvbiBvZiB0aGUgDQo+IHBhc3N3b3JkLCBsYWNrIG9m IHNlY3JldCBrZXkgYmFzZWQgb3IgcHVibGljIGtleSBiYXNlZCBwcm90ZWN0aW9uLCANCj4gdW5s aWtlIFRMUy4NCj4gLSBUaGUgc2Vzc2lvbiBrZXkgaXMgbmVnb3RpYXRlZCBpbiBvdXRlciBUTFMg cHJvdG9jb2wgc29sZWx5Lg0KPiAtIFRoZSBpbm5lciBwcm90b2NvbCBIVFRQIGRpZ2VzdCBhdXRo IGRvZXMgbm90IHJlYWxpemUgdGhlIGV4aXN0ZW5jZSANCj4gb2Ygb3V0ZXIgVExTIHByb3RvY29s Lg0KPiANCj4gQSBwb3NzaWJsZSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gbWlnaHQgYmUgdG8g Y3J5cHRvZ3JhcGhpY2FsbHkgYmluZCANCj4gdGhlIGlubmVyIGFuZCBvdXRlciBwcm90b2NvbCwg Zm9yIGV4YW1wbGUsIHRvIGdlbmVyYXRlIGEgc2Vzc2lvbiBrZXkgDQo+IGZvciBpbm5lciBwcm90 b2NvbC4NCj4gSG93ZXZlciwgSFRUUCBkaWdlc3QgZG9lcyBub3QgdXNlIG5vciBnZW5lcmF0ZSBz ZXNzaW9uIGtleS4uLg0KPiBBZ2FpbiwgSU1ITywgaXQgc2VlbXMgbm90IGEgZ29vZCBpZGVhIHRv IHVzZSBIVFRQIGRpZ2VzdCBhdXRoIHByb3RvY29sIA0KPiBmb3IgY2xpZW50IGF1dGhlbnRpY2F0 aW9uLiBTb21lIG90aGVyIGNhbmRpZGF0ZXMgbmVlZCB0byBiZSBjb25zaWRlcmVkLg0KPiANCj4g QW5kIGFnYWluLCBJIGZlZWwgdGhhdCBpdCBpcyBuZWNlc3NhcnkgdG8gc2V0IHVwIGFuIGluZGVw ZW5kZW50IGRyYWZ0IA0KPiB0YWtpbmcgY2FyZSBvZiBQQVdTIHNlY3VyaXR5LCB3aGljaCBtYXkg aGVscCBkZXNpZ24gYW5kIGltcGxlbWVudCB0aGUgDQo+IFBBV1MgcHJvdG9jb2wuDQo+IEhvcGUg dGhhdCBvdXIgZHJhZnQsIGRyYWZ0LXd1LXBhd3Mtc2VjdXRpdHktMDAsIGNvdWxkIGJlIGEgc3Rh cnRpbmcgDQo+IHBvaW50LiBBbnkgY29tbWVudCBpcyB3ZWxjb21lLg0KPiANCj4gQlIsDQo+IFlh bmcNCj4gPT09PT09PT09PT09PT09PT09DQo+ICBZYW5nIEN1aSwgIFBoLkQuDQo+ICBIdWF3ZWkg VGVjaG5vbG9naWVzDQo+ICBjdWl5YW5nQGh1YXdlaS5jb20NCj4gDQo+PiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4+ILeivP7IyzogRGFzLCBTdWJpciBbbWFpbHRvOnNkYXNAYXBwY29tc2NpLmNvbV0N Cj4+ILeiy83KsbzkOiAyMDEyxOo31MIyNMjVIDc6NDYNCj4+IMrVvP7IyzogQ3VpeWFuZzsgR2Fi b3IuQmFqa29Abm9raWEuY29tOyBwYXdzQGlldGYub3JnDQo+PiDW98ziOiBSRTogY29tbWVudHMg b24gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+PiANCj4+IFRoYW5rcyBmb3IgeW91 ciBjb21tZW50cy4gU29tZSBhbnN3ZXJzIGlubGluZS4NCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+IEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3Mt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPj4gT2YgQ3VpeWFuZw0KPj4gU2VudDogTW9u ZGF5LCBKdWx5IDIzLCAyMDEyIDg6NDUgQU0NCj4+IFRvOiBHYWJvci5CYWprb0Bub2tpYS5jb207 IHBhd3NAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbcGF3c10gY29tbWVudHMgb24gZHJhZnQt ZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+PiANCj4+IEhpIEFsbCwNCj4+IA0KPj4gSSB3b3Vs ZCBsaWtlIHRvIHByb3ZpZGUgc29tZSBjb21tZW50cyB0byB0aGlzIGRyYWZ0LCBmcm9tIGEgc2Vj dXJpdHkgDQo+PiBwb2ludCBvZiB2aWV3Lg0KPj4gSG9wZSB0aGF0IGl0IHdpbGwgYmUgaGVscGZ1 bC4NCj4+IA0KPj4gVGhlIFRMUyBhbmQgIkhUVFAgRGlnZXN0IEF1dGgiIGhhdmUgYmVlbiB1c2Vk LCBidXQgc2VlbSB1bmNsZWFyIGZvciBtZS4NCj4+IEJlc2lkZXMsIGl0IGlzIG5vdCByZWNvbW1l bmRlZCB0byB1c2UgdGhlIGxhdHRlciBmb3Igc29tZSByZWFzb25zIA0KPj4gbGlzdGVkIGJlbG93 LiAtIEl0IGlzIHNhaWQgdGhhdCB0aGUgSFRUUC9UTFMgcHJvdG9jb2wgaXMgZGVwbG95ZWQgZm9y IA0KPj4gbXV0dWFsIGF1dGhlbnRpY2F0aW9uLg0KPj4gDQo+PiBTRD4gVGhpcyBpcyBub3QgY29y cmVjdC4NCj4+IA0KPj4gSG93ZXZlciwgIkhUVFAgZGlnZXN0IGF1dGhlbnRpY2F0aW9uIiBpcyBh Y3R1YWxseSB1c2VkIGZvciANCj4+IGF1dGhlbnRpY2F0aW5nIHRoZSBkZXZpY2UsDQo+PiANCj4+ IFNEPiAgRGlnZXN0IEF1dGhlbnRpY2F0aW9uIGlzIHVzZWQgdG8gYXV0aGVudGljYXRlIHRoZSBj bGllbnQgYXQgdGhlIA0KPj4gU0Q+IFBBV1MNCj4+IGxheWVyLg0KPj4gDQo+PiB3aGljaCBpcyB0 eXBpY2FsbHkgd2Vha2VyIHRoYW4gbm9ybWFsIFRMUy4NCj4+IA0KPj4gU0Q+IFdoeSBpcyBpdCB3 ZWFrZXI/DQo+PiANCj4+IE9ubHkgdGhlIHNlcnZlciBzaWRlIGF1dGhlbnRpY2F0aW9uIGlzIHBl cmZvcm1lZCBieSBUTFMgDQo+PiBjZXJ0aWZpY2F0ZS1iYXNlZCBjcnlwdG8gbWV0aG9kLg0KPj4g LSBJdCBhcHBlYXJzIHRoYXQgYXV0aGVudGljYXRpb24gaXMgZG9uZSBpbiBkaWZmZXJlbnQgbGF5 ZXJzLCBpLmUuLCANCj4+IGRldmljZSBpcyBkb25lIGluIFBBV1MgbGF5ZXIgYnkgIkhUVFAgZGln ZXN0IGF1dGgiIGFuZCBzZXJ2ZXIgaXMgDQo+PiBhY2hpZXZlZCBpbiBUTFMgbGF5ZXIgYnkgY2Vy dGlmaWNhdGUuDQo+PiANCj4+IFNEPiBZZXMsIGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgYXQgdGhl IFBBV1MgbGF5ZXIgYnkgdXNpbmcgZGlnZXN0DQo+PiBhdXRoZW50aWNhdGlvbi4NCj4+IA0KPj4g SSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgc2VjdXJpdHkgaXMgZG9uZSBpbiBtaXhlZCBsYXllcnM/ DQo+PiANCj4+IC0gSXQgaXMgc2FpZCB0aGF0IGNvbmZpZGVudGlhbGl0eSBpcyBwcm90ZWN0ZWQg aW4gSFRUUFMgbGF5ZXIsIGJ1dCBpZiANCj4+IGF1dGhlbnRpY2F0aW5nIGRldmljZSBpcyBhY2hp ZXZlZCBpbiBkaWZmZXJlbnQgbGF5ZXIgKGkuZS4gaW4gUEFXUyANCj4+IGxheWVyKSwgaG93IGNh biB0aGUgZGV2aWNlIGFuZCBzZXJ2ZXIgbmVnb3RpYXRlIHRoZSBzZXNzaW9uIGtleT8NCj4+IA0K Pj4gU0Q+IER1cmluZyBub3JtYWwgVExTIG5lZ290aWF0aW9uLg0KPj4gDQo+PiAtIE9yLCBpZiBt eSBhYm92ZSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nIGFuZCBtdXR1YWwgYXV0aGVudGljYXRpb24g aXMgDQo+PiBpbmRlZWQgZG9uZSBpbiBUTFMgbGF5ZXIsIHdoeSBkb2VzIGl0IG5lZWQgdG8gaGF2 ZSBhZGRpdGlvbmFsICJIVFRQIA0KPj4gZGlnZXN0IGF1dGgiIGluIFBBV1MgbGF5ZXI/DQo+PiAN Cj4+IFNEPiBPbmx5IGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBkb25lIGF0IHRoZSBQQVdTIGxh eWVyLiBPZiBjb3Vyc2UgDQo+PiBTRD4gY2xpZW50DQo+PiBhdXRoIGNhbiBiZSBkb25lIGF0IHRo ZSBUTFMgbGF5ZXIuIFRoZW4gb25lIG5lZWRzIHRvIGhhdmUgY2hhbm5lbCANCj4+IGJpbmRpbmcg YW5kIHRoYXQncyBhbm90aGVyIGFwcHJvYWNoLg0KPj4gDQo+PiAtICJIVFRQIGRpZ2VzdCBhdXRo IiBvbmx5IHByb3ZpZGVzIGEgaGFzaC1iYXNlZCBwcm90ZWN0aW9uIGZvciANCj4+IHNlY3JldHMg bGlrZSBwYXNzd29yZCBhbmQgSUQsIGFuZCBpcyBrbm93biB0byBiZSB2dWxuZXJhYmxlIHRvIE1p dE0NCj4+IChNYW4taW4tdGhlLU1pZGRsZSkgYXR0YWNrcy4gU2luY2UgYWNjb3JkaW5nIHRvIHRo ZSBQQVdTIFdHIGRvY3VtZW50LCANCj4+IGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNl Y2FzZXMtcnFtdHMtMDYsIENoYXB0ZXIgOCwgdGhyZWF0IDcsIA0KPj4gTWl0TSBhdHRhY2sgc2hv dWxkIGJlIHRod2FydGVkLiBUaGlzIGRyYWZ0IHVzaW5nICJIVFRQIGRpZ2VzdCBhdXRoIg0KPj4g b2J2aW91c2x5IGRvZXMgbm90IHNhdGlzZnkgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50Lg0KPj4g DQo+PiBTRD4gIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhpcy4gSFRUUC9UTFMgaXMgdXNlZCBpbiBv dXIgc2NoZW1lLg0KPj4gDQo+PiAtICJIVFRQIGRpZ2VzdCBhdXRoIiBkaWZmZXJzIGZyb20gSFRU UCBvdmVyIFRMUywgd2hlcmUgdGhlIGZvcm1lciANCj4+IHByb3ZpZGVzIG5vIGVuY3J5cHRpb24g Zm9yIGNvbnRlbnQsIGJ1dCB0aGUgbGF0dGVyIGNhbiBlbmNyeXB0IHRoZSANCj4+IGNvbnRlbnQg YnkgUHVibGljIEtleSBjcnlwdG8uIFRodXMgVExTIGlzIHByZWZlcnJlZC4gLSAiSFRUUCBkaWdl c3QgDQo+PiBhdXRoIiBkb2VzIG5vdCBzdXBwb3J0IEhNQUMgYWxnb3JpdGhtIChzby1jYWxsZWQg S2V5ZWQgSGFzaCksIHRodXMgaXQgDQo+PiBpcyB5ZXQgYSBsaXR0bGUgcmlza3kgdG8gdXNlIFNI QS0xIHRvIHJlcGxhY2UgY3VycmVudCBNRDUgYWxnb3JpdGhtLCANCj4+IGJlY2F1c2UgTklTVCBo YXMgbm90IHJlY29tbWVuZGVkIHRvIHVzZSB0aGUgY29sbGlzaW9uIHJlc2lzdGFuY2Ugb2YNCj4+ IFNIQS0xIChidXQgSE1BQy1TSEExIGlzIGZpbmUpLiBJbiBjb250cmFzdCwgVExTIHN1cHBvcnRz IEhNQUMgYW5kIA0KPj4gZG9lcyBub3QgaGF2ZSBzdWNoIGEgcHJvYmxlbS4NCj4+IA0KPj4gU0Q+ IFllcyBpdCBzaG91bGQgYmUgSE1BQy1TSEExLg0KPj4gDQo+PiBGcm9tIHRoZSBhYm92ZSBhbmFs eXNpcywgaXQgaXMgY2xlYXIgdG8gc2VlIHRoYXQgdGhlIHNlY3VyaXR5IGFuZCANCj4+IHByaXZh Y3kgb2YgUEFXUyBpcyBub3Qgc3RyYWlnaHRmb3J3YXJkIGFuZCBuZWVkcyB0byBiZSBjYXJlZnVs bHkgDQo+PiBpbnZlc3RpZ2F0ZWQsIGZvciBkZXNpZ24gYW5kIGltcGxlbWVudGF0aW9uLg0KPj4g SXQgaXMgYWxzbyB0aGUgcmVhc29uIHdoeSB3ZSBoYXZlIHN1Ym1pdHRlZCBhbiBpbmRlcGVuZGVu dCBkcmFmdCBmb3IgDQo+PiBQQVdTIHNlY3VyaXR5LCB0byBwcm92aWRlIGEgYmFzZSBmb3IgZGlz Y3Vzc2lvbi4NCj4+IA0KPj4gQlIsDQo+PiBZYW5nDQo+PiA9PT09PT09PT09PT09PT09PT0NCj4+ ICBZYW5nIEN1aSwgIFBoLkQuDQo+PiAgSHVhd2VpIFRlY2hub2xvZ2llcw0KPj4gIGN1aXlhbmdA aHVhd2VpLmNvbQ0KPj4gDQo+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+Pj4gt6K8/sjLOiBwYXdz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4+ PiBHYWJvci5CYWprb0Bub2tpYS5jb20NCj4+PiC3osvNyrG85DogMjAxMsTqN9TCMjLI1SA3OjMx DQo+Pj4gytW8/sjLOiBwYXdzQGlldGYub3JnDQo+Pj4g1vfM4jogW3Bhd3NdIGNvbW1lbnRzIG9u IGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPj4+IA0KPj4+IEl0IHdvdWxkIGJlIGJl bmVmaWNpYWwgaWYgdGhlcmUgd2VyZSBkaXNjdXNzaW9ucyBvbiB0aGUgZHJhZnRzIHRvIA0KPj4+ IHN1Ym1pdHRlZCBhaGVhZCBvZiB0aGUgRjJGIHByZXNlbnRhdGlvbnMuDQo+Pj4gVGh1cywgSSd2 ZSB0YWtlbiB0aGUgaW5pdGlhdGl2ZSB0byByZWFkIHRoZSBkcmFmdCBhbmQgcHJvdmlkZSBzb21l IA0KPj4+IGluaXRpYWwNCj4+PiBjb21tZW50czoNCj4+PiANCj4+PiAxLiBJIGRvIG5vdCB1bmRl cnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoZSBpbml0aWFsaXphdGlvbiBwcm9jZXNzIGFuZCANCj4+ PiB3aHkgbWVzc2FnZXMgSU5ULVJFUSBhbmQgSU5ULVJFU1AgYXJlIG5lY2Vzc2FyeS4gVGhlIGNh cGFiaWxpdHkgDQo+Pj4gZXhjaGFuZ2UgY2FuIGJlIGRvbmUgZHVyaW5nIHRoZSByZWdpc3RyYXRp b24gcHJvY2Vzcy4gV2UgbWF5IGV2ZW4gDQo+Pj4gY29uc2lkZXIgbWVyZ2luZyB0aGUgcmVnaXN0 cmF0aW9uIHByb2Nlc3Mgd2l0aCB0aGUgREIgcXVlcnkgcHJvY2VzcywgDQo+Pj4gdGhlcmUgZG9l c24ndCBzZWVtIHRvIGJlIGFueSByZWFzb24gdG8gaGF2ZSB0aGVtIGFzIHNlcGFyYXRlIG1lc3Nh Z2VzLg0KPj4+IA0KPj4+IDIuIHlvdSBtYXkgbmVlZCBhIHNlY3Rpb24gd2hlcmUgeW91IG1hcCB5 b3VyIG5ld2x5IGRlZmluZWQgbWVzc2FnZXMgDQo+Pj4gdG8gZXhpc3RpbmcgaHR0cCBwcm90b2Nv bCBtZXNzYWdlcy4gSSBzYXcgdGhhdCB5b3UgaGF2ZSBhbiBleGFtcGxlIA0KPj4+IHNlY3Rpb24s IGJ1dCBhIG5vcm1hdGl2ZSBzZWN0aW9uIHdvdWxkIGJlIG1vcmUgZGVzaXJhYmxlLg0KPj4+IA0K Pj4+IDMuIHRoZSBkYXRhIG1vZGVsIHBhcnQgbmVlZHMgc29tZSBtb3JlIHdvcmsuIFRoZSBzdHJ1 Y3R1cmUgaXMgbm90IA0KPj4+IHZlcnkgY2xlYXIgdG8gbWUsIGFuZCBzb21lIG9mIHRoZSBhdHRy aWJ1dGVzIHJlZmVyZW5jZSBvYnNvbGV0ZSBSRkMuIA0KPj4+IEVnLA0KPj4+IFJGQzM4MjUgaXMg cmVmZXJlbmNlZCBmb3IgdGhlIGxvbmdpdHVkZS9sYXRpdHVkZSBhdHRyaWJ1dGVzLiBJIHRoaW5r IA0KPj4+IHlvdSBzaG91bGQgYmUgYmV0dGVyIG9mIHVzaW5nIGFuIGVsZW1lbnQgZm9yIGdlby1s b2NhdGlvbiwgd2l0aCB0aGUgDQo+Pj4gc3RydWN0dXJlIGFzIGRlZmluZWQgaW4gUkZDNTQ5MSwg YSBzZXBhcmF0ZSBlbGVtZW50IGZvciB0aGUgY2l2aWMgDQo+Pj4gbG9jYXRpb24sIHdpdGggdGhl IHN0cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJGQzUxMzksIGV0Yy4gSW5zdGVhZCBvZiANCj4+PiB0 aGUgRGV2aWNlT3duZXIgb2JqZWN0LCBJIHdvdWxkIHVzZSBhIHZDYXJkIGVsZW1lbnQsIHdpdGgg dGhlIA0KPj4+IHN0cnVjdHVyZSBhcyBkZWZpbmVkIGluIFJGQzI0MjYuIFlvdSBtYXkgYWxzbyBu ZWVkIGFuIGlDYWxlbmRhciANCj4+PiBlbGVtZW50IChSRkM1NTQ1KSB0byBzcGVjaWZ5IHRoZSBj aGFubmVsIGF2YWlsYWJpbGl0eSB0aW1lIChlZywgd2hlbiANCj4+PiB0aGUgY2hhbm5lbCBpcyBu b3QgYXZhaWxhYmxlIGZvciB0aGUgZnVsbCAyNEgpLiBFdGMuDQo+Pj4gDQo+Pj4gTW9yZSBjb21t ZW50cyBhcmUgd2VsY29tZS4NCj4+PiAtIEdhYm9yDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIA0KPj4+IFttYWls dG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IERhcywgU3ViaXIgU2Vu dDoNCj4+PiBTYXR1cmRheSwgSnVseSAxNCwgMjAxMiA3OjM2IEFNIFRvOiBwYXdzQGlldGYub3Jn IFN1YmplY3Q6IFtwYXdzXSBGVzoNCj4+PiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KPj4+IA0KPj4+IERlYXIgQ2hhaXJzLA0KPj4+ IFdlIGhhdmUgdXBkYXRlZCBvdXIgZHJhZnQgYW5kIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhIHNs b3QgaW4NCj4+PiBJRVRGLTg0IHRvIHByZXNlbnQgaXQuDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+ PiBfU3ViaXINCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQo+Pj4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDE0LCAyMDEyIA0KPj4+IDEwOjMwIEFNIFRvOiBEYXMs IFN1YmlyIENjOiBqbWFseWFyQHRlbGNvcmRpYS5jb207IA0KPj4+IGQuam9zbHluQHNwZWN0cnVt YnJpZGdlLmNvbSBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+Pj4gZHJh ZnQtZGFzLXBhd3MtcHJvdG9jb2wtIDAyLnR4dA0KPj4+IA0KPj4+IA0KPj4+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQgaGFzIGJlZW4gDQo+Pj4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdWJpciBEYXMgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KPj4+IA0KPj4+IEZpbGVuYW1lOgkgZHJhZnQtZGFzLXBhd3MtcHJvdG9j b2wgUmV2aXNpb246CSAwMiBUaXRsZToJCSBEZXZpY2UgdG8NCj4+PiBEYXRhYmFzZSBQcm90b2Nv bCBmb3IgV2hpdGUgU3BhY2UgQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTQgV0cgSUQ6CQkNCj4+ PiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24gTnVtYmVyIG9mIHBhZ2VzOiAzMiBVUkw6DQo+Pj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wt MDIudHh0DQo+Pj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWRhcy1wYXdzLQ0KPj4+IHByb3RvY29sIEh0bWxpemVkOiAgICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFzLXBhd3MtDQo+Pj4gcHJvdG9jb2wtMDIgRGlm ZjoNCj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWRhcy1wYXdz LXByb3RvY29sLTAyDQo+Pj4gDQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgdGhlIGBQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3BhY2UNCj4+PiAgICBkYXRh YmFzZSAoUEFXUyknIHRoYXQgdXNlcyBIVFRQL1RMUyBhcyB0cmFuc3BvcnQuICBUaGUgcHJvdG9j b2wgaXMNCj4+PiAgICB1c2VkIGZvciByZXRyaWV2aW5nIHRoZSBuZWNlc3NhcnkgVFYgd2hpdGUg c3BhY2UgaW5mb3JtYXRpb24gKGUuZy4sDQo+Pj4gICAgY2hhbm5lbCwgZnJlcXVlbmN5LCB0cmFu c21pdHRlZCBwb3dlcikgYXQgYSBnaXZlbiBsb2NhdGlvbiBhbmQgdGltZQ0KPj4+ICAgIGZyb20g YSBkYXRhYmFzZSB0aGF0IGlzIG9wZXJhdGluZyB1bmRlciBhIHJlZ3VsYXRvcnkgZG9tYWluLiAg VGhlDQo+Pj4gICAgZG9jdW1lbnQgaW5jbHVkZXMgdGhlIHByb3RvY29sIGZ1bmN0aW9uYWxpdGll cywgaXRzIGVsZW1lbnRzLA0KPj4+ICAgIGNvcnJlc3BvbmRpbmcgZGF0YSBtb2RlbCBhbmQgcmVj b21tZW5kcyBpdHMgZW5jb2Rpbmcgc2NoZW1lLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IFRoZSBJ RVRGIFNlY3JldGFyaWF0DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+IHBhd3NAaWV0Zi5vcmcNCj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHBhd3MgbWFpbGlu ZyBsaXN0DQo+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3cw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBwYXdzQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QN Cj4gcGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bhd3MNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= From sdas@appcomsci.com Fri Jul 27 05:33:28 2012 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 8A6CB21F8656 for ; Fri, 27 Jul 2012 05:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.567 X-Spam-Level: X-Spam-Status: No, score=0.567 tagged_above=-999 required=5 tests=[AWL=-1.376, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 qj-V0DkSzFNR for ; Fri, 27 Jul 2012 05:33:27 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1549721F84A0 for ; Fri, 27 Jul 2012 05:33:26 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q6RCXJdL013620; Fri, 27 Jul 2012 08:33:20 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q6RCXJjd018190; Fri, 27 Jul 2012 08:33:19 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Fri, 27 Jul 2012 08:33:18 -0400 From: "Das, Subir" To: Weixinpeng , Peter McCann , Cuiyang , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: comments on draft-das-paws-protocol-02.txt Thread-Index: Ac1nk4lPivKwFP/TTt2ac5kLNzqJlgBFussQAB/KozAAGpqGMABA6hCAABVA+6AALBiIcAAVtPdA Date: Fri, 27 Jul 2012 12:33:17 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F884B1@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DB49@SZXEML508-MBS.china.huawei.com> <8CC0CB0BCAE52F46882E17828A9AE2163684DD31@SZXEML508-MBS.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E18FC3@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.4.1.251] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 12:33:28 -0000 WWVzLCB0aGF0IGlzIHRoZSBjYXNlIGluIG91ciBkcmFmdC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFdlaXhpbnBlbmcgW21haWx0bzp3ZWl4aW5wZW5nQGh1YXdlaS5jb21d IA0KU2VudDogVGh1cnNkYXksIEp1bHkgMjYsIDIwMTIgMTA6MTcgUE0NClRvOiBEYXMsIFN1Ymly OyBQZXRlciBNY0Nhbm47IEN1aXlhbmc7IEdhYm9yLkJhamtvQG5va2lhLmNvbTsgcGF3c0BpZXRm Lm9yZw0KU3ViamVjdDogUkU6IGNvbW1lbnRzIG9uIGRyYWZ0LWRhcy1wYXdzLXByb3RvY29sLTAy LnR4dA0KDQpIaSwNCkkgdGhpbmsgaW4gdGhlIHJlcXVlc3QgbWVzc2FnZSBmcm9tIG1hc3RlciBk ZXZpY2UgdG8gdGhlIGRhdGFiYXNlIFBPU1QgbWV0aG9kIG1heSBiZSBvaywgYnV0IGZvciB0aGUg bWVzc2FnZSB0aGF0IHRoZSBkYXRhYmFzZSByZXNwb25zZXMgdG8gdGhlIG1hc3RlciBkZXZpY2Ug U0hPVUxEIGJlIGEgSFRUUCByZXNwb25zZSBtZXNzYWdlLCBOT1QgYSBQT1NUIG1lc3NhZ2UuDQoN Ci13ZWkNCg0KU0Q+ICBUaGUgZGF0YWJhc2UgcmVzcG9uZHMgdG8gYWxsIHJlcXVlc3RzLiBJbiBv dXIgZXhhbXBsZSwgIHdlIGN1cnJlbnRseSBzaG93IFBBV1MgcHJvdG9jb2wgbWVzc2FnZSAgZGV0 YWlscyB0aGF0IGFyZSBpbmNsdWRlZCBpbiB0aGUgYm9keSBvZiB0aGUgSFRUUCBQT1NULg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhcywgU3ViaXINClNlbnQ6 IFRodXJzZGF5LCBKdWx5IDI2LCAyMDEyIDE6MjYgUE0NClRvOiBQZXRlciBNY0Nhbm47IEN1aXlh bmc7IEdhYm9yLkJhamtvQG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtw YXdzXSBjb21tZW50cyBvbiBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCg0KQW5zd2Vy cyBpbmxpbmUuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGV0ZXIgTWND YW5uIFttYWlsdG86UGV0ZXIuTWNDYW5uQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1 bHkgMjUsIDIwMTIgMzowNCBQTQ0KVG86IEN1aXlhbmc7IERhcywgU3ViaXI7IEdhYm9yLkJhamtv QG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IGNvbW1lbnRzIG9uIGRyYWZ0 LWRhcy1wYXdzLXByb3RvY29sLTAyLnR4dA0KDQpJdCBhbHNvIGFwcGVhcnMgdGhhdCBkcmFmdC1k YXMgcmUtaW1wbGVtZW50cyBIVFRQIERpZ2VzdCBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIsIHJh dGhlciB0aGFuIGF0dGVtcHRpbmcgdG8gdXNlIHN0YW5kYXJkIEhUVFAgRGlnZXN0LiBJIGFtIGN1 cmlvdXMgYXMgdG8gd2h5IHlvdSBtYWRlIHRoaXMgY2hvaWNlLiAgDQoNClNEPiAgVGhpcyBpcyBu b3QgbmV3LiBPdGhlciBJRVRGIHByb3RvY29scyBoYXZlIHVzZWQgdGhpcywgZm9yIGV4YW1wbGUs IA0KU0Q+IFJGQyAzMjYxDQoNCklzIGl0IHNvIHRoYXQgeW91IGNhbiB1cGdyYWRlIHRoZSBoYXNo IGZ1bmN0aW9uIGZyb20gTUQ1IHRvIFNIQS0xPw0KDQpTRD4gSUVURiBkb2VzIG5vdCByZWNvbW1l bmQgIHVzaW5nIE1ENSBhbnltb3JlLiANCg0KQWxzbywgeW91IGRvbid0IHNob3cgdGhlIG1lc3Nh Z2VzIHRoYXQgcmVsYXkgdGhlIG5vbmNlIHZhbHVlIGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xp ZW50LiAgSSB0aGluayB5b3Ugd2lsbCBuZWVkIHRvIHNwZWNpZnkgdGhhdCBtZXNzYWdlIGFzIHdl bGwuICBIVFRQIGRvZXMgdGhpcyB3aXRoIGEgNDAxIFVuYXV0aG9yaXplZCByZXNwb25zZS4NCg0K U0Q+IFRoaXMgaXMgZG9uZSB2aWEgaW5pdGlhbGl6YXRpb24gcmVzcG9uc2UgbWVzc2FnZSwgSU5J VF9SRVNQLiAgUmVtZW1iZXIgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIHBlcmZvcm1lZCBkdXJp bmcgaW5pdGlhbGl6YXRpb24gc3RhZ2UuIFdlIHNob3VsZCBoYXZlIGluY2x1ZGVkIHRoZSBkZXRh aWxzIG9mIElOSVRfUkVRIGFuZCBJTklUX1JFU1AgbWVzc2FnZXMgaW4gZXhhbXBsZSBzZWN0aW9u LiBXaWxsIGluY2x1ZGUgdGhpcyBpbiBuZXh0IHZlcnNpb24uDQoNCkl0IGFsc28gbG9va3MgbGlr ZSB5b3UgYXJlIG5vdCBzZW5kaW5nIGFueSByZXNwb25zZXMgYXQgYWxsIGluIHlvdXIgZXhhbXBs ZXMsIGp1c3QgdXNpbmcgUE9TVCBpbiBib3RoIGRpcmVjdGlvbnMuICBUaGlzIHNlZW1zIHN0cmFu Z2UuDQoNClNEPiAgVGhlIGRhdGFiYXNlIHJlc3BvbmRzIHRvIGFsbCByZXF1ZXN0cy4gSW4gb3Vy IGV4YW1wbGUsICB3ZSBjdXJyZW50bHkgc2hvdyBQQVdTIHByb3RvY29sIG1lc3NhZ2UgIGRldGFp bHMgdGhhdCBhcmUgaW5jbHVkZWQgaW4gdGhlIGJvZHkgb2YgdGhlIEhUVFAgUE9TVC4NCg0KDQpJ dCBtaWdodCBiZSBiZXR0ZXIgdG8gcmVseSBvbiBjbGllbnQgY2VydGlmaWNhdGVzIGF0IHRoZSBU TFMgbGF5ZXIgdG8gYXV0aGVudGljYXRlIHRoZSBtYXN0ZXIgZGV2aWNlLg0KDQpTRD4gV2UgZG8g bm90IGFzc3VtZSB0aGF0IHRoZSBjbGllbnQgaGFzIGNlcnQuIE91ciBleHBlcmllbmNlIHdpdGgg V1NEIG1hbnVmYWN0dXJlcyBpcyB0aGF0IHRoZXkgcHJlZmVyIHRoZSBtb2RlbCBvZiBhIHNoYXJl ZCBzZWNyZXQgZm9yIE1hc3RlciBXU0QgYXV0aGVudGljYXRpb24gdG8gbWFuYWdlIGNvc3RzLg0K DQpGb3IgYXV0aGVudGljYXRpbmcgdGhlIHNsYXZlIGRldmljZXMsIHdlIG1pZ2h0IG5lZWQgc29t ZXRoaW5nIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllci4gIFRoYXQgaXMgYSBzZXBhcmF0ZSBkaXNj dXNzaW9uIHRoYXQgc3RpbGwgbmVlZHMgdG8gaGFwcGVuIChuZWl0aGVyIGRyYWZ0IHJpZ2h0IG5v dyBkZWFscyB3aXRoIGF1dGhlbnRpY2F0aW5nIHRoZSBzbGF2ZSBkZXZpY2UgaWRlbnRpZmllcnMp Lg0KDQpTRD4gT3VyIHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBhdXRoZW50aWNhdGluZyB0aGUgc2xh dmUgZGV2aWNlcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBQQVdTLiBUaGVyZSBpcyBubyBkaXJl Y3QgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHNsYXZlIGRldmljZXMgYW5kIHRoZSBkYXRhYmFzZS4g SG93ZXZlciwgd2UgZG8gc3VwcG9ydCB0aGUgY2FwYWJpbGl0eSBvZiB2YWxpZGF0aW5nIHRoZSBz bGF2ZSBkZXZpY2VzIHZpYSBNU0QuIA0KDQotUGV0ZQ0KDQoNCkN1aXlhbmcgd3JvdGU6IA0KPiBU aGFua3MgZm9yIHlvdXIgYW5zd2Vycy4NCj4gDQo+IEJ1dCB0aGVuIEkgcmVhbGl6ZWQgdGhhdCB0 aGUgcHJvcG9zYWwgaXMgdXNpbmcgYSBraW5kIG9mIHR3by1sYXllciANCj4gYXV0aGVudGljYXRp b24gcHJvdG9jb2xzLCBzLnQuIGFuIG91dGVyIGxheWVyIHByb3RvY29sIG9mIFRMUyANCj4gYXV0 aGVudGljYXRpb24gb2Ygc2VydmVyIChkYXRhYmFzZSksIGFuZCBhbiBpbm5lciBsYXllciBwcm90 b2NvbCANCj4gYXV0aGVudGljYXRpb24gb2YgY2xpZW50IChNYXN0ZXIgZGV2aWNlKS4NCj4gVW5m b3J0dW5hdGVseSwgaXQgaXMga25vd24gdGhhdCBzdWNoIGEgbWl4ZWQgbW9kZSBvZiBhdXRoZW50 aWNhdGlvbiBpcyANCj4gdnVsbmVyYWJsZSB0byBNaXRNLg0KPiBJIGFtIHNlcmlvdXNseSBjb25j ZXJuZWQgdGhhdCB0aGlzIGRyYWZ0IGlzIGFsc28gaW4gdGhlIGNhc2UuDQo+IA0KPiBJbiBwYXJ0 aWN1bGFyLCBzdWNoIGEgY29tYmluYXRpb24gb2YgVExTIG9mIHNlcnZlciBhdXRoZW50aWNhdGlv biBhbmQgDQo+IEhUVFAgZGlnZXN0IGF1dGhlbnRpY2F0aW9uIG9mIGNsaWVudCwgaXMgcmFpc2Vk IGFzIGFuIGluc2VjdXJlIGV4YW1wbGUgDQo+IGluIHNldmVyYWwgcGxhY2VzLCBpbmNsdWRpbmc6 DQo+IC0gUkZDIDQxNjkNCj4gLSBBc29rYW4tTmllbWktTnliZXJnIGF0dGFjayAyMDAyLCBodHRw Oi8vZXByaW50LmlhY3Iub3JnLzIwMDIvMTYzLnBkZg0KPiANCj4gUXVvdGVkIGZyb20gUkZDIDQx NjksIFNlYyA0LjMsIE1hbi1pbi10aGUtTWlkZGxlIEF0dGFjaywNCj4gCSIgRm9yIGV4YW1wbGUs IHRoZSB1c2Ugb2YgVExTIHdpdGggSFRUUCBEaWdlc3QgYXV0aGVudGljYXRpb24gKGkuZS4sDQo+ ICAgIFRMUyBmb3Igc2VydmVyIGF1dGhlbnRpY2F0aW9uLCBhbmQgc3Vic2VxdWVudCB1c2Ugb2Yg SFRUUCBEaWdlc3QgZm9yDQo+ICAgIGNsaWVudCBhdXRoZW50aWNhdGlvbikgaXMgYW4gaW5zdGFu Y2Ugb2Ygc3VjaCBzY2VuYXJpby4gIEhUVFANCj4gICAgY2hhbGxlbmdlcyBhbmQgcmVzcG9uc2Vz IGNhbiBiZSBmZXRjaGVkIGZyb20gYW5kIHRvIGRpZmZlcmVudCBUTFMNCj4gICAgdHVubmVscyB3 aXRob3V0IG5vdGljaW5nIHRoZWlyIG9yaWdpbi4iDQo+IEFsdGhvdWdoIHRoZSBhYm92ZSBhdHRh Y2sgbmVlZHMgc29tZSBjb25kaXRpb25zLCBzdWNoIGEgdXNlIG9mIFRMUyBhbmQgDQo+IEhUVFAg ZGlnZXN0IGRvZXMgbGVhZCB0aGUgcHJvcG9zZWQgcHJvdG9jb2wgdG8gYSBkYW5nZXJvdXMgc2l0 dWF0aW9uLg0KPiBJdCBpcyBtYWlubHkgYmVjYXVzZSwgKGRldGFpbHMgY291bGQgYmUgZm91bmQg aW4gQXNva2FuIGV0IGFsJ3MgcGFwZXIpDQo+IC0gSFRUUCBkaWdlc3QgYXV0aGVudGljYXRpb24g cHJvdG9jb2wgaXMgdG9vIHdlYWsuIEl0IG9ubHkgaGFzIGEgDQo+IGNyeXB0b2dyYXBoaWMgaGFz aCBmdW5jdGlvbiB0byBydW4gYSBvbmUtd2F5IGNvbXB1dGF0aW9uIG9mIHRoZSANCj4gcGFzc3dv cmQsIGxhY2sgb2Ygc2VjcmV0IGtleSBiYXNlZCBvciBwdWJsaWMga2V5IGJhc2VkIHByb3RlY3Rp b24sIA0KPiB1bmxpa2UgVExTLg0KPiAtIFRoZSBzZXNzaW9uIGtleSBpcyBuZWdvdGlhdGVkIGlu IG91dGVyIFRMUyBwcm90b2NvbCBzb2xlbHkuDQo+IC0gVGhlIGlubmVyIHByb3RvY29sIEhUVFAg ZGlnZXN0IGF1dGggZG9lcyBub3QgcmVhbGl6ZSB0aGUgZXhpc3RlbmNlIA0KPiBvZiBvdXRlciBU TFMgcHJvdG9jb2wuDQo+IA0KPiBBIHBvc3NpYmxlIHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbSBt aWdodCBiZSB0byBjcnlwdG9ncmFwaGljYWxseSBiaW5kIA0KPiB0aGUgaW5uZXIgYW5kIG91dGVy IHByb3RvY29sLCBmb3IgZXhhbXBsZSwgdG8gZ2VuZXJhdGUgYSBzZXNzaW9uIGtleSANCj4gZm9y IGlubmVyIHByb3RvY29sLg0KPiBIb3dldmVyLCBIVFRQIGRpZ2VzdCBkb2VzIG5vdCB1c2Ugbm9y IGdlbmVyYXRlIHNlc3Npb24ga2V5Li4uDQo+IEFnYWluLCBJTUhPLCBpdCBzZWVtcyBub3QgYSBn b29kIGlkZWEgdG8gdXNlIEhUVFAgZGlnZXN0IGF1dGggcHJvdG9jb2wgDQo+IGZvciBjbGllbnQg YXV0aGVudGljYXRpb24uIFNvbWUgb3RoZXIgY2FuZGlkYXRlcyBuZWVkIHRvIGJlIGNvbnNpZGVy ZWQuDQo+IA0KPiBBbmQgYWdhaW4sIEkgZmVlbCB0aGF0IGl0IGlzIG5lY2Vzc2FyeSB0byBzZXQg dXAgYW4gaW5kZXBlbmRlbnQgZHJhZnQgDQo+IHRha2luZyBjYXJlIG9mIFBBV1Mgc2VjdXJpdHks IHdoaWNoIG1heSBoZWxwIGRlc2lnbiBhbmQgaW1wbGVtZW50IHRoZSANCj4gUEFXUyBwcm90b2Nv bC4NCj4gSG9wZSB0aGF0IG91ciBkcmFmdCwgZHJhZnQtd3UtcGF3cy1zZWN1dGl0eS0wMCwgY291 bGQgYmUgYSBzdGFydGluZyANCj4gcG9pbnQuIEFueSBjb21tZW50IGlzIHdlbGNvbWUuDQo+IA0K PiBCUiwNCj4gWWFuZw0KPiA9PT09PT09PT09PT09PT09PT0NCj4gIFlhbmcgQ3VpLCAgUGguRC4N Cj4gIEh1YXdlaSBUZWNobm9sb2dpZXMNCj4gIGN1aXlhbmdAaHVhd2VpLmNvbQ0KPiANCj4+IC0t LS0t08q8/tStvP4tLS0tLQ0KPj4gt6K8/sjLOiBEYXMsIFN1YmlyIFttYWlsdG86c2Rhc0BhcHBj b21zY2kuY29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTLE6jfUwjI0yNUgNzo0Ng0KPj4gytW8/sjLOiBD dWl5YW5nOyBHYWJvci5CYWprb0Bub2tpYS5jb207IHBhd3NAaWV0Zi5vcmcNCj4+INb3zOI6IFJF OiBjb21tZW50cyBvbiBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCj4+IA0KPj4gVGhh bmtzIGZvciB5b3VyIGNvbW1lbnRzLiBTb21lIGFuc3dlcnMgaW5saW5lLg0KPj4gDQo+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQo+PiBPZiBDdWl5YW5nDQo+ PiBTZW50OiBNb25kYXksIEp1bHkgMjMsIDIwMTIgODo0NSBBTQ0KPj4gVG86IEdhYm9yLkJhamtv QG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtwYXdzXSBjb21tZW50 cyBvbiBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCj4+IA0KPj4gSGkgQWxsLA0KPj4g DQo+PiBJIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBzb21lIGNvbW1lbnRzIHRvIHRoaXMgZHJhZnQs IGZyb20gYSBzZWN1cml0eSANCj4+IHBvaW50IG9mIHZpZXcuDQo+PiBIb3BlIHRoYXQgaXQgd2ls bCBiZSBoZWxwZnVsLg0KPj4gDQo+PiBUaGUgVExTIGFuZCAiSFRUUCBEaWdlc3QgQXV0aCIgaGF2 ZSBiZWVuIHVzZWQsIGJ1dCBzZWVtIHVuY2xlYXIgZm9yIG1lLg0KPj4gQmVzaWRlcywgaXQgaXMg bm90IHJlY29tbWVuZGVkIHRvIHVzZSB0aGUgbGF0dGVyIGZvciBzb21lIHJlYXNvbnMgDQo+PiBs aXN0ZWQgYmVsb3cuIC0gSXQgaXMgc2FpZCB0aGF0IHRoZSBIVFRQL1RMUyBwcm90b2NvbCBpcyBk ZXBsb3llZCBmb3IgDQo+PiBtdXR1YWwgYXV0aGVudGljYXRpb24uDQo+PiANCj4+IFNEPiBUaGlz IGlzIG5vdCBjb3JyZWN0Lg0KPj4gDQo+PiBIb3dldmVyLCAiSFRUUCBkaWdlc3QgYXV0aGVudGlj YXRpb24iIGlzIGFjdHVhbGx5IHVzZWQgZm9yIA0KPj4gYXV0aGVudGljYXRpbmcgdGhlIGRldmlj ZSwNCj4+IA0KPj4gU0Q+ICBEaWdlc3QgQXV0aGVudGljYXRpb24gaXMgdXNlZCB0byBhdXRoZW50 aWNhdGUgdGhlIGNsaWVudCBhdCB0aGUgDQo+PiBTRD4gUEFXUw0KPj4gbGF5ZXIuDQo+PiANCj4+ IHdoaWNoIGlzIHR5cGljYWxseSB3ZWFrZXIgdGhhbiBub3JtYWwgVExTLg0KPj4gDQo+PiBTRD4g V2h5IGlzIGl0IHdlYWtlcj8NCj4+IA0KPj4gT25seSB0aGUgc2VydmVyIHNpZGUgYXV0aGVudGlj YXRpb24gaXMgcGVyZm9ybWVkIGJ5IFRMUyANCj4+IGNlcnRpZmljYXRlLWJhc2VkIGNyeXB0byBt ZXRob2QuDQo+PiAtIEl0IGFwcGVhcnMgdGhhdCBhdXRoZW50aWNhdGlvbiBpcyBkb25lIGluIGRp ZmZlcmVudCBsYXllcnMsIGkuZS4sIA0KPj4gZGV2aWNlIGlzIGRvbmUgaW4gUEFXUyBsYXllciBi eSAiSFRUUCBkaWdlc3QgYXV0aCIgYW5kIHNlcnZlciBpcyANCj4+IGFjaGlldmVkIGluIFRMUyBs YXllciBieSBjZXJ0aWZpY2F0ZS4NCj4+IA0KPj4gU0Q+IFllcywgYXV0aGVudGljYXRpb24gaXMg ZG9uZSBhdCB0aGUgUEFXUyBsYXllciBieSB1c2luZyBkaWdlc3QNCj4+IGF1dGhlbnRpY2F0aW9u Lg0KPj4gDQo+PiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSBzZWN1cml0eSBpcyBkb25lIGluIG1p eGVkIGxheWVycz8NCj4+IA0KPj4gLSBJdCBpcyBzYWlkIHRoYXQgY29uZmlkZW50aWFsaXR5IGlz IHByb3RlY3RlZCBpbiBIVFRQUyBsYXllciwgYnV0IGlmIA0KPj4gYXV0aGVudGljYXRpbmcgZGV2 aWNlIGlzIGFjaGlldmVkIGluIGRpZmZlcmVudCBsYXllciAoaS5lLiBpbiBQQVdTIA0KPj4gbGF5 ZXIpLCBob3cgY2FuIHRoZSBkZXZpY2UgYW5kIHNlcnZlciBuZWdvdGlhdGUgdGhlIHNlc3Npb24g a2V5Pw0KPj4gDQo+PiBTRD4gRHVyaW5nIG5vcm1hbCBUTFMgbmVnb3RpYXRpb24uDQo+PiANCj4+ IC0gT3IsIGlmIG15IGFib3ZlIHVuZGVyc3RhbmRpbmcgaXMgd3JvbmcgYW5kIG11dHVhbCBhdXRo ZW50aWNhdGlvbiBpcyANCj4+IGluZGVlZCBkb25lIGluIFRMUyBsYXllciwgd2h5IGRvZXMgaXQg bmVlZCB0byBoYXZlIGFkZGl0aW9uYWwgIkhUVFAgDQo+PiBkaWdlc3QgYXV0aCIgaW4gUEFXUyBs YXllcj8NCj4+IA0KPj4gU0Q+IE9ubHkgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgYXQg dGhlIFBBV1MgbGF5ZXIuIE9mIGNvdXJzZSANCj4+IFNEPiBjbGllbnQNCj4+IGF1dGggY2FuIGJl IGRvbmUgYXQgdGhlIFRMUyBsYXllci4gVGhlbiBvbmUgbmVlZHMgdG8gaGF2ZSBjaGFubmVsIA0K Pj4gYmluZGluZyBhbmQgdGhhdCdzIGFub3RoZXIgYXBwcm9hY2guDQo+PiANCj4+IC0gIkhUVFAg ZGlnZXN0IGF1dGgiIG9ubHkgcHJvdmlkZXMgYSBoYXNoLWJhc2VkIHByb3RlY3Rpb24gZm9yIA0K Pj4gc2VjcmV0cyBsaWtlIHBhc3N3b3JkIGFuZCBJRCwgYW5kIGlzIGtub3duIHRvIGJlIHZ1bG5l cmFibGUgdG8gTWl0TQ0KPj4gKE1hbi1pbi10aGUtTWlkZGxlKSBhdHRhY2tzLiBTaW5jZSBhY2Nv cmRpbmcgdG8gdGhlIFBBV1MgV0cgZG9jdW1lbnQsIA0KPj4gZHJhZnQtaWV0Zi1wYXdzLXByb2Js ZW0tc3RtdC11c2VjYXNlcy1ycW10cy0wNiwgQ2hhcHRlciA4LCB0aHJlYXQgNywgDQo+PiBNaXRN IGF0dGFjayBzaG91bGQgYmUgdGh3YXJ0ZWQuIFRoaXMgZHJhZnQgdXNpbmcgIkhUVFAgZGlnZXN0 IGF1dGgiDQo+PiBvYnZpb3VzbHkgZG9lcyBub3Qgc2F0aXNmeSB0aGUgc2VjdXJpdHkgcmVxdWly ZW1lbnQuDQo+PiANCj4+IFNEPiAgSSBkbyBub3QgdW5kZXJzdGFuZCB0aGlzLiBIVFRQL1RMUyBp cyB1c2VkIGluIG91ciBzY2hlbWUuDQo+PiANCj4+IC0gIkhUVFAgZGlnZXN0IGF1dGgiIGRpZmZl cnMgZnJvbSBIVFRQIG92ZXIgVExTLCB3aGVyZSB0aGUgZm9ybWVyIA0KPj4gcHJvdmlkZXMgbm8g ZW5jcnlwdGlvbiBmb3IgY29udGVudCwgYnV0IHRoZSBsYXR0ZXIgY2FuIGVuY3J5cHQgdGhlIA0K Pj4gY29udGVudCBieSBQdWJsaWMgS2V5IGNyeXB0by4gVGh1cyBUTFMgaXMgcHJlZmVycmVkLiAt ICJIVFRQIGRpZ2VzdCANCj4+IGF1dGgiIGRvZXMgbm90IHN1cHBvcnQgSE1BQyBhbGdvcml0aG0g KHNvLWNhbGxlZCBLZXllZCBIYXNoKSwgdGh1cyBpdCANCj4+IGlzIHlldCBhIGxpdHRsZSByaXNr eSB0byB1c2UgU0hBLTEgdG8gcmVwbGFjZSBjdXJyZW50IE1ENSBhbGdvcml0aG0sIA0KPj4gYmVj YXVzZSBOSVNUIGhhcyBub3QgcmVjb21tZW5kZWQgdG8gdXNlIHRoZSBjb2xsaXNpb24gcmVzaXN0 YW5jZSBvZg0KPj4gU0hBLTEgKGJ1dCBITUFDLVNIQTEgaXMgZmluZSkuIEluIGNvbnRyYXN0LCBU TFMgc3VwcG9ydHMgSE1BQyBhbmQgDQo+PiBkb2VzIG5vdCBoYXZlIHN1Y2ggYSBwcm9ibGVtLg0K Pj4gDQo+PiBTRD4gWWVzIGl0IHNob3VsZCBiZSBITUFDLVNIQTEuDQo+PiANCj4+IEZyb20gdGhl IGFib3ZlIGFuYWx5c2lzLCBpdCBpcyBjbGVhciB0byBzZWUgdGhhdCB0aGUgc2VjdXJpdHkgYW5k IA0KPj4gcHJpdmFjeSBvZiBQQVdTIGlzIG5vdCBzdHJhaWdodGZvcndhcmQgYW5kIG5lZWRzIHRv IGJlIGNhcmVmdWxseSANCj4+IGludmVzdGlnYXRlZCwgZm9yIGRlc2lnbiBhbmQgaW1wbGVtZW50 YXRpb24uDQo+PiBJdCBpcyBhbHNvIHRoZSByZWFzb24gd2h5IHdlIGhhdmUgc3VibWl0dGVkIGFu IGluZGVwZW5kZW50IGRyYWZ0IGZvciANCj4+IFBBV1Mgc2VjdXJpdHksIHRvIHByb3ZpZGUgYSBi YXNlIGZvciBkaXNjdXNzaW9uLg0KPj4gDQo+PiBCUiwNCj4+IFlhbmcNCj4+ID09PT09PT09PT09 PT09PT09PQ0KPj4gIFlhbmcgQ3VpLCAgUGguRC4NCj4+ICBIdWF3ZWkgVGVjaG5vbG9naWVzDQo+ PiAgY3VpeWFuZ0BodWF3ZWkuY29tDQo+PiANCj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+PiC3 orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9y Z10gtPqx7Q0KPj4+IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPj4+ILeiy83KsbzkOiAyMDEyxOo3 1MIyMsjVIDc6MzENCj4+PiDK1bz+yMs6IHBhd3NAaWV0Zi5vcmcNCj4+PiDW98ziOiBbcGF3c10g Y29tbWVudHMgb24gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtMDIudHh0DQo+Pj4gDQo+Pj4gSXQg d291bGQgYmUgYmVuZWZpY2lhbCBpZiB0aGVyZSB3ZXJlIGRpc2N1c3Npb25zIG9uIHRoZSBkcmFm dHMgdG8gDQo+Pj4gc3VibWl0dGVkIGFoZWFkIG9mIHRoZSBGMkYgcHJlc2VudGF0aW9ucy4NCj4+ PiBUaHVzLCBJJ3ZlIHRha2VuIHRoZSBpbml0aWF0aXZlIHRvIHJlYWQgdGhlIGRyYWZ0IGFuZCBw cm92aWRlIHNvbWUgDQo+Pj4gaW5pdGlhbA0KPj4+IGNvbW1lbnRzOg0KPj4+IA0KPj4+IDEuIEkg ZG8gbm90IHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhlIGluaXRpYWxpemF0aW9uIHByb2Nl c3MgYW5kIA0KPj4+IHdoeSBtZXNzYWdlcyBJTlQtUkVRIGFuZCBJTlQtUkVTUCBhcmUgbmVjZXNz YXJ5LiBUaGUgY2FwYWJpbGl0eSANCj4+PiBleGNoYW5nZSBjYW4gYmUgZG9uZSBkdXJpbmcgdGhl IHJlZ2lzdHJhdGlvbiBwcm9jZXNzLiBXZSBtYXkgZXZlbiANCj4+PiBjb25zaWRlciBtZXJnaW5n IHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyB3aXRoIHRoZSBEQiBxdWVyeSBwcm9jZXNzLCANCj4+ PiB0aGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgYW55IHJlYXNvbiB0byBoYXZlIHRoZW0gYXMgc2Vw YXJhdGUgbWVzc2FnZXMuDQo+Pj4gDQo+Pj4gMi4geW91IG1heSBuZWVkIGEgc2VjdGlvbiB3aGVy ZSB5b3UgbWFwIHlvdXIgbmV3bHkgZGVmaW5lZCBtZXNzYWdlcyANCj4+PiB0byBleGlzdGluZyBo dHRwIHByb3RvY29sIG1lc3NhZ2VzLiBJIHNhdyB0aGF0IHlvdSBoYXZlIGFuIGV4YW1wbGUgDQo+ Pj4gc2VjdGlvbiwgYnV0IGEgbm9ybWF0aXZlIHNlY3Rpb24gd291bGQgYmUgbW9yZSBkZXNpcmFi bGUuDQo+Pj4gDQo+Pj4gMy4gdGhlIGRhdGEgbW9kZWwgcGFydCBuZWVkcyBzb21lIG1vcmUgd29y ay4gVGhlIHN0cnVjdHVyZSBpcyBub3QgDQo+Pj4gdmVyeSBjbGVhciB0byBtZSwgYW5kIHNvbWUg b2YgdGhlIGF0dHJpYnV0ZXMgcmVmZXJlbmNlIG9ic29sZXRlIFJGQy4NCj4+PiBFZywNCj4+PiBS RkMzODI1IGlzIHJlZmVyZW5jZWQgZm9yIHRoZSBsb25naXR1ZGUvbGF0aXR1ZGUgYXR0cmlidXRl cy4gSSB0aGluayANCj4+PiB5b3Ugc2hvdWxkIGJlIGJldHRlciBvZiB1c2luZyBhbiBlbGVtZW50 IGZvciBnZW8tbG9jYXRpb24sIHdpdGggdGhlIA0KPj4+IHN0cnVjdHVyZSBhcyBkZWZpbmVkIGlu IFJGQzU0OTEsIGEgc2VwYXJhdGUgZWxlbWVudCBmb3IgdGhlIGNpdmljIA0KPj4+IGxvY2F0aW9u LCB3aXRoIHRoZSBzdHJ1Y3R1cmUgYXMgZGVmaW5lZCBpbiBSRkM1MTM5LCBldGMuIEluc3RlYWQg b2YgDQo+Pj4gdGhlIERldmljZU93bmVyIG9iamVjdCwgSSB3b3VsZCB1c2UgYSB2Q2FyZCBlbGVt ZW50LCB3aXRoIHRoZSANCj4+PiBzdHJ1Y3R1cmUgYXMgZGVmaW5lZCBpbiBSRkMyNDI2LiBZb3Ug bWF5IGFsc28gbmVlZCBhbiBpQ2FsZW5kYXIgDQo+Pj4gZWxlbWVudCAoUkZDNTU0NSkgdG8gc3Bl Y2lmeSB0aGUgY2hhbm5lbCBhdmFpbGFiaWxpdHkgdGltZSAoZWcsIHdoZW4gDQo+Pj4gdGhlIGNo YW5uZWwgaXMgbm90IGF2YWlsYWJsZSBmb3IgdGhlIGZ1bGwgMjRIKS4gRXRjLg0KPj4+IA0KPj4+ IE1vcmUgY29tbWVudHMgYXJlIHdlbGNvbWUuDQo+Pj4gLSBHYWJvcg0KPj4+IA0KPj4+IA0KPj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyAN Cj4+PiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBEYXMs IFN1YmlyIFNlbnQ6DQo+Pj4gU2F0dXJkYXksIEp1bHkgMTQsIDIwMTIgNzozNiBBTSBUbzogcGF3 c0BpZXRmLm9yZyBTdWJqZWN0OiBbcGF3c10gRlc6DQo+Pj4gTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQNCj4+PiANCj4+PiBEZWFyIENo YWlycywNCj4+PiBXZSBoYXZlIHVwZGF0ZWQgb3VyIGRyYWZ0IGFuZCB3b3VsZCBsaWtlIHRvIHJl cXVlc3QgYSBzbG90IGluDQo+Pj4gSUVURi04NCB0byBwcmVzZW50IGl0Lg0KPj4+IA0KPj4+IFJl Z2FyZHMsDQo+Pj4gX1N1YmlyDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIA0KPj4+IFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXSBTZW50OiBTYXR1cmRheSwgSnVseSAxNCwgMjAxMg0KPj4+IDEwOjMwIEFN IFRvOiBEYXMsIFN1YmlyIENjOiBqbWFseWFyQHRlbGNvcmRpYS5jb207IA0KPj4+IGQuam9zbHlu QHNwZWN0cnVtYnJpZGdlLmNvbSBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y DQo+Pj4gZHJhZnQtZGFzLXBhd3MtcHJvdG9jb2wtIDAyLnR4dA0KPj4+IA0KPj4+IA0KPj4+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kYXMtcGF3cy1wcm90b2NvbC0wMi50eHQgaGFzIGJl ZW4gDQo+Pj4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdWJpciBEYXMgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPj4+IA0KPj4+IEZpbGVuYW1lOgkgZHJhZnQtZGFzLXBh d3MtcHJvdG9jb2wgUmV2aXNpb246CSAwMiBUaXRsZToJCSBEZXZpY2UgdG8NCj4+PiBEYXRhYmFz ZSBQcm90b2NvbCBmb3IgV2hpdGUgU3BhY2UgQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTQgV0cg SUQ6CQkNCj4+PiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24gTnVtYmVyIG9mIHBhZ2VzOiAzMiBVUkw6 DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGFzLXBhd3Mt cHJvdG9jb2wtMDIudHh0DQo+Pj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWRhcy1wYXdzLQ0KPj4+IHByb3RvY29sIEh0bWxpemVkOiAgICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGFzLXBhd3MtDQo+Pj4gcHJvdG9j b2wtMDIgRGlmZjoNCj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWRhcy1wYXdzLXByb3RvY29sLTAyDQo+Pj4gDQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgdGhlIGBQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3BhY2UNCj4+ PiAgICBkYXRhYmFzZSAoUEFXUyknIHRoYXQgdXNlcyBIVFRQL1RMUyBhcyB0cmFuc3BvcnQuICBU aGUgcHJvdG9jb2wgaXMNCj4+PiAgICB1c2VkIGZvciByZXRyaWV2aW5nIHRoZSBuZWNlc3Nhcnkg VFYgd2hpdGUgc3BhY2UgaW5mb3JtYXRpb24gKGUuZy4sDQo+Pj4gICAgY2hhbm5lbCwgZnJlcXVl bmN5LCB0cmFuc21pdHRlZCBwb3dlcikgYXQgYSBnaXZlbiBsb2NhdGlvbiBhbmQgdGltZQ0KPj4+ ICAgIGZyb20gYSBkYXRhYmFzZSB0aGF0IGlzIG9wZXJhdGluZyB1bmRlciBhIHJlZ3VsYXRvcnkg ZG9tYWluLiAgVGhlDQo+Pj4gICAgZG9jdW1lbnQgaW5jbHVkZXMgdGhlIHByb3RvY29sIGZ1bmN0 aW9uYWxpdGllcywgaXRzIGVsZW1lbnRzLA0KPj4+ICAgIGNvcnJlc3BvbmRpbmcgZGF0YSBtb2Rl bCBhbmQgcmVjb21tZW5kcyBpdHMgZW5jb2Rpbmcgc2NoZW1lLg0KPj4+IA0KPj4+IA0KPj4+IA0K Pj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+IHBhd3NAaWV0 Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHBh d3MgbWFpbGluZyBsaXN0DQo+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBwYXdzQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBtYWls aW5nIGxpc3QNCj4gcGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Bhd3MNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= From Gabor.Bajko@nokia.com Fri Jul 27 11:23:24 2012 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 DACD611E808C for ; Fri, 27 Jul 2012 11:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFJQmiMyIlm2 for ; Fri, 27 Jul 2012 11:23:23 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8AE11E80EA for ; Fri, 27 Jul 2012 11:23:22 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6RINJa9019553 for ; Fri, 27 Jul 2012 21:23:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 21:24:02 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Fri, 27 Jul 2012 20:23:18 +0200 From: To: Thread-Topic: remote participation to the Vancouver F2F Thread-Index: Ac1lO3cYBZdmcJnuRGaTYBWlOBkrUQG5TpWw Date: Fri, 27 Jul 2012 18:23:18 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F9B38F@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F84925@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F84925@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.117.150] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F9B38F008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2012 18:24:03.0073 (UTC) FILETIME=[FFDA4710:01CD6C24] X-Nokia-AV: Clean Subject: Re: [paws] remote participation to the Vancouver F2F 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, 27 Jul 2012 18:23:25 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F9B38F008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you are interested in participating remotely to the PAWS session on Mond= ay, go to http://www.meetecho.com/ietf84/paws for video and file sharing, a= nd connect to skype id ietf.paws for audio (do so 5 min before the session = start). - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Wednesday, July 18, 2012 4:21 PM To: paws@ietf.org Subject: [paws] remote participation to the Vancouver F2F Some people contacted me offline to ask about the remote participation poss= ibilities for the PAWS session at the Vancouver F2F on Monday, July 30th, 1= 5:40 to 17:10 pm PST. I requested support from the Meetecho team for video broadcast and presenta= tion sharing, while voice will be provided by Skype. Once details are avail= able, I'll forward it to the list. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F9B38F008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are interested = in participating remotely to the PAWS session on Monday, go to http://www.meetecho.com/iet= f84/paws for video and file sharing, and connect to skype id ietf.paws = for audio (do so 5 min before the session start).

-&nb= sp;         Gabor

 

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Wednesday, July 18, 2012 4:21 PM
To: paws@ietf.org
Subject: [paws] remote participation to the Vancouver F2F=

 

Some people contacted me offline to ask about the re= mote participation possibilities for the PAWS session at the Vancouver F2F = on Monday, July 30th, 15:40 to 17:10 pm PST.

 

I requested support from the Meetecho team for video= broadcast and presentation sharing, while voice will be provided by Skype.= Once details are available, I’ll forward it to the list.<= /p>

 

-     &= nbsp;    Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F9B38F008AM1MPN1006mg_-- From ericchu@google.com Sun Jul 29 17:48:13 2012 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 70C0521F85C4 for ; Sun, 29 Jul 2012 17:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HADmjrzt-llr for ; Sun, 29 Jul 2012 17:48:12 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D166021F85C3 for ; Sun, 29 Jul 2012 17:48:12 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8830415pbc.31 for ; Sun, 29 Jul 2012 17:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; bh=v8WW+r/V+tNGiMpmBVzoGZGLP6FlfH+3BZpqMDT92PA=; b=IRHcffhNRGDr76HaM4F599Ae5ctTUEeuW04sEisp7oM2EncTxvwxVAaej459HbsSNP QYVSEYCxJbYIVFhHfMjwFrISQMaxM5K7uODI1YMMs6eLSzhEukGZR+oqQhCVnHDTQOpt 5iHpxKbyHn52HmHj9V/k+C7u9W0CA+5Q6OB8OyfC8Jn+XJKGKxvyuWPaosRvPD2mkQqp CGCHhBohqV6LNfkkuEkQD4hhh4OwDFvne782aoIyeRRGKTh3UzmS7RRVxcpHNtu/WCiD SnW4Bx4D7q84VlQmOhV1LeRziQcUG5ROmEg1jPPKRbk6kyMn0K/w191FekDItlKAqYuZ /7wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:x-gm-message-state; bh=v8WW+r/V+tNGiMpmBVzoGZGLP6FlfH+3BZpqMDT92PA=; b=gsPMryGThT2/xJ+PDqlg8dDJwxNbOOGPk/Z51lJF2QXSre+32n3WCuo8LBPJnq5gq0 FgzdfonjmDaABnBqCDNLa3Nz2O4iDnosdxe1GMOi9RCIcFc4Zm4BJtJcwUD9z8ILNpu0 y5rd6C6LMcCmPsH11M2RZTaRh3wVmwtYwTYst5dfG9JWl1Ha/r2aTyi1HuLZ8cIt20Xp 0yvVdU7KEdXUT7WFnJyXNWPrvmyj73oCPCr0VSRYiQqQTk6o1hRkNRIAc/s5wTthJmu+ Jkx/iNecmNbt9vgzO4XvbwavWIfpMfypLGTIFQ4XlQoVW+FSDPkytK19zNgsCdVeBsGD fbvQ== Received: by 10.68.138.169 with SMTP id qr9mr31153552pbb.27.1343609292556; Sun, 29 Jul 2012 17:48:12 -0700 (PDT) Received: by 10.68.138.169 with SMTP id qr9mr31153540pbb.27.1343609292394; Sun, 29 Jul 2012 17:48:12 -0700 (PDT) Received: from ericchu-macbookair.local (S0106001e2ade4f01.vc.shawcable.net. [24.84.59.161]) by mx.google.com with ESMTPS id oo6sm6729560pbc.22.2012.07.29.17.48.11 (version=SSLv3 cipher=OTHER); Sun, 29 Jul 2012 17:48:11 -0700 (PDT) Message-ID: <5015D9CF.1090002@google.com> Date: Sun, 29 Jul 2012 17:48:15 -0700 From: Eric Chu User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com Content-Type: multipart/alternative; boundary="------------070302090604070109070704" X-Gm-Message-State: ALoCoQm9ko0VWTX826trtjcjskrsthds1rKvqqjr2fXDb0CSuGjqjHOGGdcf1hrq+7WfIB/yI/Tt4Iw2yYn5M4T6WtsxuMYNbmIlWCLfwHtZv7jTaL4SPudXMDVNv4b/YMt5zZ1LnzvghsWjUPWsxy9ImIw4sHtrYH86WPMArVCQpvtZi1bhWZs= X-Mailman-Approved-At: Sun, 29 Jul 2012 22:08:33 -0700 Cc: paws@ietf.org Subject: [paws] A couple of clarifications to requirement doc? 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, 30 Jul 2012 00:48:13 -0000 This is a multi-part message in MIME format. --------------070302090604070109070704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gabor, Apologize for the late "entry" but we would like to suggest a couple of minor but important clarifications to current requirement doc to minimize potential confusions: * The final spec should be general enough to support all spectrum. Not just TV spectrum. In our discussions with several PAWS members, they all agree with this point but they point to the requirement doc as the limiting factor to generalize the spec. For example in the Normative Requirements section 6.1 D7 " *The Data Model MUST support specifying a list of availablechannels. The Data Model MUST support specification of thisinformation by channel numbers and...."* * Both FCC and Ofcom do not require "authentication of device". While the FCC requires the DB to check for "authorized" FCCID, device authentication is not required. Current requirement doc requires the database to "authenticate" the master device as stated in the Normative Requirements section 6.1 P.4 " *The protocol MUST provide the ability for the database toauthenticate the master device.". *To be consistent with FCC and Ofcom spec, we believe the spec should allow for the implementation of strong authentication as an option. Appreciate your thoughts on what's the best process to consider these refinements. If there's consensus, Google is more than happy to take on the work of providing specific text changes. Thanks Eric --------------070302090604070109070704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Gabor,

Apologize for the late "entry" but we would like to suggest a couple of minor but important clarifications to current requirement doc to minimize potential confusions:
  • The final spec should be general enough to support all spectrum.  Not just TV spectrum.  In our discussions with several PAWS members, they all agree with this point but they point to the requirement doc as the limiting factor to generalize the spec.  For example in the Normative Requirements section 6.1 D7   " The Data Model MUST support specifying a list of available channels.  The Data Model MUST support specification of this information by channel numbers and...."
  • Both FCC and Ofcom do not require "authentication of device".  While the FCC requires the DB to check for "authorized" FCCID, device authentication is not required.  Current requirement doc requires the database to "authenticate" the master device as stated in the Normative Requirements section 6.1 P.4 " The protocol MUST provide the ability for the database to authenticate the master device.". To be consistent with FCC and Ofcom spec, we believe the spec should allow for the implementation of strong authentication as an option.

Appreciate your thoughts on what's the best process to consider these refinements.  If there's consensus, Google is more than happy to take on the work of providing specific text changes.

Thanks
Eric





--------------070302090604070109070704-- From andy.sago@bt.com Mon Jul 30 02:30:01 2012 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 43B2D21F84A1 for ; Mon, 30 Jul 2012 02:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=0.188, 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 XsjE0P19CE2r for ; Mon, 30 Jul 2012 02:29:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7602521F8732 for ; Mon, 30 Jul 2012 02:29:58 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 30 Jul 2012 10:29:57 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.113]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 30 Jul 2012 10:29:57 +0100 From: To: , Date: Mon, 30 Jul 2012 10:29:55 +0100 Thread-Topic: [paws] A couple of clarifications to requirement doc? Thread-Index: Ac1uEWCUVoIEWKzqTtW0RauqwWKDDQAHarvQ Message-ID: <619CDADDCCD2B44380834BE8BF6F714140A9E2060E@EMV62-UKRD.domain1.systemhost.net> References: <5015D9CF.1090002@google.com> In-Reply-To: <5015D9CF.1090002@google.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F714140A9E2060EEMV62UKRDdoma_" MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] A couple of clarifications to requirement doc? 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, 30 Jul 2012 09:30:01 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140A9E2060EEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric Thanks very much for your comments. The intent of the requirements spec is = to cover all spectrum, but of course we only have two sets of inputs from r= egulatory bodies at present and they both relate to TV spectrum. The actual= Ofcom language refers to "a list of lower and upper frequency boundaries"= which is more flexible than using channels, but this is covered in the req= uirement D.7 that you quoted, as the next sentence says "The Data Model MUS= T support specification of this information by channel numbers and by start= and stop frequencies.". So, although we could continue to refine the langu= age in the PAWS requirements with regard to channels, personally I'm OK wit= h the document and I don't see this as an area where we need to spend furth= er effort. On your second point, in general I think we demand a lot of our regulators = if we expect them to have a full understanding of security threats and reme= dies, therefore we need to allow the PAWS protocol to include necessary sec= urity even if regulators were a bit vague. I interpret "...the protocol MUS= T provide the ability for..." in P.4 and elsewhere as allowing PAWS to impl= ement best practice with regard to security (authentication/authorisation/e= ncryption/whatever), and I trust the PAWS participants not to make this unn= ecessarily onerous. Clearly neither will we be writing a protocol that is f= ull of security holes. In this regard I don't have any problem with the req= uirements as written, as this is all sorted out in the next stage. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Eri= c Chu Sent: 30 July 2012 01:48 To: Gabor.Bajko@nokia.com Cc: paws@ietf.org Subject: [paws] A couple of clarifications to requirement doc? Hi Gabor, Apologize for the late "entry" but we would like to suggest a couple of min= or but important clarifications to current requirement doc to minimize pote= ntial confusions: * The final spec should be general enough to support all spectrum. Not = just TV spectrum. In our discussions with several PAWS members, they all a= gree with this point but they point to the requirement doc as the limiting = factor to generalize the spec. For example in the Normative Requirements s= ection 6.1 D7 " The Data Model MUST support specifying a list of availabl= e channels. The Data Model MUST support specification of this information = by channel numbers and...." * Both FCC and Ofcom do not require "authentication of device". While t= he FCC requires the DB to check for "authorized" FCCID, device authenticati= on is not required. Current requirement doc requires the database to "auth= enticate" the master device as stated in the Normative Requirements section= 6.1 P.4 " The protocol MUST provide the ability for the database to authen= ticate the master device.". To be consistent with FCC and Ofcom spec, we be= lieve the spec should allow for the implementation of strong authentication= as an option. Appreciate your thoughts on what's the best process to consider these refin= ements. If there's consensus, Google is more than happy to take on the wor= k of providing specific text changes. Thanks Eric --_000_619CDADDCCD2B44380834BE8BF6F714140A9E2060EEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Eric<= /o:p>

 

Thanks ve= ry much for your comments. The intent of the requirements spec is to cover = all spectrum, but of course we only have two sets of inputs from regulatory= bodies at present and they both relate to TV spectrum. The actual Ofcom la= nguage refers to  “a list of lower and upper frequency boundarie= s” which is more flexible than using channels, but this is covered in= the requirement D.7 that you quoted, as the next sentence says “The = Data Model MUST support specification of this information by channel number= s and by start and stop frequencies.”. So, although we could continue= to refine the language in the PAWS requirements with regard to channels, p= ersonally I’m OK with the document and I don’t see this as an a= rea where we need to spend further effort.

=  

On your second point, in general I t= hink we demand a lot of our regulators if we expect them to have a full und= erstanding of security threats and remedies, therefore we need to allow the= PAWS protocol to include necessary security even if regulators were a bit = vague. I interpret “…the protocol MUST provide the ability for&= #8230;” in P.4 and elsewhere as allowing PAWS to implement best pract= ice with regard to security (authentication/authorisation/encryption/whatev= er), and I trust the PAWS participants not to make this unnecessarily onero= us. Clearly neither will we be writing a protocol that is full of security = holes. In this regard I don’t have any problem with the requirements = as written, as this is all sorted out in the next stage.<= /p>

 

Regards

 

Andy

 

 

Fr= om: paws-bounces@ietf.org [mailto:paws-bou= nces@ietf.org] On Behalf Of Eric Chu
Sent: 30 July 2012 01= :48
To: Gabor.Bajko@nokia.com
Cc: paws@ietf.org
S= ubject: [paws] A couple of clarifications to requirement doc?

 


Hi Gabor,

Apologize for the late "entry" = but we would like to suggest a couple of minor but important clarifications= to current requirement doc to minimize potential confusions:

  • The final spec should be g= eneral enough to support all spectrum.  Not just TV spectrum.  In= our discussions with several PAWS members, they all agree with this point = but they point to the requirement doc as the limiting factor to generalize = the spec.  For example in the Normative Requirements section 6.1 D7 &n= bsp; " The = Data Model MUST support specifying a list of available channels.  The = Data Model MUST support specification of this information by channel number= s and...."
  • Both FCC and Ofcom do not require "authentication of d= evice".  While the FCC requires the DB to check for "authori= zed" FCCID, device authentication is not required.  Current requi= rement doc requires the database to "authenticate" the master dev= ice as stated in the Normative Requirements section 6.1 P.4 " The protocol MUST provid= e the ability for the database to authenticate the master device.". To be consistent with FCC and Ofcom spec, we believe the spec should a= llow for the implementation of strong authentication as an option.

Appreciate your thoughts on what's the best process to consi= der these refinements.  If there's consensus, Google is more than happ= y to take on the work of providing specific text changes.

= Thanks
Eric

 

 

 

= --_000_619CDADDCCD2B44380834BE8BF6F714140A9E2060EEMV62UKRDdoma_-- From scott.probasco@nokia.com Mon Jul 30 09:15:31 2012 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 EEFBA21F85DD for ; Mon, 30 Jul 2012 09:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.127, 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 jiZl3aVGtigj for ; Mon, 30 Jul 2012 09:15:29 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 875BA21F85D9 for ; Mon, 30 Jul 2012 09:15:29 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6UGFOCr027146 for ; Mon, 30 Jul 2012 19:15:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jul 2012 19:16:12 +0300 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.192]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Mon, 30 Jul 2012 18:15:25 +0200 From: To: Thread-Topic: [paws] A couple of clarifications to requirement doc? Thread-Index: AQHNbhFiuFMiSMTqwUy5X/3JSScmd5dBbhiAgAAdp4A= Date: Mon, 30 Jul 2012 16:15:24 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140A9E2060E@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [172.19.40.94] Content-Type: multipart/alternative; boundary="_000_CC3C1791DFC4scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2012 16:16:12.0115 (UTC) FILETIME=[A2D83A30:01CD6E6E] X-Nokia-AV: Clean Subject: Re: [paws] A couple of clarifications to requirement doc? 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, 30 Jul 2012 16:15:31 -0000 --_000_CC3C1791DFC4scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, In development of the Use Cases & Requirements, as a group we have discusse= d this many times and always concluded that PAWS is not specific to TV band= s, although TV bands will be first taken into use. I believe requirement D.= 7 is flexible and does not limit PAWS to TV frequencies. By stating that th= e data model must support channel numbers AND frequency definitions, this d= oes not mean that both must be used at the same time, only that the data mo= del must be flexible enough to allow both to be used. Decision to use chann= el numbers or to specify frequencies can be made at run-time, e.g. when the= regulator domain is determined (see requirement P.3). Requirement P.4 says that PAWS must provide the ABILITY for the database to= authenticate the master, it does not say that the master must be authentic= ated. Authentication of the master is an option. I do notice that both of t= he proposals submitted to the work group envision HTTPS, or HTTP over TLS, = which is fully capable of supporting authentication of the master, but also= is in wide use for applications which authenticate only the server-side of= the transaction. The comments from Eric I believe are valid, i.e. PAWS not limited to TV ban= ds only and authentication of the master device is not mandatory. However I= believe our requirements as written do support these positions. Kind Regards, Scott From: ext com > Date: Mon, 30 Jul 2012 10:29:55 +0100 To: >, Gabor Bajko > Cc: "paws@ietf.org" > Subject: Re: [paws] A couple of clarifications to requirement doc? Eric Thanks very much for your comments. The intent of the requirements spec is = to cover all spectrum, but of course we only have two sets of inputs from r= egulatory bodies at present and they both relate to TV spectrum. The actual= Ofcom language refers to =93a list of lower and upper frequency boundarie= s=94 which is more flexible than using channels, but this is covered in the= requirement D.7 that you quoted, as the next sentence says =93The Data Mod= el MUST support specification of this information by channel numbers and by= start and stop frequencies.=94. So, although we could continue to refine t= he language in the PAWS requirements with regard to channels, personally I= =92m OK with the document and I don=92t see this as an area where we need t= o spend further effort. On your second point, in general I think we demand a lot of our regulators = if we expect them to have a full understanding of security threats and reme= dies, therefore we need to allow the PAWS protocol to include necessary sec= urity even if regulators were a bit vague. I interpret =93=85the protocol M= UST provide the ability for=85=94 in P.4 and elsewhere as allowing PAWS to = implement best practice with regard to security (authentication/authorisati= on/encryption/whatever), and I trust the PAWS participants not to make this= unnecessarily onerous. Clearly neither will we be writing a protocol that = is full of security holes. In this regard I don=92t have any problem with t= he requirements as written, as this is all sorted out in the next stage. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Eric Chu Sent: 30 July 2012 01:48 To: Gabor.Bajko@nokia.com Cc: paws@ietf.org Subject: [paws] A couple of clarifications to requirement doc? Hi Gabor, Apologize for the late "entry" but we would like to suggest a couple of min= or but important clarifications to current requirement doc to minimize pote= ntial confusions: * The final spec should be general enough to support all spectrum. Not= just TV spectrum. In our discussions with several PAWS members, they all = agree with this point but they point to the requirement doc as the limiting= factor to generalize the spec. For example in the Normative Requirements = section 6.1 D7 " The Data Model MUST support specifying a list of availab= le channels. The Data Model MUST support specification of this information= by channel numbers and...." * Both FCC and Ofcom do not require "authentication of device". While = the FCC requires the DB to check for "authorized" FCCID, device authenticat= ion is not required. Current requirement doc requires the database to "aut= henticate" the master device as stated in the Normative Requirements sectio= n 6.1 P.4 " The protocol MUST provide the ability for the database to authe= nticate the master device.". To be consistent with FCC and Ofcom spec, we b= elieve the spec should allow for the implementation of strong authenticatio= n as an option. Appreciate your thoughts on what's the best process to consider these refin= ements. If there's consensus, Google is more than happy to take on the wor= k of providing specific text changes. Thanks Eric _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CC3C1791DFC4scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi All,

In development of the Use Cases & Requirements, as a group we have= discussed this many times and always concluded that PAWS is not specific t= o TV bands, although TV bands will be first taken into use. I believe requi= rement D.7 is flexible and does not limit PAWS to TV frequencies. By stating that the data model must support = channel numbers AND frequency definitions, this does not mean that both mus= t be used at the same time, only that the data model must be flexible enoug= h to allow both to be used. Decision to use channel numbers or to specify frequencies can be made at run-time, = e.g. when the regulator domain is determined (see requirement P.3).

Requirement P.4 says that PAWS must provide the ABILITY for the databa= se to authenticate the master, it does not say that the master must be auth= enticated. Authentication of the master is an option. I do notice that both= of the proposals submitted to the work group envision HTTPS, or HTTP over TLS, which is fully capable of sup= porting authentication of the master, but also is in wide use for applicati= ons which authenticate only the server-side of the transaction.

The comments from Eric I believe are valid, i.e. PAWS not limited to T= V bands only and authentication of the master device is not mandatory. Howe= ver I believe our requirements as written do support these positions.

Kind Regards,
Scott

From: ext com <andy.sago@bt.com>
Date: Mon, 30 Jul 2012 10:29:55 = 3;0100
To: <ericchu@google.com>, Gabor Bajko <Gabor.Bajko@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] A couple of cla= rifications to requirement doc?

Eric

 

Thanks very much for your comments. The intent of t= he requirements spec is to cover all spectrum, but of course we only have t= wo sets of inputs from regulatory bodies at present and they both relate to TV spectrum. The actual Ofcom language = refers to  =93a list of lower and upper frequency boundaries=94 which = is more flexible than using channels, but this is covered in the requiremen= t D.7 that you quoted, as the next sentence says =93The Data Model MUST support specification of this information by c= hannel numbers and by start and stop frequencies.=94. So, although we could= continue to refine the language in the PAWS requirements with regard to ch= annels, personally I=92m OK with the document and I don=92t see this as an area where we need to spend further effort.

 

On your second point, in general I think we demand = a lot of our regulators if we expect them to have a full understanding of s= ecurity threats and remedies, therefore we need to allow the PAWS protocol to include necessary security even if r= egulators were a bit vague. I interpret =93=85the protocol MUST provide the= ability for=85=94 in P.4 and elsewhere as allowing PAWS to implement best = practice with regard to security (authentication/authorisation/encryption/w= hatever), and I trust the PAWS participants not to make this unnecessarily onerous. = Clearly neither will we be writing a protocol that is full of security hole= s. In this regard I don=92t have any problem with the requirements as writt= en, as this is all sorted out in the next stage.

 

Regards

 

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Eric Chu
Sent: 30 July 2012 01:48
To: Gabor.Bajko@nokia.com
Cc: paws@ietf.org
Subject: [paws] A couple of clarifications to requirement doc?<= /o:p>

 


Hi Gabor,

Apologize for the late "entry" but we would like to suggest a cou= ple of minor but important clarifications to current requirement doc to min= imize potential confusions:

  • The final spec should be general enough to support all spectrum.  Not = just TV spectrum.  In our discussions with several PAWS members, they = all agree with this point but they point to the requirement doc as the limi= ting factor to generalize the spec.  For example in the Normative Requirements section 6.1 D7   " The Data Model MUST support specifying a list of available channels.  = The Data Model MUST support specification of this information by channel nu= mbers and...."
  • Both FCC and Ofcom do not require "authentication of device".&nbs= p; While the FCC requires the DB to check for "authorized" FCCID,= device authentication is not required.  Current requirement doc requi= res the database to "authenticate" the master device as stated in the Normative Requirements section 6.1 P.4 " The protocol MUST provide the ability for the database to authenticate the = master device.". To be consistent with FCC and Ofcom spec, we believe the spec should= allow for the implementation of strong authentication as an option.

Appreciate your thoughts on what's the best process to consider these re= finements.  If there's consensus, Google is more than happy to take on= the work of providing specific text changes.

Thanks
Eric

 

 

 

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CC3C1791DFC4scottprobasconokiacom_-- From jstine@mitre.org Mon Jul 30 11:48:32 2012 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 0084911E8129 for ; Mon, 30 Jul 2012 11:48:32 -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 GG3lvdZZtzaq for ; Mon, 30 Jul 2012 11:48:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6896C11E8111 for ; Mon, 30 Jul 2012 11:48:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D44E321B0F70 for ; Mon, 30 Jul 2012 14:48:25 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A9E6C21B0F65 for ; Mon, 30 Jul 2012 14:48:25 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.151]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0309.002; Mon, 30 Jul 2012 14:48:25 -0400 From: "Stine, John A." To: "paws@ietf.org" Thread-Topic: [paws] A couple of clarifications to requirement doc? Thread-Index: AQHNbhFgNgvducdXIUqiQTRfQ0vl/ZdB0q2AgABxSgD//+Co0A== Date: Mon, 30 Jul 2012 18:48:24 +0000 Message-ID: <2782C93FD2244441893673F3F91281920667BBFC@IMCMBX01.MITRE.ORG> References: <619CDADDCCD2B44380834BE8BF6F714140A9E2060E@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: multipart/alternative; boundary="_000_2782C93FD2244441893673F3F91281920667BBFCIMCMBX01MITREOR_" MIME-Version: 1.0 Subject: Re: [paws] A couple of clarifications to requirement doc? 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, 30 Jul 2012 18:48:32 -0000 --_000_2782C93FD2244441893673F3F91281920667BBFCIMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Several months ago I pushed adding the goal of using separate business and = data models and making them modular (See Section 6.3 of the use cases and r= equirements). My intent was to address this problem of different ways to d= efine spectrum and different data required by different administrations in = the managed sharing of spectrum. Using channel numbers infers that all det= ails of the channel are known a priori, in our case when creating PAWS. I = think this is very restrictive. Spectrum definitions should be made part o= f a data module that can be replaced whole cloth. If it is made too close = to the communications specification, i.e. included in the data elements of = a message defined in the protocol rather than specified by an optional data= module, it will greatly limit the future applicability of the PAWS work. The recent discussion In the US with the release of the PCAST report "Reali= zing the Full Potential of Government Held Spectrum to Spur Economic Growth= " proposes t= o make database management a tool well beyond the TVWS. In these cases, th= e data model will need to support arbitrating reuse among any RF technologi= es. It will need to include the management of coexistence. This managemen= t will need to be collaboratively achieved among multiple database administ= rators. Channel numbers or specifying frequency definitions would both be = inadequate. By keeping it modular other standards bodies can worry about h= ow to model spectrum use so that coexistence can be arbitrated. I don't th= ink this is something that PAWS would want to do. The greatest value of PA= WS is its definition on how to discover databases and how to obtain and mai= ntain the authorization to use spectrum in a secure way. In the near term,= PAWS may need to create data models that match current TVWS regulation so = the standard can be made operational sooner. Long term, however, other sta= ndards bodies are likely to generate methods to model spectrum use and to a= rbitrate compatibility of spectrum uses that are more general. Work of thi= s nature is currently being pursued by the IEEE DySPAN SC P1900.5 WG. By emphasizing the modularity of this data in this first go around, it esta= blishes a first release of PAWS that can be expanded upon easily as new reg= ulatory and technical requirements for reuse are defined. These requiremen= ts and the means of arbitrating compatibility can be added by choosing the = data model. John From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: Monday, July 30, 2012 12:15 PM To: paws@ietf.org Subject: Re: [paws] A couple of clarifications to requirement doc? Hi All, In development of the Use Cases & Requirements, as a group we have discusse= d this many times and always concluded that PAWS is not specific to TV band= s, although TV bands will be first taken into use. I believe requirement D.= 7 is flexible and does not limit PAWS to TV frequencies. By stating that th= e data model must support channel numbers AND frequency definitions, this d= oes not mean that both must be used at the same time, only that the data mo= del must be flexible enough to allow both to be used. Decision to use chann= el numbers or to specify frequencies can be made at run-time, e.g. when the= regulator domain is determined (see requirement P.3). Requirement P.4 says that PAWS must provide the ABILITY for the database to= authenticate the master, it does not say that the master must be authentic= ated. Authentication of the master is an option. I do notice that both of t= he proposals submitted to the work group envision HTTPS, or HTTP over TLS, = which is fully capable of supporting authentication of the master, but also= is in wide use for applications which authenticate only the server-side of= the transaction. The comments from Eric I believe are valid, i.e. PAWS not limited to TV ban= ds only and authentication of the master device is not mandatory. However I= believe our requirements as written do support these positions. Kind Regards, Scott From: ext com > Date: Mon, 30 Jul 2012 10:29:55 +0100 To: >, Gabor Bajko > Cc: "paws@ietf.org" > Subject: Re: [paws] A couple of clarifications to requirement doc? Eric Thanks very much for your comments. The intent of the requirements spec is = to cover all spectrum, but of course we only have two sets of inputs from r= egulatory bodies at present and they both relate to TV spectrum. The actual= Ofcom language refers to "a list of lower and upper frequency boundaries"= which is more flexible than using channels, but this is covered in the req= uirement D.7 that you quoted, as the next sentence says "The Data Model MUS= T support specification of this information by channel numbers and by start= and stop frequencies.". So, although we could continue to refine the langu= age in the PAWS requirements with regard to channels, personally I'm OK wit= h the document and I don't see this as an area where we need to spend furth= er effort. On your second point, in general I think we demand a lot of our regulators = if we expect them to have a full understanding of security threats and reme= dies, therefore we need to allow the PAWS protocol to include necessary sec= urity even if regulators were a bit vague. I interpret "...the protocol MUS= T provide the ability for..." in P.4 and elsewhere as allowing PAWS to impl= ement best practice with regard to security (authentication/authorisation/e= ncryption/whatever), and I trust the PAWS participants not to make this unn= ecessarily onerous. Clearly neither will we be writing a protocol that is f= ull of security holes. In this regard I don't have any problem with the req= uirements as written, as this is all sorted out in the next stage. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Eric Chu Sent: 30 July 2012 01:48 To: Gabor.Bajko@nokia.com Cc: paws@ietf.org Subject: [paws] A couple of clarifications to requirement doc? Hi Gabor, Apologize for the late "entry" but we would like to suggest a couple of min= or but important clarifications to current requirement doc to minimize pote= ntial confusions: * The final spec should be general enough to support all spectrum. = Not just TV spectrum. In our discussions with several PAWS members, they = all agree with this point but they point to the requirement doc as the limi= ting factor to generalize the spec. For example in the Normative Requireme= nts section 6.1 D7 " The Data Model MUST support specifying a list of ava= ilable channels. The Data Model MUST support specification of this informa= tion by channel numbers and...." * Both FCC and Ofcom do not require "authentication of device". Wh= ile the FCC requires the DB to check for "authorized" FCCID, device authent= ication is not required. Current requirement doc requires the database to = "authenticate" the master device as stated in the Normative Requirements se= ction 6.1 P.4 " The protocol MUST provide the ability for the database to a= uthenticate the master device.". To be consistent with FCC and Ofcom spec, = we believe the spec should allow for the implementation of strong authentic= ation as an option. Appreciate your thoughts on what's the best process to consider these refin= ements. If there's consensus, Google is more than happy to take on the wor= k of providing specific text changes. Thanks Eric _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_2782C93FD2244441893673F3F91281920667BBFCIMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Several months ago I pushed adding the goal of using sep= arate business and data models and making them modular (See Section 6.3 of = the use cases and requirements).  My intent was to address this problem of different ways to define spectrum and different data requi= red by different administrations in the managed sharing of spectrum.  = Using channel numbers infers that all details of the channel are known a pr= iori, in our case when creating PAWS.  I think this is very restrictive.  Spectrum definitions should be mad= e part of a data module that can be replaced whole cloth.  If it is ma= de too close to the communications specification, i.e. included in the data= elements of a message defined in the protocol rather than specified by an optional data module, it will greatly limit th= e future applicability of the PAWS work.

 

The recent discussion In the US with the release of the = PCAST report “Realizing the Full Potential of Government Held Spectrum to Spur Economic Growth= ” proposes to make database management a tool well beyond the TVWS.&n= bsp; In these cases, the data model will need to support arbitrating reuse = among any RF technologies.  It will need to include the management of coexistence.  This management will need to = be collaboratively achieved among multiple database administrators.  C= hannel numbers or specifying frequency definitions would both be inadequate= .  By keeping it modular other standards bodies can worry about how to model spectrum use so that coexistence can be arbit= rated.  I don’t think this is something that PAWS would want to = do.  The greatest value of PAWS is its definition on how to discover d= atabases and how to obtain and maintain the authorization to use spectrum in a secure way.  In the near term, PAWS may need to = create data models that match current TVWS regulation so the standard can b= e made operational sooner.  Long term, however, other standards bodies= are likely to generate methods to model spectrum use and to arbitrate compatibility of spectrum uses that are more general.=   Work of this nature is currently being pursued by the IEEE DySPAN SC= P1900.5 WG.

 

By emphasizing the modularity of this data in this first= go around, it establishes a first release of PAWS that can be expanded upo= n easily as new regulatory and technical requirements for reuse are defined.  These requirements and the means of arbitrating c= ompatibility can be added by choosing the data model.

 

John

 <= /p>

 <= /p>

From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Monday, July 30, 2012 12:15 PM
To: paws@ietf.org
Subject: Re: [paws] A couple of clarifications to requirement doc?

 

Hi All,=

 <= /o:p>

In developme= nt of the Use Cases & Requirements, as a group we have discussed this m= any times and always concluded that PAWS is not specific to TV bands, although TV bands will be first taken into use. I believe requireme= nt D.7 is flexible and does not limit PAWS to TV frequencies. By stating th= at the data model must support channel numbers AND frequency definitions, t= his does not mean that both must be used at the same time, only that the data model must be flexible enough= to allow both to be used. Decision to use channel numbers or to specify fr= equencies can be made at run-time, e.g. when the regulator domain is determ= ined (see requirement P.3).

 <= /o:p>

Requirement = P.4 says that PAWS must provide the ABILITY for the database to authenticat= e the master, it does not say that the master must be authenticated. Authentication of the master is an option. I do notice that both of the pr= oposals submitted to the work group envision HTTPS, or HTTP over TLS, which= is fully capable of supporting authentication of the master, but also is i= n wide use for applications which authenticate only the server-side of the transaction.

 <= /o:p>

The comments= from Eric I believe are valid, i.e. PAWS not limited to TV bands only and = authentication of the master device is not mandatory. However I believe our requirements as written do support these positions.

 <= /o:p>

Kind Regards= ,

Scott

 <= /o:p>

From: ext com <and= y.sago@bt.com>
Date: Mon, 30 Jul 2012 10:29:55 +0100
To: <ericchu@google.com= >, Gabor Bajko <Gabor.Bajko@= nokia.com>
Cc: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: Re: [paws] A couple of clarifications to requirement doc?

 <= /o:p>

= Eric

=  

= Thanks very much for your comments. The intent of the requirements spec is = to cover all spectrum, but of course we only have two sets of inputs from regulatory bodies at present and they both relate to TV spectr= um. The actual Ofcom language refers to  “a list of lower and up= per frequency boundaries” which is more flexible than using channels,= but this is covered in the requirement D.7 that you quoted, as the next sentence says “The Data Model MUST support s= pecification of this information by channel numbers and by start and stop f= requencies.”. So, although we could continue to refine the language i= n the PAWS requirements with regard to channels, personally I’m OK with the document and I don’t see this as an= area where we need to spend further effort.

=  

= On your second point, in general I think we demand a lot of our regulators = if we expect them to have a full understanding of security threats and remedies, therefore we need to allow the PAWS protocol to include nece= ssary security even if regulators were a bit vague. I interpret “R= 30;the protocol MUST provide the ability for…” in P.4 and elsew= here as allowing PAWS to implement best practice with regard to security (authentication/authorisation/encryption/whatever), and I trus= t the PAWS participants not to make this unnecessarily onerous. Clearly nei= ther will we be writing a protocol that is full of security holes. In this = regard I don’t have any problem with the requirements as written, as this is all sorted out in the next st= age.

=  

= Regards

=  

= Andy

=  

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Eric Chu
Sent: 30 July 2012 01:48
To: Gabor.Bajko@nokia.com
Cc: paws@ietf.org
Subject: [paws] A couple of clarifications to requirement doc?

&nbs= p;


Hi Gabor,

Apologize for the late "entry" but we would like to suggest a cou= ple of minor but important clarifications to current requirement doc to min= imize potential confusions:

·       =   The final spec should b= e general enough to support all spectrum.  Not just TV spectrum. = In our discussions with several PAWS members, they all agree with this poi= nt but they point to the requirement doc as the limiting factor to generalize the spec.  For example in the Norma= tive Requirements section 6.1 D7   " The Data Model MUST support specifying a list of available = channels.  The Data Model MUST support specification of this informati= on by channel numbers and...."<= /span>

·       =   Both FCC and Ofcom do n= ot require "authentication of device".  While the FCC requir= es the DB to check for "authorized" FCCID, device authentication = is not required.  Current requirement doc requires the database to "authenticate" the master device as stated in the Normative R= equirements section 6.1 P.4 " The protocol MUST provide the ability for the database to a= uthenticate the master device.". To be consistent with FCC and Ofcom spec, we be= lieve the spec should allow for the implementation of strong authentication= as an option.

Appreciate your thoughts= on what's the best process to consider these refinements.  If there's= consensus, Google is more than happy to take on the work of providing spec= ific text changes.

Thanks
Eric

 =

 

 =

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

--_000_2782C93FD2244441893673F3F91281920667BBFCIMCMBX01MITREOR_-- From ietf@meetecho.com Mon Jul 30 13:46:27 2012 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 2A9D611E81A3 for ; Mon, 30 Jul 2012 13:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3rdHdMR0n4G for ; Mon, 30 Jul 2012 13:46:26 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out18.aruba.it [62.149.158.58]) by ietfa.amsl.com (Postfix) with SMTP id 27E2711E81A5 for ; Mon, 30 Jul 2012 13:46:25 -0700 (PDT) Received: (qmail 23195 invoked by uid 89); 30 Jul 2012 20:46:25 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq03.aruba.it with SMTP; 30 Jul 2012 20:46:25 -0000 Received: (qmail 16379 invoked by uid 89); 30 Jul 2012 20:46:25 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp3.ad.aruba.it with ESMTPA; 30 Jul 2012 20:46:24 -0000 Message-ID: <5016F28C.40209@meetecho.com> Date: Mon, 30 Jul 2012 22:46:04 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: paws@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [paws] Meetecho support for PAWS WG X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:46:27 -0000 Hi all, a virtual room has been reserved on the Meetecho system for today's PAWS WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf84/paws The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf84 Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From ben@blindcreek.com Mon Jul 30 13:50:32 2012 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 363E411E81A9 for ; Mon, 30 Jul 2012 13:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 dCKz60QRbPCl for ; Mon, 30 Jul 2012 13:50:30 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id DA14911E8155 for ; Mon, 30 Jul 2012 13:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=aC+52YCxFDIYtqX/3fUp9OJ1+xTtZ2J4Uan9SYlDsdY=; b=vkNV5jQOUtApa13aA0tLUX6e/ljMzAi+8ccEIJnidIAQrLOCsKtbiqYgK1hSQTk/3+a6Ttg84/YVKenFhUflupr3joV1xzwjn3w3YQareTRhS3jTF4TM+uzcqwz8s9zH; Received: from [64.74.213.174] (port=54117 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1Svwv3-0005ZI-SQ for paws@ietf.org; Mon, 30 Jul 2012 15:50:26 -0500 Message-ID: <5016F398.1010902@blindcreek.com> Date: Mon, 30 Jul 2012 13:50:32 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <5015D9CF.1090002@google.com> <619CDADDCCD2B44380834BE8BF6F714140A9E2060E@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140A9E2060E@EMV62-UKRD.domain1.systemhost.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] A couple of clarifications to requirement doc? 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, 30 Jul 2012 20:50:32 -0000 Hi Andy,
Your responses confuse me a bit, sorry if it's just me being daft again...

Eric

 

Thanks very much for your comments. The intent of the requirements spec is to cover all spectrum, but of course we only have two sets of inputs from regulatory bodies at present and they both relate to TV spectrum. The actual Ofcom language refers to  “a list of lower and upper frequency boundaries” which is more flexible than using channels, but this is covered in the requirement D.7 that you quoted, as the next sentence says “The Data Model MUST support specification of this information by channel numbers and by start and stop frequencies.”. So, although we could continue to refine the language in the PAWS requirements with regard to channels, personally I’m OK with the document and I don’t see this as an area where we need to spend further effort.

I'm not sure I see the point of doing both. For every regulatory domain I've studied so far, each TV channel is be defined by either a start and end frequency or center frequency and width.   Seems the frequency method is more generally useful for an exchange format.  I'm somewhat confused as to how PAWS will accommodate different database content and formats as they change, which seems inevitable.  

 

On your second point, in general I think we demand a lot of our regulators if we expect them to have a full understanding of security threats and remedies, therefore we need to allow the PAWS protocol to include necessary security even if regulators were a bit vague. I interpret “…the protocol MUST provide the ability for…” in P.4 and elsewhere as allowing PAWS to implement best practice with regard to security (authentication/authorisation/encryption/whatever), and I trust the PAWS participants not to make this unnecessarily onerous. Clearly neither will we be writing a protocol that is full of security holes. In this regard I don’t have any problem with the requirements as written, as this is all sorted out in the next stage.

The FCC has specified that the distribution of channel availability information must be secure.  This is in addition to the requirement that the device receiving channel information has been verified as authorized to operate as a white-space device.  Simple is definitely better as some of the devices I envision will be very low cost/low power.

I think the term "master" is rather limiting. There are devices that have access to the internet and so can access a database independently, and those that depend on some other source of channel availability information  There seems to be an assumption in the term "master" that the device accessing the database is also the network master for any devices depending on it as the data source. There is no reason to tie these roles together. It is quite possible that the device with database access is "just any peer" and network master.   I think when labeling a device that does not have access to the database (i.e. not internet infrastructure tied) the term "dependent" is more accurate.  I would think PAWS would not want to constrain the topology or architecture of the underlying network layers that may carry the protocol...am I missing some basis assumption?

Thanks in advance for patience with someone new to the discussion!

 

Regards

 

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Eric Chu
Sent: 30 July 2012 01:48
To: Gabor.Bajko@nokia.com
Cc: paws@ietf.org
Subject: [paws] A couple of clarifications to requirement doc?

 


Hi Gabor,

Apologize for the late "entry" but we would like to suggest a couple of minor but important clarifications to current requirement doc to minimize potential confusions:

  • The final spec should be general enough to support all spectrum.  Not just TV spectrum.  In our discussions with several PAWS members, they all agree with this point but they point to the requirement doc as the limiting factor to generalize the spec.  For example in the Normative Requirements section 6.1 D7   " The Data Model MUST support specifying a list of available channels.  The Data Model MUST support specification of this information by channel numbers and...."
  • Both FCC and Ofcom do not require "authentication of device".  While the FCC requires the DB to check for "authorized" FCCID, device authentication is not required.  Current requirement doc requires the database to "authenticate" the master device as stated in the Normative Requirements section 6.1 P.4 " The protocol MUST provide the ability for the database to authenticate the master device.". To be consistent with FCC and Ofcom spec, we believe the spec should allow for the implementation of strong authentication as an option.

Appreciate your thoughts on what's the best process to consider these refinements.  If there's consensus, Google is more than happy to take on the work of providing specific text changes.

Thanks
Eric

 

 

 


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